[coreboot] Memory corruption on Resume from S3 Baytrail

Jin, Huang huang.jin at intel.com
Sat Jan 17 08:58:57 CET 2015


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.


From: coreboot [mailto:coreboot-bounces at 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 at gmail.com> wrote:
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 at 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 at 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.


More information about the coreboot mailing list