[PROPOSAL] extended payload handling
stepan at openbios.org
Tue Jun 8 09:37:00 CEST 2004
* Mathieu Deschamps <mdeschamps at 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
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.
More information about the coreboot