[PROPOSAL] extended payload handling

Mathieu Deschamps 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
>   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

More information about the coreboot mailing list