In my Coreboot build (derived from kblrvp configuration) based on 4.9 label I am seeing that MRC test is run on every boot. From what I can tell, what happens is: 1) On first boot the MRC cache is not found (correct). MRC test is done and the MRC cache is saved successfully. If I pull the BIOS image down, I can see valid contents of the MRC cache where they are supposed to be 2) On the second boot MRC verification fails because rdev_mmap does not have .mmap method in the rdev ops. Since this rdev is based on boot_device_rw_nommap, this seems to be both intended and clearly wrong. 3) At this point MRC test is rerun and is written to the flash *without erasing it first* resulting in corrupted data. 4) Next and all subsequent boots result in reading back corrupt header from MRC cache and a failure followed by retrain.
I was able to hack it by replacing 3 calls to mmap with readat and adding erase before the MRC update, but clearly it is supposed to work, so what am I missing?
The board is fairly close to KBL RVP3 and the changes to coreboot are minimal. FMD file has MRC cache section
I'm open to suggestions
Alex
Hi Alex,
On 04.06.19 22:27, Alex Feinman wrote:
In my Coreboot build (derived from kblrvp configuration) based on 4.9 label I am seeing that MRC test is run on every boot. From what I can tell, what happens is:
- On first boot the MRC cache is not found (correct). MRC test is done
and the MRC cache is saved successfully. If I pull the BIOS image down, I can see valid contents of the MRC cache where they are supposed to be 2) On the second boot MRC verification fails because rdev_mmap does not have .mmap method in the rdev ops. Since this rdev is based on boot_device_rw_nommap, this seems to be both intended and clearly wrong.
this is odd. AFAIK, it should use boot_device_ro (src/arch/x86/ mmap_boot.c).
I'm open to suggestions
Share your code. The FMD format alone provides enough flexibility that it's impossible to tell what could go wrong. Also, your .config might contain some spurious setting (though, I don't see how it could result in using the rdev).
Nico
Hi Niko, thank you for looking into this
If the boot_device_ro from mmap_boot.c is being used, I don't see how the flash content gets mapped into top of the 4GB space. In case of Apollo Lake, there is a special implementation. But for the rest of x86 there is nothing. Is there something I missed in the SKL+ specification that says that the BIOS is mapped into memory automatically? For now if I use boot_device_ro as a backing device for MRC reads, I am getting 0xFF all around, resulting in cache slot treated as uninitialized.
PS How should I provide my .config - attachment or inline? ________________________________________ From: Nico Huber nico.h@gmx.de Sent: Tuesday, June 4, 2019 3:33 PM To: Alex Feinman; coreboot@coreboot.org Subject: Re: [coreboot] MRC cache save/readback failure (SKL/KBL)
Hi Alex,
On 04.06.19 22:27, Alex Feinman wrote:
In my Coreboot build (derived from kblrvp configuration) based on 4.9 label I am seeing that MRC test is run on every boot. From what I can tell, what happens is:
- On first boot the MRC cache is not found (correct). MRC test is done
and the MRC cache is saved successfully. If I pull the BIOS image down, I can see valid contents of the MRC cache where they are supposed to be 2) On the second boot MRC verification fails because rdev_mmap does not have .mmap method in the rdev ops. Since this rdev is based on boot_device_rw_nommap, this seems to be both intended and clearly wrong.
this is odd. AFAIK, it should use boot_device_ro (src/arch/x86/ mmap_boot.c).
I'm open to suggestions
Share your code. The FMD format alone provides enough flexibility that it's impossible to tell what could go wrong. Also, your .config might contain some spurious setting (though, I don't see how it could result in using the rdev).
Nico
Hi Alex,
On 06.06.19 18:43, Alex Feinman wrote:
If the boot_device_ro from mmap_boot.c is being used, I don't see how the flash content gets mapped into top of the 4GB space. In case of Apollo Lake, there is a special implementation. But for the rest of x86 there is nothing. Is there something I missed in the SKL+ specification that says that the BIOS is mapped into memory automatically?
yes, it's traditionally mapped there. Actually, on all current Intel platforms, the BIOS region in flash is mapped there. Apollo Lake needs a little special treatment because a) the BIOS region usually isn't at the end of the flash chip and b) an SRAM replaces the topmost part of the mapping. Not sure where it is documented, maybe in the PCH data- sheet.
PS How should I provide my .config - attachment or inline?
Attachment works.
Nico
I've checked the upper 16 MB - simply dumped the block at 0xff9f0000 (0xff000000 is the last 16 MB + MRC cache region offset 0x9f0000 from the layout file ) where in my image the MRC cache region resides (I can confirm it's there by dumping the image from flash). The data I read from the supposed memory mapping is all 0xff.
fmd and .config files are attached
cbfstool output at the end of the build:
This image contains the following sections that can be manipulated with this tool:
'SI_DESC' (size 4096, offset 0) 'SI_ME' (size 2093056, offset 4096) 'VBLOCK_A' (size 65536, offset 2097152) 'FW_MAIN_A' (size 4063168, offset 2162688) 'RW_FWID_A' (size 64, offset 6225856) 'VBLOCK_B' (size 65536, offset 6225920) 'FW_MAIN_B' (size 4063168, offset 6291456) 'RW_FWID_B' (size 64, offset 10354624) 'RECOVERY_MRC_CACHE' (size 65536, offset 10354688) 'RW_MRC_CACHE' (size 57344, offset 10420224) 'RW_VAR_MRC_CACHE' (size 8192, offset 10477568) 'RW_ELOG' (size 16384, offset 10485760) 'SHARED_DATA' (size 8192, offset 10502144) 'VBLOCK_DEV' (size 8192, offset 10510336) 'RW_VPD' (size 8192, offset 10518528) 'RW_NVRAM' (size 24576, offset 10526720) 'SMMSTORE' (size 262144, offset 10551296) 'RW_LEGACY' (CBFS, size 1769472, offset 10813440) 'RO_UNUSED' (size 40960, offset 12607488) 'RO_FRID' (size 64, offset 12650496) 'RO_FRID_PAD' (size 1984, offset 12650560) 'GBB' (size 978944, offset 12652544) 'RO_VPD' (size 15872, offset 13631488) 'RO_FTW' (size 8192, offset 13885440) 'RO_UNUSE' (size 327680, offset 13893632) 'COREBOOT' (CBFS, size 2555904, offset 14221312)
It is possible to perform either the write action or the CBFS add/remove actions on every section listed above. To see the image's read-only sections as well, rerun with the -w option. CBFSPRINT coreboot.rom
FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 41084 none cpu_microcode_blob.bin 0xa180 microcode 785408 none fallback/ramstage 0xc9e00 stage 94218 none config 0xe0e80 raw 1072 none revision 0xe1300 raw 577 none spd.bin 0xe1580 spd 2048 none wifi_sar_defaults.hex 0xe1dc0 raw 81 none (empty) 0xe1e80 null 280 none fspm.bin 0xe1fc0 fsp 401408 none vbt.bin 0x144000 raw 1168 LZMA (4608 decompressed) cmos_layout.bin 0x144500 cmos_layout 904 none (empty) 0x1448c0 null 1752 none fsps.bin 0x144fc0 fsp 188416 none pci8086,591e.rom 0x173000 optionrom 65536 none fallback/postcar 0x183080 stage 20396 none fallback/dsdt.aml 0x188080 raw 18172 none fallback/payload 0x18c800 simple elf 671666 none (empty) 0x230800 null 210840 none bootblock 0x263fc0 bootblock 49152 none
________________________________________ From: Nico Huber nico.h@gmx.de Sent: Thursday, June 6, 2019 1:28 PM To: Alex Feinman; coreboot@coreboot.org Subject: Re: [coreboot] MRC cache save/readback failure (SKL/KBL)
Hi Alex,
On 06.06.19 18:43, Alex Feinman wrote:
If the boot_device_ro from mmap_boot.c is being used, I don't see how the flash content gets mapped into top of the 4GB space. In case of Apollo Lake, there is a special implementation. But for the rest of x86 there is nothing. Is there something I missed in the SKL+ specification that says that the BIOS is mapped into memory automatically?
yes, it's traditionally mapped there. Actually, on all current Intel platforms, the BIOS region in flash is mapped there. Apollo Lake needs a little special treatment because a) the BIOS region usually isn't at the end of the flash chip and b) an SRAM replaces the topmost part of the mapping. Not sure where it is documented, maybe in the PCH data- sheet.
PS How should I provide my .config - attachment or inline?
Attachment works.
Nico
-
Alex Feinman -
Nico Huber