Hi, Mr. Marc Jones,
The first question: The stack moved from 0xc8000 to 0x1f8000 is just for CAR. The main coreboot code has its own stack defined in config/coreboot_ram.ld, located below 1M RAM. So, if the CAR doesn't move the stack, only the lowest 1M RAM needs to be stored for S3. My thought is correct or not?
The second question: I mean: I didn't issue the exit-self-fresh command. Actually, I still issued the initialization command, it is strange enough that the content of RAM is kept when resuming S3.
Best Regards
??? Feng Libo @ AMD Ext: 20906 Mobile Phone: 13683249071 Office Phone: 0086-010-62801406
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Tuesday, December 16, 2008 5:50 AM To: Feng, Libo Cc: coreboot@coreboot.org Subject: Re: [coreboot] ACPI S3 with coreboot-v2 on DBM690T
Libo,
Good to see that you are making some progress.
On Thu, Dec 11, 2008 at 2:50 AM, Feng, Libo Libo.Feng@amd.com wrote: ...
- Is it really necessary for CAR to move the stack from 0xc8000 in
cache into 0x1f8000 in RAM at the final stage of CAR? Now that the stack works well in cache, why does CAR move the stack into RAM? For verifying RAM or other stuff?
The stack needs to be moved so that cache and memory can be mapped normally in the main coreboot code.
- When resuming from S3, I initialize RAM again instead of exiting
self-Refresh. Lucky enough, RAM content is also kept intact in this way. I will try the exiting self-refresh later.
My first attempt is to jump into the waking vector in the function of post_cache_as_ram, at this moment, RAM is accessible, I can get the waking vector. However, many devices are not initialized, the system is very unstable, I got different trace every time, the best was as below. So, after stuck a couple of days, I gave up and followed Rodulf's way as above.
A different trace may indicate memory is not a stable as you thought. You really need to do the existing self refresh code. It should not be difficult.
Marc