[haiku] [GSOC2014] Haiku as a stand-alone UEFI app
- From: Louis Feuvrier <manny@xxxxxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Sun, 16 Mar 2014 20:55:50 +0100
Hey guys,
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.
This solution would need only a few tweaks on the existing kernel, as most of
the UEFI implementations around still have bios compatibility. Making the haiku
kernel compatible with pure UEFI hardware could be a next step in the process.
As far as I know, the TianoCore module for QEMU is also bios compatible, and
most PC around still keep a bios compatibility.
As stated by tqh, problems arise when upgrading the kernel. In fact,
considering the kernel would be stored in the UEFI partition (a simple
fat-formated partition,) a solution could be to mount this partition on the
/boot/efi folder or any other (as linux does currently.)
The only real problem I can see is the need to modify the command-line after
install, when upgrading the kernel or modifying the root partition for
example. There would be a need for a modification in the package-management
system, and a stand-alone program allowing the user to modify the NvRAM.
Another solution might be to just dump the command-line in a file on the UEFI
partition and just read it before loading the kernel.
I understand that this may imply fixes in many parts of the haiku source tree,
but the workload seems to be diminished by this solution, and attention can be
focused on making the best of the UEFI firmware itself.
I would greatly appreciate feedbacks from all of you on this idea, both
regarding the feasability itself, and the potential drawbacks.
Thanks for reading,
[1]
//www.freelists.org/post/haiku/GSOC2014-Introduction-Louis-manny-Feuvrier
[2] https://bbs.archlinux.org/viewtopic.php?pid=1090040#p1090040
--
Louis 'manny' Feuvrier
LSE - EPITA 2016
Other related posts:
