Re: [coreboot] fwts MTRR tests fail on ASRock E350M1
On Sat, Aug 8, 2015 at 11:54 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear coreboot folks, following Patrick to test devices with the Firmware Test Suite [1], I built fwts V15.08.00-7-g9ddce1f from the their Git repository [2] and ran it on the ASRock E350M1 with coreboot [3] and SeaBIOS. The first tests failing are the MTRR tests. ``` mtrr: MTRR tests. MTRR overview - Reg 0: 0x - 0x8000 ( 2048 MB) Write-Back Reg 1: 0x8000 - 0xc000 ( 1024 MB) Write-Back Reg 2: 0xc000 - 0xc800 ( 128 MB) Write-Back Reg 6: 0xffc0 - 0x0001 ( 4 MB) Write-Protect Test 1 of 3: Validate the kernel MTRR IOMEM setup. FAILED [MEDIUM] MTRRIncorrectAttr: Test 1, Memory range 0x1 to 0x21eff (System RAM) has incorrect attribute Default (Most probably Uncached). FAILED [MEDIUM] MTRRLackingAttr: Test 1, Memory range 0x1 to 0x21eff (System RAM) is lacking attribute Write-Back. The E350M1 is an AMD system. On those systems there is a TOM2 msr to cover memory above 4GiB as writeback. I don't know what family the cores are in that system, however here is the BKDG link for family 10h: http://support.amd.com/TechDocs/31116.pdf MSRC001_0010 System Configuration Register (SYS_CFG) bits: 22 Tom2ForceMemTypeWB: top of memory 2 memory type write back. Read-write. 1=The default memory type of memory between 4GB and TOM2 is write back instead of the memory type defined by [The MTRR Default Memory Type Register (MTRRdefType)] MSR_02FF[MemType]. For this bit to have any effect, MSR_02FF[MtrrDefTypeEn] must be 1. MTRRs and PAT can be used to override this memory type. 21 MtrrTom2En: MTRR top of memory 2 enable. Read-write. 0=[The Top Of Memory 2 Register (TOM2)] MSRC001_001D is disabled. 1=This register is enabled. And the TOM2 msr: MSRC001_001D Top Of Memory 2 Register (TOM2) 47:23 TOM2[47:23]: second top of memory. Read-write. Specifies the address divides between MMIO and DRAM. This value is normally placed above 4G. From 4G to TOM2 - 1 is DRAM; TOM2 and above is MMIO. See 2.9.3 [Access Type Determination]. This register is enabled by [The System Configuration Register (SYS_CFG)] MSRC001_0010[MtrrTom2En]. If those settings are employed then I'd expect the MTRRs not to cover memory above 4GiB. Test 2 of 3: Validate the MTRR setup across all processors. PASSED: Test 2, All processors have the a consistent MTRR setup. Test 3 of 3: Test for AMD MtrrFixDramModEn being cleared by the BIOS. PASSED: Test 3, No MtrrFixDramModEn error detected. 2 passed, 2 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. ``` I’ll try to look into it in the coming weeks, but if somebody has an idea and a suggestion for a fix, that would be great. Please also comment, if fwts is not correct in this regard.) Thanks, Paul [1] https://wiki.ubuntu.com/Kernel/Reference/fwts [2] git://kernel.ubuntu.com/hwe/fwts [3] commit 6de27da3 (samsung/exynos5250: Enable bootblock console) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New on blogs.coreboot.org: [GSoC] coreboot for ARM64 Qemu – Week #8
A new post titled "[GSoC] coreboot for ARM64 Qemu – Week #8" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/09/gsoc-coreboot-for-arm64-qemu-week-8/ As I had discussed in my last blog post, currently I am onto the debug of the qemu boot. I was intending to use Valgrind tools to detect various memory managements bugs and use that information for my debug. But sadly the information provided by Valgrind was not of much use since it didnt deal with the execution stream of the coreboot code in qemu. I ultimately had to turn to gdb and use it for further debug. This was an initial hiccup, since, as in my last post, building aarch64-linux-gnu-gdb on MacOSX was not straightforward, since there was no direct replacement for the gdb-multiarch. I was able to get this done. I discuss some of the basic steps of how to set it up below. First, we need a couple to packages to build gdb. They are listed below: expat guile texinfo Next, download the aarch64-gdb from here. Now, you need to configure CC to gcc (GNU gcc and not the innate symlink to clang). Then proceed to, $ ./configure --target=aarch64-linux-gnu $ make $ make install If this completes successfully, you would have aarch64-gdb installed on your system correctly. The important thing to remember is to use GNU gcc (=4.9) and not the innate MacOS gcc. To run gdb you must $ aarch64-linux-gnu-gdb The output looks like this : GNU gdb (GDB) 7.9 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-apple-darwin13.3.0 --target=aarch64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word". Now I had gdb working. Then I did started the debug by giving a -s -S while invoking qemu. After this, I need to connect to gdb remotely using (gdb) target remote : 1234 Some of the debug information I received was this : (gdb) target remote :1234 Remote debugging using :1234 0x0200 in ?? () (gdb) run The remote target does not support run. Try help target or continue. (gdb) continue Continuing. ^C Program received signal SIGINT, Interrupt. 0x0200 in ?? () On trying single-step execution on gdb, I received : (gdb) step Cannot find bounds of current function An error like this usually seen when we overflow a buffer and corrupt the stack, the proper return address is destroyed. When the debugger tries to figure out which function the address is in, it fails, because the address is not in any of the functions in the program. On running the simple where on gdb I get [where displays the current line and function and the stack of calls that got you there] (gdb) where #0 0x0200 in ?? () After some unscrambling of the source code using information from gdb, we were pointed to some issues under the stage_entry in src/arch/arm64/stage_entry.S. I am onto re-setting those and continuing the debug further now. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] fwts MTRR tests fail on ASRock E350M1
Dear coreboot folks, following Patrick to test devices with the Firmware Test Suite [1], I built fwts V15.08.00-7-g9ddce1f from the their Git repository [2] and ran it on the ASRock E350M1 with coreboot [3] and SeaBIOS. The first tests failing are the MTRR tests. ``` mtrr: MTRR tests. MTRR overview - Reg 0: 0x - 0x8000 ( 2048 MB) Write-Back Reg 1: 0x8000 - 0xc000 ( 1024 MB) Write-Back Reg 2: 0xc000 - 0xc800 ( 128 MB) Write-Back Reg 6: 0xffc0 - 0x0001 ( 4 MB) Write-Protect Test 1 of 3: Validate the kernel MTRR IOMEM setup. FAILED [MEDIUM] MTRRIncorrectAttr: Test 1, Memory range 0x1 to 0x21eff (System RAM) has incorrect attribute Default (Most probably Uncached). FAILED [MEDIUM] MTRRLackingAttr: Test 1, Memory range 0x1 to 0x21eff (System RAM) is lacking attribute Write-Back. Test 2 of 3: Validate the MTRR setup across all processors. PASSED: Test 2, All processors have the a consistent MTRR setup. Test 3 of 3: Test for AMD MtrrFixDramModEn being cleared by the BIOS. PASSED: Test 3, No MtrrFixDramModEn error detected. 2 passed, 2 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. ``` I’ll try to look into it in the coming weeks, but if somebody has an idea and a suggestion for a fix, that would be great. Please also comment, if fwts is not correct in this regard.) Thanks, Paul [1] https://wiki.ubuntu.com/Kernel/Reference/fwts [2] git://kernel.ubuntu.com/hwe/fwts [3] commit 6de27da3 (samsung/exynos5250: Enable bootblock console) signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
