Bootloader FAQ

From OSDev.wiki
Revision as of 20:10, 24 September 2018 by Glauxosdever (talk | contribs) (Initial Bootloader FAQ with four questions: two answered and two pending)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This page intends to answer the most frequent questions related to writing a bootloader.

GRUB or custom bootloader?

This page is a stub.
You can help the wiki by accurately adding more contents to it.

TODO.

BIOS or UEFI?

This page is a stub.
You can help the wiki by accurately adding more contents to it.

TODO.

How do I load the kernel (BIOS)?

You probably followed a tutorial that shows how to write a "bootloader" that prints "Hello, World!" using the BIOS. Now you naturally ask how to load the kernel, which is indeed the intended purpose of a bootloader.

Unfortunately, loading the kernel isn't quite a simple thing, as seen from What should my bootloader support? Of course, these things won't fit in the 512 bytes you got in your stage-1, so you need to load more sectors before even initialising the environment for the kernel.

Floppies

Please, don't even bother with these unreliable media.

Hard disks

Assuming a partitioned hard disk, the BIOS loads and executes the Master Boot Record (MBR), which is responsible for loading and executing the Volume Boot Record (VBR) of the active partition. Normally, the VBR should simply do some initial checks and load stage-2 from either the filesystem or some reserved sectors right after the VBR (not the MBR, see the footnote). I suggest doing the latter, in order not to bother with filesystems yet. If you, however, decide to implement a filesystem already, be warned that common filesystems don't reserve much space for stage-1. FAT is probably the worst in this regard, reserving only one single sector (the VBR) for doing initial checks, parsing the filesystem tables and loading stage-2. Ext2 is somewhat better, reserving another sector right after the VBR, but then again Ext2 needs more parsing than FAT. Or, if you want, design your own filesystem (don't do it before designing and implementing the VFS), where the VBR says how many sectors at the start of the partition are reserved so you can put the whole bootloader there.

Footnote: The space after the MBR and before the first partition is not supposed to be used by any OS.

CDs

For CDs, there is the El-Torito specification. The CD has an ISO-9660 filesystem and the BIOS reads a file from the filesystem and executes the code from it. Compliant BIOSes will load the full file. However, some older BIOSes may only load the first sector (2048 bytes), so you might still want to split it into two stages; either as two files, or as two parts of the same file where the second part of the file starting at offset 2048 contains a magic number that's checked by the first part.

Note that the CDs you buy in bulk may usually be burned only once. Please look for CD-RWs which, while a bit more expensive than CD-Rs, allow to be rewritten multiple times, making them acceptable for testing your OS.

USB drives

This page is a stub.
You can help the wiki by accurately adding more contents to it.

The last time you installed a Linux distro, chances are you wrote the live CD to the USB drive and booted from it. The problem, however, is that BIOSes treat USB drives as hard disks, so the CD image needs to additionally contain a valid MBR that is then loaded by the BIOS. Now the space available between the MBR and the first interesting ISO-9660 sector may be used for stage-2.

<personal_opinion>Don't do it yet.</personal_opinion>

What should my bootloader support?

Apart from loading the kernel, the bootloader also has to prepare the environment appropriately before handing off control to the kernel. This includes:

  • Detecting CPU/BIOS features. You need to make sure that the CPU or the BIOS supports any features that you use (e.g. INT 0x13 extensions).
  • Getting the memory map. Where will you even load the kernel if you don't know what memory areas actually are memory?
  • Enabling A20 and protected mode with paging (or long mode if running on x86_64). GRUB doesn't enable paging or long mode, but that doesn't mean other bootloaders shouldn't do better. Not enabling paging or long mode in the bootloader means that you need to decide a priori in which physical memory area the kernel will reside, which may lead to two potential consequences:
    • There might not be actually any memory at that address;
    • It makes it a bit harder and more messy to do a higher half kernel.

When you are more advanced, you may also want/need to do these things in the bootloader:

<personal_opinion>I suggest starting from the bare minimum in order to load the kernel then implement whatever you see the kernel needs. Don't try to match an existing specification (e.g. Multiboot), otherwise it would be probably better to use an existing bootloader (e.g. GRUB).</personal_opinion>