+ OpenBeOS will use a boot loader process with 3 different stages. Since the second + stage is bound tightly to both other stages (which are independent from each other), + is referred to as stage 1.5, whereas the other stages are referred to as stage 1 + and 2. +
++ The following will explain all stages in detail. Note that this document is not + necessarily complete and a work in progress - it doesn't describe a situation + as-is, but one that very likely will be. +
+ ++ The first stage is responsible for loading the real boot loader from a BFS disk. It + will be loaded by the Master Boot Record (MBR) and executed in the x86 real mode. + It is only used if the system will be booted directly from a BFS partition, it won't + be used at all if it is booted from a floppy disk or CD-ROM (in this case, stage + 1.5 is in charge immediately). +
+
+ It resides in the first first 1024 bytes of a BFS disk which usually refers to the
+ first two sectors of the partition in question. Since the BFS super block is located
+ at byte offset 512, and about 170 bytes large, this section is already reserved,
+ and thus cannot be used by the loader itself.
+ The MBR only loads the first sector of a partition into memory, so it has to load
+ the super block (and the rest of its implementation) by itself.
+
+ The loader must be able to load the real boot loader from a certain path, and
+ execute it. In BeOS this boot loader would be in "/boot/beos/system/zbeos" -
+ this name will likely change for OpenBeOS, though.
+ Theoretically, it is enough to load the first few blocks from the loader, and
+ let the next stage then load the whole thing (which it has to do anyway if it
+ has been written on a floppy). This would be one possible optimization
+ if the 850 bytes of space are filled too early, but would require that "zbeos"
+ is written in one sequential block (which should be always the case anyway).
+
+ Contains both, the stage 1.5 boot loader and the compressed stage 2 loader. + It's not an ELF executable file; i.e. it can be directly written to a floppy + disk which would cause the BIOS to load the first 512 bytes of that file and + execute it. +
++ Therefore, it will start with the stage 1.5 boot loader which will be loaded + either by the BIOS when it directly resides on the disk (for example when + loaded from a floppy disk), or the stage 1 boot loader, although this one + could have a different entry point than the BIOS. +
+ ++ Will have to load the rest of "zbeos" into memory (if not already done by the + stage 1 loader in case it has been loaded from a BFS disk), set up the global + descriptor table, switch to x86 protected mode, uncompress stage 2, and execute it. +
++ This part is very similar to the current stage 1 boot loader from NewOS. +
+ ++ This is the most complex part of the boot loader. In short, it has to load + any modules and devices the kernel needs to access the boot device, set up + the system, load the kernel, and execute it. +
++ The kernel, and the modules and drivers needed are loaded from the boot + disk - therefore the loader has to be able to access BFS disks. It also + has to be able to load and parse the settings of these drivers (and the + kernel) from the boot disk, some of them are already important for the + boot loader itself (like "don't call the BIOS"). Since this stage is already + executed in protected mode, it has to use the virtual-86 mode to call the + BIOS and access any disk. +
++ Before loading those files from the boot disk, it should look for additional + files located on a specific disk location after the "zbeos" file (on floppy disk + or CD-ROM). This way, it could access disks that cannot be accessed by the + BIOS itself. +
++ Setting up the system for the kernel also means initalizing PCI devices needed + during the boot process before the kernel is up. It must be able to do so since + the BIOS might not have set up those devices correctly or at all. +
++ It also must calculate a check sum for the boot device which the kernel can then + use to identify the boot volume and partition with - there is no other reliable + way to map BIOS disk IDs to the /dev/disk/... tree the system itself is using. +
++ After having loaded and relocated the kernel, it executes it by passing a special + structure which tells the kernel things like the boot device check sum, which + modules are already loaded and where they are. +
++ The stage 2 boot loader also includes user interaction. If the user presses a + special key during the boot process (like the space key, or some others as well), + a menu will be presented where the user can select the boot device (if several, + the loader has to scan for options), safe mode options, VESA mode, etc. +
++ This menu may also come up if an error occured during the execution of the stage + 2 loader. +
+