On 05.11.2013 22:11, Duncan Laurie wrote:
On Tue, Nov 5, 2013 at 10:56 AM, Aaron Durbin <[email protected]> wrote:
On Tue, Nov 5, 2013 at 12:52 PM, Stefan Reinauer
<[email protected]> wrote:
* Aaron Durbin <[email protected]> [131105 18:00]:
On Tue, Nov 5, 2013 at 10:55 AM, Kyösti Mälkki <[email protected]> wrote:
Hi
A recent discussion I had about google/stout suggested that with the sources
from coreboot git, this board is unable to resume from S3 suspend.
(Argumentation: no EARLY_CBMEM_INIT, no MRC cache, no memory training
results).
I find it hard to believe this problem would affect production units and I
tried to locate the sources where this is fixed from chromium git, without
success.
So this question pops on the surface once again: how do I track down, locate
and download the specific revision of coreboot sources for a Chromebook
production unit? I'd like to see fixes like this upstreamed to coreboot git.
As a related topic: Sandy/ivybridge boards have some low-memory writes on S3
resume, see use of CBMEM_RESUME_BACKUP and CBMEM_BOOT_MODE in romstage.c. Is
there some argumentation why these writes are safe and do not corrupt OS
memory?
It's my understanding that things are just lucky because Linux
reserves that low memory from its use.
Last I checked that memory was marked reserved by coreboot, so Linux
should not use it. Did this change?
I think it's up to the chipset code to mark it as reserved. I don't
recall seeing anything in the sandy/ivy codebase which makes that
happen. Anyone have a boot log of stout? It'd be really easy to check.
The kernel will trim this first 4K even if it does not have an
explicit e820 entry, so it ends up looking like it is reserved in
dmesg even if coreboot is (incorrectly) not marking it reserved.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/setup.c#n752
static void __init trim_bios_range(void)
{
/*
* A special case is the first 4Kb of memory;
* This is a BIOS owned area, not kernel ram, but generally
* not listed as such in the E820 table.
*
* This typically reserves additional memory (64KiB by default)
* since some BIOSes are known to corrupt low memory. See the
* Kconfig help text for X86_RESERVE_LOW.
*/
e820_update_range(0, PAGE_SIZE, E820_RAM, E820_RESERVED);
/*
* special case: Some BIOSen report the PC BIOS
* area (640->1Mb) as ram even though it is not.
* take them out.
*/
e820_remove_range(BIOS_BEGIN, BIOS_END - BIOS_BEGIN, E820_RAM, 1);
sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
}
This should probably be added to the sandybridge/ivybridge resource
allocation to make it explicit and not rely on the kernel to do it for
us.
-duncan
Sorry for the noise, I was fooled by dmesg output:
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
Only after scrolling bit further I find:
e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Table from coreboot is already correct, although I do not understand how
that first entry got extended from 0x500 to 0x1000-1.
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
Kyösti
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
