Bootloaders and LinuxBIOS - coreboot

7 Jun 2004


      As the freebiosv1 tree grew and developed we had a lot of disagreement
about bootloaders.  What should linuxbios do in condition X.  It was
clear that there was no way that in the linuxbios tree itself we could
satisfy all of the developers.  You can see remnants of this in
the freebios1 tree in src/lib/linuxbiosmain.c
Coming into this confusion I proposed a truce, that would give us
greater flexibility and allow a single LinuxBIOS source tree for
everyone.  That was to have a really stupid bootloader in LinuxBIOS
that was smart enough to load a real bootloader.  That is where
elfboot comes from.
To prove my concept I ported etherboot to run under LinuxBIOS as that 
was the only bootloader I could find that actually had real
hardware drivers.  In this scenario the fact that etherboot 
well with my style of booting was no longer a threat because people
were free to use their own code.  Etherboot was also choosen because
of it's strong core team of maintainers and you can all see the
results of that decision today.
Out of this concept we had additional bootloaders written or ported:
ADLO, FILO, OpenBIOS, baremetal, linux kernel, etc.
So from everything I can see this concept has been a success.  I have
seen no complaints.  We don't have more because it is not the easiest
thing to write standalone code to the bare metal.  But this is
something time and starting to catch up on our LinuxBIOS ports 
has been overcoming.
One of the large reasons I was a great proponet of the simple/stupid
bootloader in LinuxBIOS to load a real one is that draws a line around
what functionality LinuxBIOS shall provide.  Anything over that line
is code bloat.
Several months ago as I was involved in other things Yhlu noted that
FILO had been added to LinuxBIOS without a word.   The way he described
it I thought it was as a driver to elfboot.  I expressed my concerns
at that time, but I really have not had time to do anything.  And if
it was a driver it was seriously pushing the line I had drawn against
feature bloat, and really coming close to starting another bootloader
feature war but it was perhaps ok.
Later I finally had time to start syncing my code with the main
LinuxBIOS and I saw what that code actually was, and I was shocked.
This code had crossed the line, it had broken the truce, it was
feature bloat.  Not to talk about how useless a disk based bootloader
is without a configuration file.  From that moment on I have not
seen a reasonable solution besides deleting that code from LinuxBIOS.
Last time we had this conversation 2 problems were mentioned that
this code solves.
1) People have a hard time setting up an external payload.
2) There are not any bootloaders for the ppc that run under LinuxBIOS.
To the problem of setting up an external payload I propose we can
include FILO into the tree like baremetal and simply make it the
default payload.  If you don't change anything it will get built.
That solves the problem without breaking the design.
To the problem of there not being any bootloaders for the ppc that
run under LinuxBIOS.  I respond that one of the x86 based bootloaders
would not be hard to port, or better yet we can just use a kernel
with kexec built in.  Although I would strongly be with the amount of
embedded activity that happens with the ppc if none of the native
ppc bootloaders could not be easily adopted.
In addition I have seen noone except the guys at LANL who are even
interested in the built in FILO.
I have a few additional technical objections as well.  Just like when
someone tried to include etherboot the code in the LinuxBIOS tree has
languished, and is much less capable a solution.
Having to support bootloaders places an additional burden upon the
LinuxBIOS code that must be considered when the code must be
refactored or cleaned up.  And we have not even succeed in a
sufficiently clean and stable API that we are willing to freeze the
core interfaces and make stable releases from the LinuxBIOS tree, only
adding new ports or extensions to the existing API that cannot
possibly break old ports.
So does someone have a reason to keep the built-in FILO besides being
lazy slobs who want something-for-nothing and are not willing to put
in the work to make production quality solutions?
Eric