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 <[email protected]>
Sent: Thursday, June 6, 2019 1:28 PM
To: Alex Feinman; [email protected]
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 -- [email protected] To unsubscribe send an email to [email protected]
