Bootloader: Difference between revisions

* Bring the kernel (and all the kernel needs to bootstrap) ininto memory

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, detectingdetection of available video modes, loading of additional files, etc. The boot loader will collect this information and present it in a way the kernel will be able to understand.

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]] floppy partition? isIs it a collection of consecutive sectors in the "reserved area" of the FAT12FAT file floppysystem (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.

Some kernels require some extra information to run. For example, Youyou'll need to tell Linux the root partition to start from. Pretty useful information to have is a map of the address space - effectively a map of where physical memory is and where it's not. Other popular queries regard video modes.

In general, anything that involves a BIOS call areis easier to do in [[Real Mode]], so better do them while in real mode than trying to come back to real mode for a trip later.

''Note: givetake yourselftime theto timethink about thinking whether or not you'll enable paging now or nothere. Keep in mind that debugging paging initialization code without the help of exception handlers may quickly become a nightmare !''

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 0x07c0: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 0x07c0: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.

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.

* [[Gujin]] is a GPLed bootloader for the PC

* [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])