[coreboot] suspend/resume in v3

[Carl-Daniel Hailfinger]

On 08.09.2008 04:34, Kevin O'Connor wrote:
> On Mon, Sep 08, 2008 at 02:28:15AM +0200, Carl-Daniel Hailfinger wrote:
>   
>> On 08.09.2008 02:06, Kevin O'Connor wrote:
>>     
>>> 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.
>>     
>
> Okay - I see it's used more frequently now.
>
> I don't think it fundamentally changes much though.  One could copy
> 'struct global_vars' to a permanent location before calling stage2.
>
> Doing so would require global_vars() to evaluate to different
> locations depending on the stage.  Unfortunately, this would limit
> sharing of code between initram and stage2.  Stage2 is compressed
> though - is it still a problem?
>   

We have problems keeping the code bug-free even with one stack location
and the various ABIs we use in coreboot. Having two stacks at different
locations before and after CAR has been ruled out for v3 after long
design and implementation discussions.

> (An alternative would be to pass the gloval_vars address to every
> function that needed it - one could dress it up with macros, but it's
> probably too ugly.)
>   

Ugly indeed.

>>> 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).
>>     
>
> I suspect using ram under 1MB is going to be more problematic than you
> think.  I hope to be proven wrong.  :-)
>   

The docs of various processors (including latest 64bit silicon) state
that the CAR area MUST be below 1 MB. That 1 MB boundary is mentioned
explicitly multiple times, so I guess we have to cope with it.

>> 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.
>>     
>
> I thought S3 restore didn't require a BIOS VGA init.  My understanding
> was - turn on ram and jump to the OS.  I wasn't sure even if stage2
> had to be run.  I'm no expert though.
>   

Linux expects the VGA card to come up initialized on S3 resume. You can
work around "broken" BIOSes by telling Linux to rerun the VGA BIOS on
resume. See the s3_bios kernel parameter for details.

> There is some good info in the acpi spec (do a google search for
> 'ACPIspec30b.pdf') in section 15.1.3.
>   

Will do. Three years ago, I was heavily involved in Linux S3 because my
laptop had its own ideas about resuming with graphics. I fixed my
laptop, but that journey cost me a few months and I am determined to
make sure this doesn't happen with coreboot.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/