On Fri, Oct 30, 2015 at 9:19 AM, Ben Gardner <[email protected]> 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: > > 1) 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. > > 2) 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. > > 3) 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/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
