FILO 0.4 [PMX:#]

[Greg Watson]

On 04/04/2004, at 9:02 PM, Eric W. Biederman wrote:

> 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
>> filesystem.
>
> Feature bloat.

No, it's functionality that is needed for PPC but is not available 
anywhere else.

>
> 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
> nicely.
>
> Actual linking things together instead of including them together
> is unacceptable.
>
>> 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.

I don't get this policy stuff. This code is doing no more that adding 
another stream device, of which there are already two. Someone building 
LinuxBIOS is perfectly liberty to choose to load an ELF image from ROM, 
directly from an IDE device, or from a filesystem mounted on an IDE 
device.

>
> 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.

I agree. It would be nice if they were architecture independent as well.

>
> 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.

By policy, do you mean a file name in a valid filesystem? As opposed to 
a valid ELF header?  The distinction seems pretty fine to me. Being 
able to mount a compact flash device on another machine and drop 
multiple kernel versions onto it certainly helped me to get the EPIA 
going though.

Greg