FILO 0.4 [PMX:#]
Eric W. Biederman
ebiederman at lnxi.com
Sun Apr 4 22:36:01 CEST 2004
Greg Watson <gwatson at lanl.gov> writes:
> Correct. I haven't included linux_load, though it would probably be
> easy to do. FILO simply calls elfboot to load the image from a
If we want to take a snapshot of the source tree of FILO or any other
bootloader into the LinuxBIOS tree under util. Build that part of the
build and build a complete romimage that works. I am fine
with that. It is even reasonable to make it so you can drop in
external trees like etherboot and have everything build together
Actual linking things together instead of including them together
> Merging FILO with etherboot is a fine idea, but it doesn't solve the
> loader problem for PPC. At this point I don't see any requirement to
> port etherboot to PPC, but if anyone would like to take it on then
> feel free. :-)
It is a half way decent stand alone portable bootloader. There
are a lot of other ones out there as well. Etherboot is something
simple and small that exists as an alternative.
Etherboot should be a fairly trivial port which is why I suggest it.
> I think the case for including a simple FILO-like loader in linuxbios
> is a strong one. Apart from instant PPC loader support and reducing
> the difficulty of deploying linuxbios, it's possible to make use of
> much of the existing linuxbios code which significantly reduces
> duplication and complexity in the payload.
I have not seen it yet. The reason FILO simplifies is because
it a simple first pass. But this complicates LinuxBIOS, and includes
policy. Both of which are bad.
Any builtin policy more complicated than slurp in one hard coded
executable and run it I refuse to touch, and elfload gives us that.
This is a line I refuse to cross and will delete code from
CVS if necessary to enforce.
Bootloaders can and should be board independent. That makes
then easier to test and develop. And it very much simplifies
the test of the whole thing.
In addition we have had way to many questions of what is the right
policy for a bootloader to implement, on this list. I refuse
to couple that to the LinuxBIOS core. And I don't want some stupid
policy in there like FILO's that would require me to upgrade
my firmware just to upgrade my OS.
More information about the coreboot