Somewhere in the back of my mind, I think I recall it was a design goal that we support returning control back to v3 from the payload and loading an alternate payload or panicing sanely.
Is this still a legitimate goal for v3? If so, how much of the original environment needs to be restored before the payload returns control? I ask because I'm finishing up the last touches of the libpayload BSD rewrite, and this is really the last thing I need to worry about.
Jordan
IMO, It would be a good idea to have this functionality.
It is not always possible to return to the state prior to jumping to the payload. This is because you do not have any control over where the problem in the load of the "next" image happens.
It might be interesting to have an error code of some type returned so that coreboot can take a make a decision on what to do next. For example if it fails because of some hardware item, it should prob not try to load an alternate image, but if a crc check of an image fails, then an alternate load would be possible.
In doing this for embedded systems, I have never assumed that control would be returned with a "known" state and always did some basic reinit (SP, etc..) so that I would not crash myself.
Just my 2 cents...
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Jordan Crouse wrote:
Somewhere in the back of my mind, I think I recall it was a design goal that we support returning control back to v3 from the payload and loading an alternate payload or panicing sanely.
Is this still a legitimate goal for v3? If so, how much of the original environment needs to be restored before the payload returns control? I ask because I'm finishing up the last touches of the libpayload BSD rewrite, and this is really the last thing I need to worry about.
Jordan
On Fri, Mar 14, 2008 at 08:32:05AM -0600, Jordan Crouse wrote:
Somewhere in the back of my mind, I think I recall it was a design goal that we support returning control back to v3 from the payload and loading an alternate payload or panicing sanely.
Hm. I think I recall discussion about multiple "payloads" in a lar.
Is this still a legitimate goal for v3?
I am very hesitant.
As was hinted to, it's not possible to guarantee all state so best not try. With returning comes administration, I much prefer going for the strictly linear execution flow.
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
//Peter
On 14.03.2008 19:51, Peter Stuge wrote:
On Fri, Mar 14, 2008 at 08:32:05AM -0600, Jordan Crouse wrote:
Somewhere in the back of my mind, I think I recall it was a design goal that we support returning control back to v3 from the payload and loading an alternate payload or panicing sanely.
Hm. I think I recall discussion about multiple "payloads" in a lar.
Indeed. However, that was a while ago and I have no idea whether the project died. IIRC Uwe or another GSoC student was active in that direction.
Is this still a legitimate goal for v3?
I am very hesitant.
As was hinted to, it's not possible to guarantee all state so best not try. With returning comes administration, I much prefer going for the strictly linear execution flow.
As a bare minimum to support returning payloads, we'd have to verify that contents of the stack and other coreboot-generated memory (like e820 tables) are still OK. Not something I'd like to do. However, if one "master" payload takes care of all that stuff, I'm fine. Then again, that would put the master payload in the position to handle returning slave payloads.
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
Agreed.
Regards, Carl-Daniel
Peter Stuge wrote:
On Fri, Mar 14, 2008 at 08:32:05AM -0600, Jordan Crouse wrote:
Somewhere in the back of my mind, I think I recall it was a design goal that we support returning control back to v3 from the payload and loading an alternate payload or panicing sanely.
Hm. I think I recall discussion about multiple "payloads" in a lar.
Is this still a legitimate goal for v3?
I am very hesitant.
As was hinted to, it's not possible to guarantee all state so best not try. With returning comes administration, I much prefer going for the strictly linear execution flow.
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 "stage2"
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.
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 "stage2"
Mh, yes and no. It comes back to definition of what state can be expected.
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.
//Peter
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 "stage2"
Mh, yes and no. It comes back to definition of what state can be expected.
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, does it?
Stefan
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Marc Karasek -
Peter Stuge -
Stefan Reinauer