Le mar 08/06/2004 à 17:00, Stefan Reinauer a écrit :
- Mathieu Deschamps mdeschamps@mangrove-systems.com [040608 16:20]:
I don't exactly get the problem. Etherboot would probably be the end of the in-rom payload chain, since it does not return from execution but pass control to Linux, which is not stored in ROM in the above scenario.
Ok we agree, I try to be clearer, i redo:
you said in above LinuxBIOS should allow payload chains, ie. executing multiple payloads one after the other.
Isn't it already was it can with the chain we're describing in here ? Or are you considering that it is not since it passes control up to a certain constant point ?
Not really. It works because the payload you use is a bootloader. This is a very hard restriction, as PCI resource allocation, or testbios are no bootloaders, and thus do not need and should really not have an ELF loader like LinuxBIOS itself has.
oh right... same when you build a the hello world example to test LinuxBios boot time : it no a boot loader. It is a ... I realized this difference i've reported it as bootloaders and booters. But I don't know if it's a good name... what do you think ?
Bootloaders are always the end of the chain.
But possibly ADLO could be moved to ROM before Etherboot is started.
Really ? but if ADLO, as you underlined it, is out-rom is it for a good reason : a lack of inrom space. So logically it must be filled to the top and got no bytes left
The space left depends really very much on the flash device you use. Optimistically, LinuxBIOS itself, without PCI resource allocation should only eat up around 32k with some fiddling. Compared to 256 or 512kbyte flash devices there is plenty of room for additions. If not ADLO then something else.
yes. but no to forget the VGABIOS that's 64k also or rather 50k
I am not arguing that ADLO should go to rom or should not. What I am trying to say is, that
- if we decide, that having FILO inside of LinuxBIOS is a break in design, we should be consequent and split everything but DRAM init and ELF loader out, including
So if i'am not mistaking, this would leave a LinuxBios core very thin while 'modules' adding fonctions, facilities and commodities would make it thicker... an architecture that has proven it efficiency...
- if there is enough space in rom, any payload should be able to receive and give back control. The payload view of things is nice, but either do it right or have a way around it if needed.
- payloads should be able to leave information in the LinuxBIOS table, so that following payloads don't have to do the same work over and over.
yes . if it's the role a the LinuxBIOS table...hum sure it is.
I see a certain point in not having function callbacks, even if I think it's a dubious one in a full open source environment, but I am not going to argue about this. It's not really needed, EOD.
for now, i also can't see the use of such a possibility...
How could we move it to ROM in such condition ? Oh I catch it : LinuxBios does return from execution nor Etherboot, that IS space on to write is it what you mean ?
sorry I mean : " Oh I catch it : LinuxBios does NOT return from execution nor Etherboot,"
My proposal does not care for anything after code is loaded from IDE. It should not, since, as Eric pointed out, this is bloat. And it is, since either one loads a kernel from a raw device, which is not solid enough for productive use, or one has to include filesystems and whatever. This code belongs out of the LinuxBIOS core, as does PCI resource allocation.
hum.. it is before so ? that makes me wonder more...
Stefan