[haiku] Re: [GSOC2014] Haiku as a stand-alone UEFI app
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Mon, 17 Mar 2014 14:47:14 +0100
On 03/16/2014 08:55 PM, Louis Feuvrier wrote:
Hey guys,
Welcome Louis!
I am Louis Feuvrier and I am interested in working on the UEFI bootloader for
Haiku-os in the context of GSOC. I already introduced myself here[1] if you are
interested. I discussed a bit with tqh regarding this matter, and the consensus
currently seems to be a simple stand-alone UEFI app replicating the work done
by the ia32 bios module.
As most you must know, the linux kernel is bootable without the help of any
bootloader on the UEFI platform. This archlinux forum post[2] casts light on
the fact that you can invoke the linux kernel with a correct command-line
directly with UEFI. I am wondering if this would not be a great way of
implementing UEFI support in Haiku, thus avoiding a re-write of a lesser
grub-clone, or the shipment of grub itself with a BFS-aware UEFI application.
The current boot sequence for Haiku on x86 BIOS machines is as follows:
1. The MBR or some boot loader (grub or whatever) chain-loads the boot
sector of the Haiku (BFS) partition, which contains Haiku's stage 1 boot
loader.
2. Being severely limited due to size restrictions (< 900 bytes), the
stage 1 boot loader is just clever enough to locate and load Haiku's
stage 2 boot loader (haiku_loader) from the same partition.
3. The stage 2 boot loader loads the kernel and required kernel modules
and starts the kernel.
In theory the stage 2 boot loader could be merged with the kernel, so
that the stage 1 boot loader would directly load the kernel. There are
quite a few technical reasons why they are separate, though:
* There may be different requirements wrt. the executable format for
what the stage 1 boot loader can load (raw binary) and what we need/want
for the kernel (ELF object).
* The kernel may have to reside in an address range different from where
the stage 2 boot loader is/can be loaded. While relocating is possible
in principle, it's easier to avoid it by having separate components.
* The stage 2 boot loader encapsulates the boot platform. Regardless of
whether booted on BIOS, PXE, UEFI, OF, U-Boot,... the kernel can be
(mostly) ignorant of it.
* The stage 2 boot loader offers a user interface. In case you haven't
tried it yet, by holding down shift you can enter the boot menu, which
provides various safe mode and debug options. You can also choose to
boot into an entirely different partition, which is helpful e.g. when
the boot loader on that partition cannot be used for some reason
(broken, partition/disk not bootable (e.g. the BIOS doesn't support
booting off USB)). A planned feature is to allow booting an older
version of the system (e.g. when updating the system broke something).
The stage 1 boot loader is very much BIOS specific. It is not needed
where the stage 2 boot loader can be loaded directly by the boot
platform via other means. The stage 2 boot loader, however, makes sense
on all platforms, since at least some of the points listed above apply
everywhere. Trying to remove it from the boot sequence for UEFI will
just cause additional work.
So I see two reasonable approaches for UEFI:
1. Let the firmware directly load the stage 2 boot loader.
2. Let the firmware load a stage 1 boot loader that loads the stage 2
boot loader.
Approach 2 seems to be just additional work, but it would have the
advantage that the stage 1 could be very simple and would virtually
never need to be replaced. The stage 2 is currently packaged and loading
it directly would mean that it would have to be unpackaged and
reinstalled whenever it is updated.
Anyway, this is a relatively small change and the decision can be
postponed. The answer to you main question, whether it is a good idea to
load the kernel directly, clearly is no in either case.
CU, Ingo
Other related posts:
