Re: [coreboot] ACPI S3

[Feng, Libo]

Hi, all,

Thank you very much. Such a lot of information pours to me. It will take quite a while for me to digest. ;-)

The below are my thought and some experiment results, the platform is: AMD dbm690t mainboard mounted with Turion 64x2, Rs690 and Sb600. OS is Fedora 6 shipping with the 2.6.18 kernel. ACPI spec is 3.0a

1. According to the ACPI spec, prior to transitioning to S3, OS saves a lot of processor and devices' context, flushes and invalids cache. Please reference to 15.1.6. I will check the kernel source to find what are exactly saved.

2. In 15.1.3.1, Only the four items below need to be done by BIOS when waking up:
    1. Program the initial boot configuration of the CPU (such as the MSR and MTRR registers).
    2. Initialize the cache controller to its initial boot size and configuration.
    3. Enable the memory controller to accept memory accesses.
    4. Jump to the waking vector.

3. In coreboot, within cache_as_ram_auto.c, the cache is enabled. Not all MTRR but some are set up, precisely, MSR 0269h MTRfix4K_C8000 Register and MSR 02FFh MTRRdefType Register. The memory controller is setup, too. So if we don’t copy the data in cache and the coreboot code into RAM in the function of post_cache_as_ram, the content of RAM keeps intact since the last transition of S3.

4. Then, is RAM accessible in cache_as_ram_auto.c now? I did some experiments. FACS table can be found, the waking vector can be fetched. With HDT( AMD debug tool ), I can also find the waking source code at 0x2000 in RAM, identical with /arch/x86_64/kernel/acpi/wakeup.S. So, I think after initializing the memory controller, RAM has exited the self-refresh state.

5. At this point, Power Management Register is also accessible, strange but true. So I can decide it is normal boot or waking by reading Sleep Type in AcpiPm1CntBlk.

6. Some MSR and MTRR can be stored in CMOS RAM during the previous normal boot, now I can read back them from CMOS RAM.

7. After all these, jumping to the waking vector and handing the control to OS, OS will restore system and wake up.

I am not sure this can work or not yet. So, any comments are appreciated. Thanks again.

Best Regards

丰立波 Feng Libo @ AMD  Ext: 20906
Mobile Phone: [phone]
Office Phone: [phone]

-----Original Message-----
From: Rudolf Marek [mailto:[e-mail]] 
Sent: Thursday, November 13, 2008 4:39 AM
To: Feng, Libo
Cc: [e-mail]
Subject: Re: [coreboot] ACPI S3

Feng, Libo napsal(a):
> Hi, all,
>
> I am trying to implement the ACPI S3 on coreboot. I have some questions:

Hi, I have posted some experimental version year ago. It is quite tricky to get it working correctly because coreboot overwrittes lot of memory.

Here is the patch:
http://www.coreboot.org/pipermail/coreboot/2008-January/028787.html

Worked for K8T890 and K8 DDR revE

Here is described in the steps what needs to be done:
http://www.coreboot.org/pipermail/coreboot/2008-September/038539.html
> Where is the proper place to check the sleep type in the power
>
> register? Now I check it just prior to disabling the cache as RAM, for 
> not ruining the RAM.

Problem is that you need to setup again some devices which are not setup by OS. 
Like memory controller DDR and chipset low level stuff.

ACPI allows to wakeup in state like fresh boot, therefore I just let coreboot run again and then jump not to payload but to previously saved waking vector.

Problem only is not to overwrite the memory. I solved that by instructing the kernel not to use the low memory at all. Except one page for the trampoline code from your mail.
> How to jump into the wakeup_start in x86_64/kernel/acpi/wakeup.S?
>
> The code is in real mode, how does coreboot jump from the protected 
> mode to the entry? In my case, the wakeup_start points to the physical 
> address 0x2000, from there some real mode code reside. How to jump to the code.

There is reset vector in some DSDT table. Check mine original patch.

For which chipset/processor are you planning that?

Rudolf