[coreboot] Chromebook coreboot sources
kyosti.malkki at gmail.com
Tue Nov 5 21:36:19 CET 2013
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:
>>>>> 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
>>>>> 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
>>>>> 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
>>>> 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.
> 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
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
More information about the coreboot