[coreboot] Chromebook coreboot sources

[Kyösti Mälkki]

On 05.11.2013 22:11, Duncan Laurie wrote:
> 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
>


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