[coreboot] Porting to Asus M4A785-M

[Juhana Helovuo]

On Thu, 2010-08-05 at 13:05 -0600, Myles Watson wrote:

> I wouldn't change that.  I think it's easier to leave UMA at the end.
>  
> > With 2048 MB RAM this sets UMA to 0x40000000.
> 
> From your log:
> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000]  BIOS-e820: 0000000000000000 - 0000000000001000 (reserved)
> [    0.000000]  BIOS-e820: 0000000000001000 - 00000000000a0000 (usable)
> [    0.000000]  BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable)
> [    0.000000]  BIOS-e820: 00000000000f0000 - 00000000000f1000 (reserved)
> [    0.000000]  BIOS-e820: 00000000000f1000 - 0000000080000000 (usable)
> 
> Until you see the correct areas reserved in the RAM map for high_tables and
> UMA, there's not much point in booting Linux.  When those areas are reserved
> correctly they will show up in the table.


Ok, now I understand that Linux memory management is overwriting
everything listed in the e820 table as "usable". If coreboot tables are
not listed as reserved or ACPI, they will get corrupted.

The problem is, I have not been able to change the table to show correct
values despite several attempts.

The memory table of coreboot is as follows:

Adding high table area
uma_memory_start=0x70000000, uma_memory_size=0x10000000 
coreboot memory table:
 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
 1. 0000000000001000-000000000009ffff: RAM
 2. 00000000000c0000-000000006ffeffff: RAM
 3. 000000006fff0000-000000006fffffff: CONFIGURATION TABLES
 4. 0000000070000000-000000007fffffff: RESERVED
Wrote coreboot table at: 6fffe000 - 6fffe8d0  checksum eb01
coreboot table: 2256 bytes.
POST: 0x9e
 0. FREE SPACE 70000000 00000000
 1. GDT        6fff0200 00000200
 2. IRQ TABLE  6fff0400 00001000
 3. SMP TABLE  6fff1400 00001000
 4. ACPI       6fff2400 0000bc00
 5. COREBOOT   6fffe000 00002000
Check CBFS header at fffffd2e


This seems quite ok to me: UMA is reserved at the top of RAM and
coreboot tables right before that.

But at the Linux boot log the memory map shows up like this:

[    0.000000] Command line: BOOT_IMAGE=/vmlinuz root=/dev/hda console=tty1 console=ttyS0,0
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 0000000000001000 (reserved)
[    0.000000]  BIOS-e820: 0000000000001000 - 00000000000a0000 (usable)
[    0.000000]  BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable)
[    0.000000]  BIOS-e820: 00000000000f0000 - 00000000000f1000 (reserved)
[    0.000000]  BIOS-e820: 00000000000f1000 - 0000000080000000 (usable)
[    0.000000] max_pfn_mapped = 524288

So the reservations got lost somewhere between Coreboot and Linux. (Grub2?)


The e820 memory map with factory BIOS looks like this:

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
[    0.000000]  BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000006ff90000 (usable)
[    0.000000]  BIOS-e820: 000000006ff90000 - 000000006ffa8000 (ACPI data)
[    0.000000]  BIOS-e820: 000000006ffa8000 - 000000006ffd0000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000006ffd0000 - 0000000070000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
[    0.000000] Entering add_active_range(0, 0, 158) 0 entries of 3200 used
[    0.000000] Entering add_active_range(0, 256, 458640) 1 entries of 3200 used
[    0.000000] max_pfn_mapped = 1048576
[    0.000000] init_memory_mapping
  [...]
[    0.000000] Scanning NUMA topology in Northbridge 24
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-000000006ff90000
[    0.000000] Entering add_active_range(0, 0, 158) 0 entries of 3200 used
[    0.000000] Entering add_active_range(0, 256, 458640) 1 entries of 3200 used
[    0.000000] Bootmem setup node 0 0000000000000000-000000006ff90000


There is no UMA reserved, but ACPI data area is.

UMA is set aside only later, as directed by ACPI tables, I presume:

[    0.331068] pnp: PnP ACPI init
[    0.331068] ACPI: bus type pnp registered
[    0.331068] pnp 00:00: parse allocated resources
[    0.331068] pnp 00:00:   add io  0xcf8-0xcff flags 0x1
[    0.331068] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
[    0.331068] pnp 00:01: parse allocated resources
[    0.331068] pnp 00:01:   add mem 0x0-0xffffffffffffffff flags 0x10000000
[    0.331068] pnp 00:01:   add mem 0x70000000-0x7fffffff flags 0x0
[    0.331068] pnp 00:01: PNP0c02: calling quirk_system_pci_resources+0x0/0x15c



Another interesting difference is that for some reason the "Bootmem"
module of Linux uses memory only up to 0x6ff90000 with factory BIOS,
thus leaving alone ACPI data area and UMA.

With Coreboot, Linux "Bootmem" decides to use up to 0x80000000, which
seems to corrupt Coreboot tables.

I tried to protect the tables and UMA with kernel memmap-command line
parameters to specify the location of coreboot tables at 0x6fff0000
(64k) and "reserved" for UMA at 0x70000000 (256M), but then Bootmem
module somehow decides to use only 0x10000000 bytes of memory, and then
it finds that initramdisk is loaded above the top of that memory.

Additionally, kernel command line parameter memmap=256M$0x70000000
results in a line in e820 RAM map, but the range is printed as "usable"
instead of "reserved". This is very strange, since in the kernel source
code areas specified with "$" are clearly marked as reserved.

It is still somewhat unclear where and how all of these memory maps are
transmitted from Coreboot to Linux. I could not find the callback for
BIOS e820 calls in Coreboot sources.

Best regards,
Juhana Helovuo