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: 13683249071
Office Phone: 0086-010-62801406
-----Original Message-----
From: Rudolf Marek [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2008 4:39 AM
To: Feng, Libo
Cc: [email protected]
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
>
> 1. 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.
>
> 2. 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
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
