[coreboot] suspend/resume in v3

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Sun Sep 7 21:18:34 CEST 2008

Rudolf, thanks for giving us that overview. I see that it is a
description of S3 wakeup. Could you perhaps supplement that with a
description of S3 suspend?

Peter, thanks for preserving that info.

On 07.09.2008 19:50, Peter Stuge wrote:
> Discussing on IRC, ruik pointed out that we of course have to
> consider suspend and resume in v3.
> He wrote some great pointers on the topic today and I'm pasting here
> for archival and as food for thought.
> <ruik> CareBear\: the S3 works this way:
> <ruik> 1) get the wakeup info from chipset
> <ruik> 2) in intraphase ask the memory to go out of self refresh (skip train)

intraphase is initram? Would it make sense to have a fast path in
initram for this?

> <ruik> 3) do coreboot chipset init as usual

What about BARs which have been moved by the OS? Should we initialize
them to the values last used by the OS or should we use the values
calculated automatically at startup?

> <ruik> 4) when creating ACPI tables look to that place, in one table there will be OS waking vector
> <ruik> 5) after all done, jump to OS instead of payload, switch A20 on go to real mode and jump
> <ruik> 6) do this all steps in reserved memory, do not corrupt system memory used by OS
> <ruik> 7) minor fix for ACPI dsdt is needed, just one line ;)
> <ruik> CareBear\: just add one line to SLP
> <ruik> similar to bit for S5 and S0
> <ruik> one more caveat
> <ruik> make sure that suspend signal clock from SB is understood by superIO
> <ruik> so superIO wont cut RAM power
> I think 6) in particular deserves some consideration.

6) is really easy with v3. A lot easier than with v2. I think I wrote a
design doc about that one year ago.

However, I am surprised that the SuperI/O acts as a power supply for RAM.



More information about the coreboot mailing list