On Fri, Oct 30, 2015 at 9:19 AM, Ben Gardner gardner.ben@gmail.com wrote:
cbmem attempts to map 1 MB of memory to read the CB tables. This is failing on my board due to the PAT configuration under Linux. If I boot Linux with "nopat", the issue goes away.
I am using the upstream coreboot and SeaBIOS with a custom board based on the bayleybay_fsp/fsp_baytrail and Linux 4.2.
~ # ./cbmem -V -l Looking for coreboot table at 0 1048576 bytes. Mapping 1MB of physical memory at 0x0 (requested 0x0). Found! coreboot table entry 0x11 Found forwarding entry. Unmapping 1MB of virtual memory at 0x7fee18224000. Looking for coreboot table at 7ad9f000 1048576 bytes. Mapping 1MB of physical memory at 0x7ad9f000 (requested 0x7ad9f000). ... failed. Mapping 1052671B of physical memory at 0x7ad9e000. Failed to mmap /dev/mem: Resource temporarily unavailable ~ # dmesg | tail -n 4 [ 221.700621] x86/PAT: cbmem.orig:1058 conflicting memory types 7ad9f000-7ae9f000 uncached-minus<->write-back 7adb8000-7adbc000 [ 221.705419] x86/PAT: reserve_memtype failed [mem 0x7ad9f000-0x7ae9efff], track write-back, req write-back [ 221.710435] x86/PAT: cbmem.orig:1058 conflicting memory types 7ad9e000-7ae9f000 uncached-minus<->write-back 7adb8000-7adbc000 [ 221.715501] x86/PAT: reserve_memtype failed [mem 0x7ad9e000-0x7ae9efff], track write-back, req write-back ~ # cat /sys/kernel/debug/x86/pat_memtype_list PAT memtype list: uncached-minus @ 0x7ada7000-0x7ada8000 write-back @ 0x7adb8000-0x7adbc000 write-back @ 0x7adbb000-0x7adbd000 write-back @ 0x7addd000-0x7adde000 uncached-minus @ 0x80600000-0x80601000 uncached-minus @ 0x80601000-0x80602000 uncached-minus @ 0x80602000-0x80603000 write-combining @ 0xc0000000-0xd0000000 ... snip ...
From the Linux kernel log: MTRR variable ranges enabled: 0 base 0FF800000 mask FFF800000 write-protect 1 base 000000000 mask F80000000 write-back 2 base 07B000000 mask FFF000000 uncachable 3 base 07C000000 mask FFC000000 uncachable
I'm not sure how to read MTRR ranges, but it looks like the cbtable falls in the MTRR 1 with type write-back.
From the SeaBIOS log: e820 map has 15 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 000000007ad8e000 = 1 RAM 4: 000000007ad8e000 - 0000000080000000 = 2 RESERVED 5: 00000000e0000000 - 00000000f0000000 = 2 RESERVED ... snip ...
The issue appears to be that the coreboot table memory is marked as uncached-minus and then Linux (?) is marking the ACPI tables as write-back. The 1 MB size is overlapping the ACPI tables. That makes mmap attempts of the whole coreboot table to fail due to the mismatched memory types.
I have an older version of coreboot from Sage that does not have this issue. The difference is that the first uncached-minus entry is not present.
On the Sage-based (4.0) coreboot image: ~ # cat /sys/kernel/debug/x86/pat_memtype_list PAT memtype list: write-back @ 0x7add1000-0x7add2000 write-back @ 0x7add4000-0x7add9000 write-back @ 0x7adda000-0x7addc000 uncached-minus @ 0x7ade2000-0x7ade3000 write-combining @ 0xc0000000-0xd0000000 ... snip ...
So, I'm trying to figure out a few things:
- Where does Linux get the PAT table from? The e820 map?
It's generated a runtime based on the requests the kernel makes for specific mapping.
- What piece of code sets the coreboot table as uncached-minus?
The kernel does it. e820 is sort of a poor indicator for memory type. It merges the concept of address space usage and type but it doesn't do a very good job at it.
- Why is that range set as uncached-minus? Would write-back work?
Please see this thread: http://www.coreboot.org/pipermail/coreboot/2015-September/080381.html
The actual issue stems from http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/driver... which maintains a persistent mapping of smbios tables. It uses dmi_remap() which is '#define dmi_remap ioremap' which is where the uncached-minus PAT entry comes from. It should be using the same mechanism as the ACPI table mappings which uses ioremap_cache().
Hope that helps.
-Aaron