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.
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. :-)
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.
Greg
On 04/04/2004, at 2:57 PM, Yinghai Lu wrote:
Eric,
Greg just move the fs support from filo to linuxbios, and create fs_stream.
It still calls the elfboot to load the elfimage in HD. And it doesn't support linux_load.
So it is some kind of boot loader you said.
It is really enhancement to ide_stream.c
Regards
YH
-----邮件原件----- 发件人: Eric W. Biederman [mailto:eric@lnxi.com] 代表 Eric W. Biederman 发送时间: 2004年4月3日 20:33 收件人: Greg Watson 抄送: Yinghai Lu; 'SONE Takeshi'; linuxbios@clustermatic.org 主题: Re: g-e$: FILO 0.4 [PMX:#]
Greg Watson gwatson@lanl.gov writes:
Yeah sorry, I kind of did that by stealth. Ron and I get lots of requests
from
people wanting to use LB but who don't know how to deal with the payload issue. We decided that it would be really nice to have a simple bootloader
that
understands some basic filesystems built into LB. That way people can get
going
without having to deal with etherboot or FILO directly. A nice side effect
is
that it simplifies the FILO code significantly - in fact the only code
that is
really required is the filesystem support. Also, another major plus is
that the
code supports PPC as well as x86. Up to now I've had no bootloaders
(etherboot
or FILO) that work on PPC.
Then we refactor and make building the bootloader part of the tree. These things are policy engines. We need to separate mechanism and policy.
As far as I can tell this level of support crosses the line.
etherboot is portable and would not be hard to get running on ppc.
Eric
Greg Watson gwatson@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.
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.
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.
Eric
On 04/04/2004, at 9:02 PM, Eric W. Biederman wrote:
Greg Watson gwatson@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
* 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:
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
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
-
ebiederman＠lnxi.com -
Greg Watson -
Stefan Reinauer