Anonymous user
Bootloader: Difference between revisions
no edit summary
[unchecked revision] | [unchecked revision] |
m (Interwiki) |
No edit summary |
||
(16 intermediate revisions by 10 users not shown) | |||
Line 3:
== What does a boot loader do ==
The boot loader ultimately has to:
* Bring the kernel (and all the kernel needs to bootstrap)
* Provide the kernel with the information it needs to work correctly
* Switch to an environment that the kernel will like
* Transfer control to the kernel
On the x86, the boot loader runs in [[Real Mode]]. Consequently it has easy access to BIOS resources and functions. Therefore it's a good place to perform memory map detection,
=== Loading your kernel ===
The bits of your kernel are somewhere on some disk (presumably the booting disk, but this is not mandatory). Question is: where on the disk
All the above options are possible. Maybe the one I'd choose myself would be to reserve enough space on a
What needs to be loaded mainly depends on what's in your kernel. Linux, for instance, requires an additional 'initrd' file that will contain the 'initialization process' (as user level). If your kernel is modular and if Filesystems are understood by some modules, you need to load the modules along with the kernel. Same goes for 'microkernel services' like disk/files/memory services, etc.
Line 19:
=== Giving the kernel its information ===
Some kernels require some extra information to run. For example,
In general, anything that involves a BIOS call
=== Establishing an environment ===
Line 32:
It's common for the loader to keep interrupts disabled (the kernel will enable them later when an IDT is properly set up).
''Note:
== Bootloader design ==
Line 50:
== Booting multiple OSes ==
The easiest way to boot another OS is a mechanism called chainloading. Windows stores something akin to a second-stage bootloader in the boot sector of the partition it was installed in. When installing Linux, writing e.g. LILO or GRUB to the partition boot sector instead of the MBR is also an option. Now, the thing your MBR bootsector can do is to relocate itself (copying from 0x0000:0x7c00 to, traditionally, 0x0060:0x0000), parse the partition table, display some kind of menu and let the user
You see that with displaying a menu in some intelligible way and accepting keystrokes, such a multi-option bootloader can get quite complex rather quickly. We didn't even touch the subject of booting from extended partitions, which would require sequentially reading and parsing multiple extended partition tables before printing the menu.
Taken to the extreme, bootmanagers like that can become as complex as a simple OS, [[GRUB]] being a good example: It offers reading from various filesystems, booting [[Multiboot]] kernels, chainloading, loading
== See Also ==
=== Articles ===
* [[BootProg]] is able to load COM/MZ programs from a FAT12/16/32-formatted media
* [[Bootf]] is a small FAT12 floppy bootloader for protected mode OS images
* [[Gujin]] is a GPLed bootloader for the PC
* [[GRUB]] is a huge, bloated Grand Unified Bootloader, used by many OSes
* [[BOOTBOOT]] for booting 64 bit kernels on BIOS, UEFI, El Torito CDROM etc.
* [[Limine]] is a bootloader capable of natively booting 64-bit kernels and Linux
* [[SysLinux]] is the Linux kernel loader
* [[Rolling Your Own Bootloader]]
=== Threads ===
=== External Links ===
* [http://
* [http://www.cs.cmu.edu/~410-s07/p4/p4-boot.pdf "Writing a Bootloader from Scratch"] from Carnegie Mellon Computer Science Department
[[Category:OS theory]]
[[Category:Booting]]
[[Category:Bootloaders]]
[[de:Bootloader]]
|