[PROPOSAL] extended payload handling
mdeschamps at mangrove-systems.com
Tue Jun 8 10:43:00 CEST 2004
Le mar 08/06/2004 à 17:00, Stefan Reinauer a écrit :
> * 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.
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
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...
More information about the coreboot