[coreboot] suspend/resume in v3

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Mon Sep 8 02:28:15 CEST 2008


On 08.09.2008 02:06, Kevin O'Connor wrote:
> On Sun, Sep 07, 2008 at 10:59:13PM +0200, Carl-Daniel Hailfinger wrote:
> [...]
>> CAR will write to memory locations below 1M. There are three ways to
>> cope with that:
> [...]
>> 3. Write excessively clever and fragile code which performs a double
>> stack switch during resume.
> [...]
>> 3. Will NOT work for Geode, may not work for Intel and VIA. The existing
>> CAR enabling/disabling code will seem trivial in comparison.
> Why can't the code use a new stack after CAR is disabled?
> To be clear, I think moving the stack would be a bad idea.  However, I
> don't see why the code can't just start using a new stack.
> Right now, the only stack variable that is shared between CAR and
> post-CAR is 'archive' (in stage1_main() ).

Please update your v3 tree. Variables shared between CAR and post-CAR
were introduced with their own framework over 100 revisions ago, but
they were available and used without a formal framework over 270
revisions ago for the printk buffer address.

> I would think one could
> manually copy it from the CAR stack to a post-CAR global variable.
> (Or just rebuild it from scratch.)

See above.

> I'm thinking - one could implement a small assembler trampoline
> function that took two parameters - the new stack location and the
> function to jump to.  The assembler would only need to set %esp and
> jump to the new function.
> This would still require memory under 1MB for car, but at least stage2
> could run with a full stack and globals that run in reserved memory.
> Have I missed something?

Yes. If we can get some memory reserved below 1 MB for CAR, there is no
need to move the stack. Although the stack does grow quite a bit beyond
the CAR area once we are post-CAR, we can easily back up all of lowmem
(or selective chunks of it) in reserved memory at the top of RAM. That
allows us to leave the stack completely alone until we hand off control
to the payload (and we won't call a payload for the S3 resume case).

By the way, here's a nice small problem for you, Kevin: How can we
combine SeaBIOS and suspend-to-RAM? Either SeaBIOS needs to have its own
S3 resume path (machine-specific) or we perform VGA init in coreboot.



More information about the coreboot mailing list