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 <nic...@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
ATT53651.config
Description: ATT53651.config
chromeos.fmd
Description: chromeos.fmd
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org