[coreboot] same with opensuse 11.1 kernel from bootcd

Stefan Reinauer stepan at coresystems.de
Sat Feb 21 01:57:11 CET 2009


Kevin O'Connor wrote:
> Hi Stefan,
>
> Can I CC the coreboot mailing list on this?  Other people may run into
> similar issues.
>   
CCed.

> On Thu, Feb 19, 2009 at 08:45:28PM +0100, Stefan Reinauer wrote:
>   
>> And here is our e820 map as seen by SeaBIOS:
>>
>> e820 map has 5 items:
>>   0: 0000000000000000 - 000000000009fc00 = 1
>>   1: 000000000009fc00 - 00000000000a0000 = 2
>>   2: 00000000000f0000 - 0000000000100000 = 2
>>   3: 0000000000100000 - 000000003f7f0000 = 1
>>   4: 000000003f7f0000 - 0000000040000000 = 2
>> final bios_table_addr: 0x000f9f80 (used 18%)
>>
>> Noticably 0x0 - 0x9fc00 are "usable" despite coreboot table being at
>> 0x500. BAD
>>     
>
> One must not reserve any memory between 0x0-0x9fc00 in the e820 -
> otherwise all sorts of programs (eg, grub) get terribly confused.
>
>   
>> Noticably 0xa0000 - 0xeffff are completely missing in the list
>>     
>
> It needs to be that way - otherwise Windows gets confused.
>   
Ah interesting! Maybe we should put that knowledge on some Wiki page?

>> Noticably the PCIe window 0xf0000000 - f4000000 is not in the list as
>> reserved
>>     
>
> Hrmm.  I've never seen that reserved before.  Typically, the e820 is
> designed to map memory - if its not memory (eg, mmio space) then I
> don't think it should be in the e820.
>   
Today's systems put a lot of stuff in the e820. ACPI tables, some parts
of MMIO space, etc.

The resource above, the MMCFG windows, particularly needs to be in the
e820 table because otherwise Linux will refuse to treat PCIe devices as
PCIe and will just treat them as PCI instead, notifying the user that
the BIOS is buggy because the MMCFG area is only in ACPI but not in e820.


>> Noticably there is one shared entry for the "high tables" space 3f7f0000
>> - 0x3f800000 and vga memory 0x3f800000-0x40000000
>>     
>
> SeaBIOS will auto-merge like areas.  There should be no harm in this.
>   

There is none.

>> Now, which one is the culprit? Any of them?
>>     
>
> I don't see an issue.  The AMI bios log you provided showed a similar
> map.
>
> One thing that is missing is the rom at itself 00000000ffb00000 -
> 0000000100000000.  It would be nice if coreboot added this to the
> coreboot memory table.  (SeaBIOS can't really add it, because SeaBIOS
> wont know how big the rom chip is.)
>   
Yes,.. coreboot should export quite some more stuff. I will try to look
into this for the PCIe MMCFG stuff,.. I'll try to add the ROM, too.
Though the ROM size might not be known to coreboot. ROM_SIZE might be
insufficient because it lacks the option rom space in v2. We could probe
for the ROM but I'm not sure we want that. Maybe we have to solve option
roms differently in v2.

Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866





More information about the coreboot mailing list