hrev54922 adds 1 changeset to branch 'master'
old head: e73999aa57b7cf883c9b8c87e97bfe012ef7e0fc
new head: 4dcdff4fe3d770e6fc3fffcd6cfd0326ef471c1f
overview:
https://git.haiku-os.org/haiku/log/?qt=range&q=4dcdff4fe3d7+%5Ee73999aa57b7
----------------------------------------------------------------------------
4dcdff4fe3d7: Update "boot process specs" documentation
Quite a lot has happened since this was initially written.
Change-Id: Iad68ea821733ab7489d2f9713857d2752b80356d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3674
Reviewed-by: Adrien Destugues <pulkomandy@xxxxxxxxx>
[ Adrien Destugues <adrien.destugues@xxxxxxxxxxxxxxxxxxxxx> ]
----------------------------------------------------------------------------
Revision: hrev54922
Commit: 4dcdff4fe3d770e6fc3fffcd6cfd0326ef471c1f
URL: https://git.haiku-os.org/haiku/commit/?id=4dcdff4fe3d7
Author: Adrien Destugues <adrien.destugues@xxxxxxxxxxxxxxxxxxxxx>
Date: Sat Jan 23 20:47:44 2021 UTC
Committer: Adrien Destugues <pulkomandy@xxxxxxxxx>
Commit-Date: Wed Jan 27 19:51:07 2021 UTC
----------------------------------------------------------------------------
1 file changed, 67 insertions(+), 20 deletions(-)
...ss_specs_x86.html => boot_process_specs.html} | 87 +++++++++++++++-----
----------------------------------------------------------------------------
diff --git a/docs/develop/kernel/boot/boot_process_specs_x86.html
b/docs/develop/kernel/boot/boot_process_specs.html
similarity index 54%
rename from docs/develop/kernel/boot/boot_process_specs_x86.html
rename to docs/develop/kernel/boot/boot_process_specs.html
index a4f0f2a85c..b5a0d9bf0e 100644
--- a/docs/develop/kernel/boot/boot_process_specs_x86.html
+++ b/docs/develop/kernel/boot/boot_process_specs.html
@@ -1,22 +1,31 @@
<body bgcolor=white>
- <h1>OpenBeOS x86 boot process specification</h1>
+ <h1>Haiku 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
+ Version: 2.0 (Jan 22, 2021)<br>
+ Status: documenting the current state of things<br>
+ Author(s): Axel Dörfler, Adrien Destugues
</h6>
+
+ <h2>Overview</h2>
+
+ <p>Unlike other systems, Haiku comes with its own user-friendly
bootloader. The main task of
+ the bootloader is to load and start the kernel. We don't have a concept
of an initramfs as
+ Linux does, instead our bootloader is able to find the kernel and
modules in a BFS partition,
+ and even extract them from packages as needed. It also provides an
early boot menu that can
+ be used to change settings, boot older versions of Haiku that were
snapshotted by the package
+ system, and write boot logs to USB mass storage.</p>
+
+ <h2>Booting from BIOS</h2>
+
<p>
- OpenBeOS will use a boot loader process with 3 different
stages. Since the second
+ Haiku BIOS boot loader process is split into 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>
+ it is referred to as stage 1.5, whereas the other stages are
referred to as stage 1
+ and 2. This architecture is used because the BIOS booting
process only loads a very
+ small piece of code from disk for booting, insufficient for the
needs outlined above.</p>
+
+ <p>The following will explain all stages in detail.</p>
<h3>Stage 1</h3>
<p>
@@ -27,7 +36,7 @@
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
+ It resides in the first 1024 bytes of a BFS disk which usually
refers to the
first two sectors of the partition in question. Since the BFS
superblock 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>
@@ -36,8 +45,8 @@
</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>
+ execute it. In BeOS this boot loader would be in
"/boot/beos/system/zbeos",
+ in Haiku this is haiku_loader.bios_ia32 found in the
haiku_loader package.<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
@@ -45,9 +54,9 @@
is written in one sequential block (which should be always the
case anyway).
</p>
- <h3>zbeos (or whatever it will be called)</h3>
+ <h3>haiku_loader.bios_ia32</h3>
<p>
- Contains both, the stage 1.5 boot loader and the compressed
stage 2 loader.
+ 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.
@@ -61,12 +70,12 @@
<h3>Stage 1.5</h3>
<p>
- Will have to load the rest of "zbeos" into memory (if not
already done by the
+ Will have to load the rest of haiku_loader 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.
+ This part is very similar to the stage 1 boot loader from NewOS.
</p>
<h3>Stage 2</h3>
@@ -115,4 +124,42 @@
This menu may also come up if an error occured during the
execution of the stage
2 loader.
</p>
+
+ <h2>Open Firmware</h2>
+
+ <p>On Open Firmware based systems, there is no need for a stage 1.5
because the firmware
+ does not give us as many constraints. Instead, the stage 2 is loaded
directly by the firmware.
+ This requires converting the haiku_loader executable to the appropriate
executable format
+ (a.out on sparc, pef on powerpc). The conversion is done using custom
tools because binutils
+ does not support these formats anymore.</p>
+
+ <p>There is no notion of real and protected mode on non-x86
architectures, and the bootloader
+ is able to easily call Open Firmware methods to perform most tasks
(disk access, network booting,
+ setting up the framebuffer) in a largely hardware-independent way.</p>
+
+ <h2>U-Boot</h2>
+
+ <p>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 for the bootloader to
call into U-Boot APIs
+ for disk access, displaying messages on screen etc (while possible in
theory, these features
+ are often disabled in U-Boot). This means haiku_loader would need to
parse the FDT (describing
+ the available hardware) and bundle its own drivers for using the
hardware. This approach is
+ not easy to set up, and it is recommended to instead use the UEFI
support in U-Boot where
+ possible.</p>
+
+ <h2>EFI</h2>
+
+ <p>On EFI systems, there is no need for a stage1 loader as there is for
BIOS. Instead, our stage2
+ loader (haiku_loader) can be executed directly from the EFI
firmware.</p>
+
+ <p>The EFI firmware only knows how to run executables in the PE format
+ (as used by Windows) because Microsoft was involved in specifying it.
+ On x86_64, we can use binutils to output a PE file directly. But on
other platforms, this is not
+ supported by binutils. So, what we do is generate a "fake" PE header
and wrap our elf file inside
+ it. The bootloader then parses the embedded ELF header and relocates
itself, so the other parts
+ of the code can be run.</p>
+
+ <p>After this initial loading phase, the process is very similar to the
Open Firmware one. EFI
+ provides us with all the tools we need to do disk access and both text
mode and framebuffer
+ output.</p>
</body>
