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