[coreboot] Chromebook coreboot sources

[Duncan Laurie]

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