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
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
-
Gailu Singh -
Stefan Reinauer