New subject: ????: FILO 0.4 [PMX:#]

12 Apr 2004

      I just find the fifo can boot the elfimage in the rom.
If the etherboot is put in the beginning, 
Use 
boot:mem@0xfff80000 
can load the Etherboot.
Great...
YH
-----邮件原件-----
发件人: Greg Watson [mailto:gwatson@lanl.gov] 
发送时间: 2004年4月12日 5:55
收件人: Stefan Reinauer
抄送: linuxbios@clustermatic.org
主题: Re: FILO 0.4 [PMX:#]
Stefan,
I think this is a great idea. I'll talk it over with Ron and Ollie this 
week and look at how it might be implemented.
Greg
On 05/04/2004, at 6:46 AM, Stefan Reinauer wrote:
...

Eric W. Biederman ebiederman@lnxi.com [040405 05:02]:

...
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.
What about the following:
Currently LinuxBIOS divides into 2 fundamental parts:

hardware initialization
getting and starting the payload

This second part consists of two parts, again:
i) elfloader
ii) payload
Note, this is only one possible design. Maybe, this design is bloated
for some application cases.
Eric, you want to make a hard cut between what is LinuxBIOS and what is
not. This is generally a good idea, as it keeps the different
initialization steps distinct from reach other. What, if we add another
cut by dividing hardware initialization frin the payload-loader?
Instead of packing stuff like filo to util, we could do:

create a directory loader which can hold all "loaders"
move the elf loader with a Config.lb to a subdirectory in there
create other directories for other "loaders" like filo.

If done right, filo can still be compiled as a payload, or built in if
the win in size is noticable. A target config file could probably 
choose
which method to use, without overhead. Also, syncing with other trees,
like Takeshi's filo tree could be fairly easy, too.
I don't think we really have a conflict in direction here at all.
LinuxBIOS itself should be as small as possible, and the different 
parts
should be as independent as possible. But we also want to be a lot more
flexible than the existing solutions..
...
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.
Please explain, how is filo worse here than putting linux in flash?
Stefan
_______________________________________________
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios

答复: FILO 0.4 [PMX:#]