[coreboot] Returning control to v3 from the payload
stepan at coresystems.de
Mon Mar 17 01:44:41 CET 2008
Peter Stuge wrote:
> On Mon, Mar 17, 2008 at 12:46:36AM +0100, Stefan Reinauer wrote:
>> Returning only for the matter of loading the next payload. We will
>> need multiple payloads in the future for many things.
>> In fact, we do have that technology already. Our first payload is
> Mh, yes and no. It comes back to definition of what state can be
This can only work if all payloads except the last one are
"well-behaving". Nobody would expect to run any arbitrary payload, ie an
OS, except for the very last payload that never returns.
>>> The way I could like it is if it's all done by a separate payload,
>>> that sets up an environment and can run many other programs.
>>> I don't like coreboot doing it.
>>> Think kernel vs /sbin/init
>> /sbin/init is slow and bloated. ;-) My first thought.
> The point is that it can be replaced with runit or svscan without
> kernel modifications.
I think what we need is more comparable to the process scheduler (yes,
that can be exchanged, too).
It kind of belongs into the kernel, even though one could think of a
much simpler solution if the plan is to run only a single process
anyways (like an mp3 player or a motor control application)
We have a mechanism to jump into "payloads" and return from them already
-- and I think we should be careful to make sure this works for many
more such payloads not only "stage2". Plugging another layer will not
make things easier and gain us almost nothing, because we carry the
mechanism to do so anyways.
But before we're getting philosophic -- is there any estimate why
returning from a well-behaving blob can't work? It doesn't need to do
much except jump to the address noted on the very bottom of the stack,
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 249 bytes
Desc: OpenPGP digital signature
More information about the coreboot