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