On 05.11.2013 22:11, Duncan Laurie wrote:
On Tue, Nov 5, 2013 at 10:56 AM, Aaron Durbin adurbin@chromium.org wrote:
On Tue, Nov 5, 2013 at 12:52 PM, Stefan Reinauer stefan.reinauer@coreboot.org wrote:
- Aaron Durbin adurbin@chromium.org [131105 18:00]:
On Tue, Nov 5, 2013 at 10:55 AM, Kyösti Mälkki kyosti.malkki@gmail.com 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...
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
-
Kyösti Mälkki