119 lines
5.2 KiB
HTML
119 lines
5.2 KiB
HTML
<body bgcolor=white>
|
|
<h1>OpenBeOS x86 boot process specification</h1>
|
|
<h6>
|
|
Creation Date: November 23, 2002<br>
|
|
Version: 1.0 (Nov 25, 2002)<br>
|
|
Status: preliminary proposal<br>
|
|
Author(s): Axel Dörfler
|
|
</h6>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<h3>Stage 1</h3>
|
|
<p>
|
|
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).
|
|
</p>
|
|
<p>
|
|
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.<br>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.<br>
|
|
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).
|
|
</p>
|
|
|
|
<h3>zbeos (or whatever it will be called)</h3>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
|
|
<h3>Stage 1.5</h3>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
This part is very similar to the current stage 1 boot loader from NewOS.
|
|
</p>
|
|
|
|
<h3>Stage 2</h3>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
This menu may also come up if an error occured during the execution of the stage
|
|
2 loader.
|
|
</p>
|
|
</body>
|