Bootloader: Difference between revisions

828 bytes added ,  11 months ago
no edit summary
[unchecked revision][unchecked revision]
No edit summary
 
(12 intermediate revisions by 9 users not shown)
Line 11:
 
=== 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? Is it a regular file on a [[FAT|FAT-formatted]] floppypartition? Is it a collection of consecutive sectors in the "reserved area" of the FAT12FAT floppyfile system (in which case you may need a dedicated tool to format the disk and install the kernel on it)? Or is the floppydisk / partition simply left unformatted and the kernel pasted directly with a disk image tool?
 
All the above options are possible. Maybe the one I'd choose myself would be to reserve enough space on a FAT12FAT floppyfile system to store the list of sectors used by the kernel file. The field reserved sectors in the BPB is a perfect place for this. The "advantage" of being fully-FAT12FAT is that you don't need to re-write the bootsector every time you rewrite the kernel.
 
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 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 chosechoose which partition to boot from. Then, your (relocated) MBR bootsector would load that partition boot sector to 0x0000:0x7c00, and jump there. The partition boot sector would be none the wiser that there already was a bootsector loaded before, and could actually load yet another bootsector - which is why it's called chainloading.
 
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 initrd [[Ramdisk|ramdisksinitrd]] ramdisks etc. etc.
 
== See Also ==
 
=== Articles ===
* [[BootProg]] is able to load COM/MZ programs from a FAT12/16/32-formatted media
* [[BootProg]]
* [[Bootf]] is a small FAT12 floppy bootloader for protected mode OS images
* [[Bootf]]
* [[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://www.viralpatel.net/taj/tutorial/hello_world_bootloader.php Writing Hello World Bootloader] ([http://web.archive.org/web/20140729084135/http://viralpatel.net/taj/tutorial/hello_world_bootloader.php Cached version])
* [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]]
Anonymous user