* 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.
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.
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
* 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.
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.
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 ?
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.
Stefan
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
* Mathieu Deschamps mdeschamps@mangrove-systems.com [040608 17:52]:
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 ?
I think just "payload" is fine in LinuxBIOS context. Or, since it's not an intermediary it might be considered an OS or just a lowlevel application.
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
Except for onboard graphics adapters this is placed on the graphics card rom and does not need to be packed into the system rom.
- 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...
Yes, exactly. Commercial BIOS does a very similar thing, and of all things commercial BIOS does, this is actually among the best.
- 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.
The LinuxBIOS table is an enhancable table that can have new entries defined without breaking the parsability of old well-known entries. If a payload does not know how to parse a LB table section created by LinuxBIOS core or another payload, it would automatically simply ignore it.
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...
Well, console output, memory management and all of these have to be realized by every payload itself, thus producing a small code overhead. While offering the ability to make things self contained and thus solid, it also contains the possibility to include new bug sources.. It's really philosophical in an open source project and there's lots of other things to do.
Stefan
-
Mathieu Deschamps -
Stefan Reinauer