From bb5a5c05ec2de99687bf1576b5cb4772c165ef74 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Axel=20D=C3=B6rfler?= Date: Mon, 25 Nov 2002 13:58:24 +0000 Subject: [PATCH] Added a document describing/specifying the (future) boot process for OpenBeOS on x86 systems. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2079 a95241bf-73f2-0310-859d-f6bbb57e9c96 --- .../kernel/boot/boot_process_specs_x86.html | 118 ++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 docs/develop/kernel/boot/boot_process_specs_x86.html diff --git a/docs/develop/kernel/boot/boot_process_specs_x86.html b/docs/develop/kernel/boot/boot_process_specs_x86.html new file mode 100644 index 0000000000..a986bf1407 --- /dev/null +++ b/docs/develop/kernel/boot/boot_process_specs_x86.html @@ -0,0 +1,118 @@ + +

OpenBeOS x86 boot process specification

+
+ Creation Date: November 23, 2002
+ Version: 1.0 (Nov 25, 2002)
+ Status: preliminary proposal
+ Author(s): Axel Dörfler +
+

+ 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. +

+ +

Stage 1

+

+ 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). +

+ +

zbeos (or whatever it will be called)

+

+ 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. +

+ +

Stage 1.5

+

+ 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. +

+ +

Stage 2

+

+ 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. +

+