Haiku boot process specification================================Creation Date: November 23, 2002Version: 2.0 (Jan 22, 2021)Status: documenting the current state of thingsAuthor(s): Axel Dörfler, Adrien DestuguesOverview--------Unlike other systems, Haiku comes with its own user-friendly bootloader.The main task of the bootloader is to load and start the kernel. Wedon't have a concept of an initramfs as Linux does, instead ourbootloader is able to find the kernel and modules in a BFS partition,and even extract them from packages as needed. It also provides an earlyboot menu that can be used to change settings, boot older versions ofHaiku that were snapshotted by the package system, and write boot logsto USB mass storage.Booting from BIOS-----------------Haiku BIOS boot loader process is split into 3 different stages. Sincethe second stage is bound tightly to both other stages (which areindependent from each other), it is referred to as stage 1.5, whereasthe other stages are referred to as stage 1 and 2. This architecture isused because the BIOS booting process only loads a very small piece ofcode from disk for booting, insufficient for the needs outlined above.The following will explain all stages in detail.Stage 1~~~~~~~The first stage is responsible for loading the real boot loader from aBFS disk. It will be loaded by the Master Boot Record (MBR) and executedin the x86 real mode. It is only used if the system will be booteddirectly from a BFS partition, it won't be used at all if it is bootedfrom a floppy disk or CD-ROM (in this case, stage 1.5 is in chargeimmediately).| It resides in the first 1024 bytes of a BFS disk which usually refersto the first two sectors of the partition in question. Since the BFSsuperblock is located at byte offset 512, and about 170 bytes large,this section is already reserved, and thus cannot be used by theloader itself.| The MBR only loads the first sector of a partition into memory, so ithas to load the superblock (and the rest of its implementation) byitself.| The loader must be able to load the real boot loader from a certainpath, and execute it. In BeOS this boot loader would be in"/boot/beos/system/zbeos", in Haiku this is haiku_loader.bios_ia32found in the haiku_loader package.| Theoretically, it is enough to load the first few blocks from theloader, and let the next stage then load the whole thing (which it hasto do anyway if it has been written on a floppy). This would be onepossible 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).haiku_loader.bios_ia32~~~~~~~~~~~~~~~~~~~~~~Contains both the stage 1.5 boot loader, and the compressed stage 2loader. It's not an ELF executable file; i.e. it can be directly writtento a floppy disk which would cause the BIOS to load the first 512 bytesof that file and execute it.Therefore, it will start with the stage 1.5 boot loader which will beloaded either by the BIOS when it directly resides on the disk (forexample when loaded from a floppy disk), or the stage 1 boot loader,although this one could have a different entry point than the BIOS.Stage 1.5~~~~~~~~~Will have to load the rest of haiku_loader into memory (if not alreadydone 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 stage 1 boot loader from NewOS.Stage 2~~~~~~~This is the most complex part of the boot loader. In short, it has toload 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 bootdisk - therefore the loader has to be able to access BFS disks. It alsohas to be able to load and parse the settings of these drivers (and thekernel) from the boot disk, some of them are already important for theboot loader itself (like "don't call the BIOS"). Since this stage isalready executed in protected mode, it has to use the virtual-86 mode tocall the BIOS and access any disk.Before loading those files from the boot disk, it should look foradditional files located on a specific disk location after the "zbeos"file (on floppy disk or CD-ROM). This way, it could access disks thatcannot be accessed by the BIOS itself.Setting up the system for the kernel also means initalizing PCI devicesneeded during the boot process before the kernel is up. It must be ableto do so since the BIOS might not have set up those devices correctly orat all.It also must calculate a check sum for the boot device which the kernelcan then use to identify the boot volume and partition with - there isno other reliable way to map BIOS disk IDs to the /dev/disk/... tree thesystem itself is using.After having loaded and relocated the kernel, it executes it by passinga special structure which tells the kernel things like the boot devicecheck sum, which modules are already loaded and where they are.The stage 2 boot loader also includes user interaction. If the userpresses a special key during the boot process (like the space key, orsome others as well), a menu will be presented where the user can selectthe boot device (if several, the loader has to scan for options), safemode options, VESA mode, etc.This menu may also come up if an error occured during the execution ofthe stage 2 loader.Open Firmware-------------On Open Firmware based systems, there is no need for a stage 1.5 becausethe firmware does not give us as many constraints. Instead, the stage 2is loaded directly by the firmware. This requires converting thehaiku_loader executable to the appropriate executable format (a.out onsparc, pef on powerpc). The conversion is done using custom toolsbecause binutils does not support these formats anymore.There is no notion of real and protected mode on non-x86 architectures,and the bootloader is able to easily call Open Firmware methods toperform most tasks (disk access, network booting, setting up theframebuffer) in a largely hardware-independent way.U-Boot------U-Boot is able to load the stage2 loader directly from an ELF file.However, it does not provide any other features. It is not possible forthe bootloader to call into U-Boot APIs for disk access, displayingmessages on screen etc (while possible in theory, these features areoften disabled in U-Boot). This means haiku_loader would need to parsethe FDT (describing the available hardware) and bundle its own driversfor using the hardware. This approach is not easy to set up, and it isrecommended to instead use the UEFI support in U-Boot where possible.EFI---On EFI systems, there is no need for a stage1 loader as there is forBIOS. Instead, our stage2 loader (haiku_loader) can be executed directlyfrom the EFI firmware.The EFI firmware only knows how to run executables in the PE format (asused by Windows) because Microsoft was involved in specifying it. Onx86_64, we can use binutils to output a PE file directly. But on otherplatforms, this is not supported by binutils. So, what we do is generatea "fake" PE header and wrap our elf file inside it. The bootloader thenparses the embedded ELF header and relocates itself, so the other partsof the code can be run.After this initial loading phase, the process is very similar to theOpen Firmware one. EFI provides us with all the tools we need to do diskaccess and both text mode and framebuffer output.