I just find the fifo can boot the elfimage in the rom. If the etherboot is put in the beginning, Use boot:[EMAIL PROTECTED] can load the Etherboot.
Great... YH -----邮件原件----- 发件人: Greg Watson [mailto:[EMAIL PROTECTED] 发送时间: 2004年4月12日 5:55 收件人: Stefan Reinauer 抄送: [EMAIL PROTECTED] 主题: 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 <[EMAIL PROTECTED]> [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: > > 1) hardware initialization > 2) 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 [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
