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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
