On Wed, Sep 30, 2015 at 2:29 AM, Paul Menzel paulepanter@users.sourceforge.net wrote:
Dear Aaron,
thank you for the quick reply.
Am Montag, den 28.09.2015, 09:38 -0500 schrieb Aaron Durbin:
On Sun, Sep 27, 2015 at 2:54 PM, Paul Menzel wrote:
building a coreboot image for the ASRock E350M1 with the attached config, having code coverage enabled, I am unable to run the utility `cbmem`.
$ sudo util/cbmem/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 0xb74b6000. Looking for coreboot table at c7f9f000 1048576 bytes. Mapping 1MB of physical memory at 0xffffffffc7f9f000 (requested 0xc7f9f000). ... failed. Mapping 1052671B of physical memory at 0xffffffffc7f9e000. Failed to mmap /dev/mem: Resource temporarily unavailableLinux complains with the messages below.
$ dmesg […] [ 916.233910] x86/PAT: cbmem:2647 conflicting memory types c7f9f000-c809f000 uncached-minus<->write-back [ 916.233927] x86/PAT: reserve_memtype failed [mem 0xc7f9f000-0xc809efff], track uncached-minus, req write-back […]You are going to need to open the /dev/mem file w/ O_SYNC flags because the kernel is marking that range of memory as uncacheable. More info can be found here: https://www.kernel.org/doc/Documentation/x86/pat.txt
I totally missed, that besides selecting code coverage, the Linux kernel was updated to version 4.2 in between. Probably they changed some default.
$ uname -a Linux my-asrocke350m1 4.2.0-1-686-pae #1 SMP Debian 4.2.1-1 (2015-09-25) i686 GNU/Linux# cat /sys/kernel/debug/x86/pat_memtype_list
would be helpful
$ sudo more /sys/kernel/debug/x86/pat_memtype_list PAT memtype list:uncached-minus @ 0xc7fa7000-0xc7fa8000 write-back @ 0xc7fb8000-0xc7fbb000 write-back @ 0xc7fba000-0xc7fbd000
Interesting. The range you requested isn't listed in here. However, the above 3 are which are smack in the middle of region you are requesting. I suspect that's where things are falling over. Do you know what these are? Are they listed in /proc/iomem ? The best visibility we have currently is the e820 below which just has the range starting at 0xc7f9d000 through 0xe0000000. There's some weird fudging the kernel does around the usable memory boundaries so those may not be we coreboot exported. Presumably you have coreboot logs from a previous boot not on this kernel? That might provide some insight as well.
I should also note I didn't go trolling through the kernel to figure out its logic just yet. Just noting what you're finding.
write-combining @ 0xe0040000-0xe0274000 write-combining @ 0xe0274000-0xe0474000 write-combining @ 0xe0474000-0xe0475000 write-combining @ 0xe0478000-0xe0978000 uncached-minus @ 0xf0004000-0xf0005000 uncached-minus @ 0xf0100000-0xf0140000 uncached-minus @ 0xf0140000-0xf0144000 uncached-minus @ 0xf0144000-0xf0148000 uncached-minus @ 0xf0148000-0xf0149000 uncached-minus @ 0xf0149000-0xf014a000 uncached-minus @ 0xf014a000-0xf014b000 uncached-minus @ 0xf014b000-0xf014c000 uncached-minus @ 0xf014b000-0xf014c000 uncached-minus @ 0xf014b000-0xf014c000 uncached-minus @ 0xf014b000-0xf014c000 uncached-minus @ 0xf8088000-0xf8089000 uncached-minus @ 0xfed00000-0xfed01000 uncached-minus @ 0xfed80000-0xfed81000
along with this:
$ for i in /sys/firmware/memmap/*; do echo $(cat $i/type $i/start $i/end); done
$ for i in /sys/firmware/memmap/*; do echo $(sudo cat $i/type $i/start $i/end); done System RAM 0x0 0x9fbff reserved 0x9fc00 0x9ffff reserved 0xf0000 0xfffff System RAM 0x100000 0xc7f9cfff reserved 0xc7f9d000 0xdfffffff reserved 0xf8000000 0xfbffffff System RAM 0x100000000 0x21effffffThanks,
Paul
coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot