Gailu,
I reproduced the same problem with Baytrail FSP. The memory "corrupted" starting 0x1000 after S3 resume is caused by reloading the VGA option rom. There is a Kconfig option called S3_VGA_ROM_RUN to skip reloading. Please refer to this change http://review.coreboot.org/#/c/715/ for additional information.
Hope this solves the problem without reserving 64KB memory.
Thanks, Aaron
From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Gailu Singh Sent: Wednesday, December 10, 2014 3:04 AM To: Stefan Reinauer Cc: coreboot Subject: Re: [coreboot] Memory corruption on Resume from S3 Baytrail
Problem resolved by reserving initial 64K memory. Thanks to Stefan for his help.
On Wed, Dec 10, 2014 at 11:12 AM, Gailu Singh gailu96@gmail.com wrote: Hi, In coreboot developer manual memory map section (http://www.coreboot.org/Developer_Manual/Memory_map) there is specific mention of low memory.
0x00000 - 0x9FFFF: Low 640kB. Should not be clobbered on S3 suspend/resume (exceptions?) How do I tell Linux not to use this memory? I tried linux kernel argument memap=640K@0x0 to reserve the space but my kernel does not boot with that. What changes are expected in Linux kernel configuration for S3 suspend/resume to work smoothly with coreboot?
On Sun, Nov 23, 2014 at 12:54 PM, Stefan Reinauer stefan.reinauer@coreboot.org wrote: On 11/19/14 11:36 AM, Gailu Singh wrote: Hi Experts,
I am using Baytrail SoC board (Bayleybay CRB) and testing suspend/resume from Linux (kernel 3.10). I can suspend with pm-suspend and resume with power button; however after resuming I get following logs in Linux Corrupted low memory at c0001004 (1004 phys) = 0008eaea Corrupted low memory at c0001008 (1008 phys) = b0606600 ... Corrupted low memory at c00018fc (18fc phys) = 000008ea
This seems to be caused by coreboot as I do not see these logs if I use BIOS instead of coreboot. Is it true that during resume coreboot uses RAM portion already mapped by Linux and thus corrupting it. How to I avoid the RAM conflict?
Looks like coreboot (or FSP) is overwriting this memory with some trampoline code.
One (ugly) way to fix this would be to just reserve the space in the memory table. The better way would be to track down where this is actually happening and fix it there.
Stefan