$ cat defconfig ... CONFIG_ADD_FSP_BINARIES=y ...
There is *no* "fspt.bin" file in this chromebook recovery bios file used as source.
$ make ... src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file or directory #include <FsptUpd.h> ^~~~~~~~~~~ compilation terminated. make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 1
What Makefile is that? There is no such line 379.
$ find -name FsptUpd.h ... ./3rdparty/fsp/ApolloLakeFspBinPkg/Include/FsptUpd.h ...
$ less src/soc/intel/alderlake/Kconfig ... config FSP_HEADER_PATH string "Location of FSP headers" default "src/vendorcode/intel/fsp/fsp2_0/alderlake/"
$ less src/drivers/intel/fsp2_0/Kconfig ...
config FSP_T_FILE string "Intel FSP-T (temp RAM init) binary path and filename" if !FSP_FULL_FD depends on ADD_FSP_BINARIES depends on FSP_CAR default "$(obj)/Fsp_T.fd" if FSP_FULL_FD help The path and filename of the Intel FSP-T binary for this platform.
$ make nconfig ... > Generic Drivers ... (src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers
How did that get there? Not me...
$ ll src/vendorcode/intel/fsp/fsp2_0/glk total 116 drwxr-x--- 2 james james 4096 Oct 29 2020 . drwxr-x--- 9 james james 4096 Jun 14 19:04 .. -rw-r----- 1 james james 45977 Oct 29 2020 FspmUpd.h -rw-r----- 1 james james 57332 Oct 29 2020 FspsUpd.h -rw-r----- 1 james james 1967 Oct 29 2020 FspUpd.h
Why is src/soc/intel/apollolake/fspcar.c being built here? It seems that no fspt.bin file is needed.
James
FSP-T isn't used for APL/GLK Chromebooks. Sounds like your .config is selecting something it shouldn't. run `make savedefconfig` then post the contents of the defconfig. Possible CONFIG_USE_APOLLOLAKE_FSP_CAR is selected when it shouldn't be.
On Mon, Jun 21, 2021 at 9:17 PM James Feeney james@nurealm.net wrote:
$ cat defconfig ... CONFIG_ADD_FSP_BINARIES=y ...
There is *no* "fspt.bin" file in this chromebook recovery bios file used as source.
$ make ... src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file or directory #include <FsptUpd.h> ^~~~~~~~~~~ compilation terminated. make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 1
What Makefile is that? There is no such line 379.
$ find -name FsptUpd.h ... ./3rdparty/fsp/ApolloLakeFspBinPkg/Include/FsptUpd.h ...
$ less src/soc/intel/alderlake/Kconfig ... config FSP_HEADER_PATH string "Location of FSP headers" default "src/vendorcode/intel/fsp/fsp2_0/alderlake/"
$ less src/drivers/intel/fsp2_0/Kconfig ...
config FSP_T_FILE string "Intel FSP-T (temp RAM init) binary path and filename" if !FSP_FULL_FD depends on ADD_FSP_BINARIES depends on FSP_CAR default "$(obj)/Fsp_T.fd" if FSP_FULL_FD help The path and filename of the Intel FSP-T binary for this platform.
$ make nconfig ... > Generic Drivers ... (src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers
How did that get there? Not me...
$ ll src/vendorcode/intel/fsp/fsp2_0/glk total 116 drwxr-x--- 2 james james 4096 Oct 29 2020 . drwxr-x--- 9 james james 4096 Jun 14 19:04 .. -rw-r----- 1 james james 45977 Oct 29 2020 FspmUpd.h -rw-r----- 1 james james 57332 Oct 29 2020 FspsUpd.h -rw-r----- 1 james james 1967 Oct 29 2020 FspUpd.h
Why is src/soc/intel/apollolake/fspcar.c being built here? It seems that no fspt.bin file is needed.
James _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
defconfig below, but:
$ grep -i fsp_car defconfig CONFIG_USE_APOLLOLAKE_FSP_CAR=y
$ grep -i fsp_car .config CONFIG_USE_APOLLOLAKE_FSP_CAR=y CONFIG_FSP_CAR=y
Hmm - I must have done that because it sounded "safe". Which of these choices is "correct"?
src/soc/intel/apollolake/Kconfig
choice prompt "Cache-as-ram implementation" default CAR_CQOS if !SOC_INTEL_GEMINILAKE default CAR_NEM help This option allows you to select how cache-as-ram (CAR) is set up.
config CAR_NEM bool "Non-evict mode" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_NEM help Traditionally, CAR is set up by using Non-Evict mode. This method does not allow CAR and cache to co-exist, because cache fills are block in NEM mode.
config CAR_CQOS bool "Cache Quality of Service" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_CQOS help Cache Quality of Service allows more fine-grained control of cache usage. As result, it is possible to set up portion of L2 cache for CAR and use remainder for actual caching.
config USE_APOLLOLAKE_FSP_CAR bool "Use FSP CAR" select FSP_CAR help Use FSP APIs to initialize & tear down the Cache-As-Ram.
endchoice
"Cache Quality of Service" seems more functional than "Non-Evict mode", but is it "better"?
Selecting *either* CONFIG_CAR_CQOS=y or the default CONFIG_CAR_NEM=y, the compile seems mostly successful, but then ends the same, with:
... Platform is: glk File build/coreboot.pre is 16777216 bytes Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000 make: *** [src/southbridge/intel/common/firmware/Makefile.inc:39: add_intel_firmware] Error 1
I need help with that.
Also, though I'm not sure what this does, coreboot does not like my enabling CONFIG_EC_GOOGLE_CHROMEEC_RTC, which then gives:
/var/src/coreboot/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/bootblock/ec/google/chromeec/ec.o: in function `rtc_get': /var/src/coreboot/coreboot/src/ec/google/chromeec/ec.c:776: multiple definition of `rtc_get'; build/bootblock/drivers/pc80/rtc/mc146818rtc.o:/var/src/coreboot/coreboot/src/drivers/pc80/rtc/mc146818rtc.c:225: first defined here make: *** [src/arch/x86/Makefile.inc:92: build/cbfs/fallback/bootblock.debug] Error 1
By the way, this chromebook recovery file includes a distinct SAR file that can be extracted from the COREBOOT section, but the SAR file-path option is not present in the config menu, using the current Kconfig:
src/drivers/wifi/generic/Kconfig
config USE_SAR bool default n help Enable it when wifi driver uses SAR configuration feature. ...
config WIFI_SAR_CBFS_FILEPATH string "The cbfs file which has WIFI SAR defaults" depends on USE_SAR default ""
Adding any kind of "prompt text" after "bool" causes the option to appear, and then the SAR file-path can be added.
Is this a mistake in the Kconfig? Or, what should be done with this SAR file?
Coreboot does seem to properly include my SAR file, since the coreboot.pre wifi_sar_defaults.hex file exactly matches the SAR file I specified in the WIFI_SAR_CBFS_FILEPATH.
Thanks James
$ cat defconfig CONFIG_ANY_TOOLCHAIN=y CONFIG_VENDOR_GOOGLE=y CONFIG_MAINBOARD_VENDOR="Octopus" CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Coreboot" # CONFIG_POST_IO is not set CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_USE_LEGACY_8254_TIMER=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CAR_CQOS=y # CONFIG_PAVP is not set CONFIG_X2APIC_RUNTIME=y CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_VALIDATE_INTEL_DESCRIPTOR=y CONFIG_ME_REGION_ALLOW_CPU_READ_ACCESS=y CONFIG_RUN_FSP_GOP=y CONFIG_TPM_PPI=y CONFIG_USE_SAR=y CONFIG_WIFI_SAR_CBFS_FILEPATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/wifi_sar-bluebird.hex" CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y CONFIG_COREINFO_SECONDARY_PAYLOAD=y CONFIG_MEMTEST_SECONDARY_PAYLOAD=y
$ util/cbfstool/cbfstool build/coreboot.pre print FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 59136 none cpu_microcode_blob.bin 0xe800 microcode 148480 none intel_fit 0x32c40 raw 80 none fallback/ramstage 0x32cc0 stage 110054 LZMA (257508 decompressed) config 0x4db00 raw 1184 none revision 0x4dfc0 raw 722 none build_info 0x4e2c0 raw 100 none fallback/dsdt.aml 0x4e380 raw 13347 none pt 0x51800 raw 20480 none pdpt 0x56840 raw 32 none dmic-2ch-48khz-16b.bin 0x56880 raw 3048 none dmic-4ch-48khz-16b.bin 0x574c0 raw 3048 none max98357-render-2ch-48khz-24b.bin 0x58100 raw 116 none dialog-2ch-48khz-24b.bin 0x581c0 raw 100 none fspm.bin 0x58280 fsp 417792 none vbt.bin 0xbe2c0 raw 1334 LZMA (5632 decompressed) wifi_sar_defaults.hex 0xbe840 raw 119 none (empty) 0xbe900 null 932 none fsps.bin 0xbecc0 fsp 192512 none fallback/postcar 0xedd00 stage 20388 none img/coreinfo 0xf2d00 simple elf 54609 none fallback/payload 0x100280 simple elf 249347 none img/memtest 0x13d0c0 simple elf 47497 none (empty) 0x148a80 null 3234276 none bootblock 0x45e480 bootblock 10288 none
On 6/22/21 8:17 AM, Matt DeVillier wrote:
FSP-T isn't used for APL/GLK Chromebooks. Sounds like your .config is selecting something it shouldn't. run `make savedefconfig` then post the contents of the defconfig. Possible CONFIG_USE_APOLLOLAKE_FSP_CAR is selected when it shouldn't be.
On Mon, Jun 21, 2021 at 9:17 PM James Feeney james@nurealm.net wrote:
$ cat defconfig ... CONFIG_ADD_FSP_BINARIES=y ...
There is *no* "fspt.bin" file in this chromebook recovery bios file used as source.
$ make ... src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file or directory #include <FsptUpd.h> ^~~~~~~~~~~ compilation terminated. make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 1
What Makefile is that? There is no such line 379.
$ find -name FsptUpd.h ... ./3rdparty/fsp/ApolloLakeFspBinPkg/Include/FsptUpd.h ...
$ less src/soc/intel/alderlake/Kconfig ... config FSP_HEADER_PATH string "Location of FSP headers" default "src/vendorcode/intel/fsp/fsp2_0/alderlake/"
$ less src/drivers/intel/fsp2_0/Kconfig ...
config FSP_T_FILE string "Intel FSP-T (temp RAM init) binary path and filename" if !FSP_FULL_FD depends on ADD_FSP_BINARIES depends on FSP_CAR default "$(obj)/Fsp_T.fd" if FSP_FULL_FD help The path and filename of the Intel FSP-T binary for this platform.
$ make nconfig ... > Generic Drivers ... (src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers
How did that get there? Not me...
$ ll src/vendorcode/intel/fsp/fsp2_0/glk total 116 drwxr-x--- 2 james james 4096 Oct 29 2020 . drwxr-x--- 9 james james 4096 Jun 14 19:04 .. -rw-r----- 1 james james 45977 Oct 29 2020 FspmUpd.h -rw-r----- 1 james james 57332 Oct 29 2020 FspsUpd.h -rw-r----- 1 james james 1967 Oct 29 2020 FspUpd.h
Why is src/soc/intel/apollolake/fspcar.c being built here? It seems that no fspt.bin file is needed.
James _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I'm not sure why you enabled so many things not selected in my defconfig -- that's your issue. Use:
CONFIG_VENDOR_GOOGLE=y CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_RUN_FSP_GOP=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y
save as .config, then make olddefconfig.
CAR NEM (non-evict mode) is default, leave that.
No reason to select ChromeEC RTC, it's not supported.
WiFi SAR is only used by ChromeOS, only selectable when CONFIG_CHROMEOS=y
secondary payloads are almost certainly not useful with u-boot as primary payload.
I don't get any size mismatch errors when building for CASTA using the default FMAP. Have you modified your IFD at all?
On Tue, Jun 22, 2021 at 4:10 PM James Feeney james@nurealm.net wrote:
defconfig below, but:
$ grep -i fsp_car defconfig CONFIG_USE_APOLLOLAKE_FSP_CAR=y
$ grep -i fsp_car .config CONFIG_USE_APOLLOLAKE_FSP_CAR=y CONFIG_FSP_CAR=y
Hmm - I must have done that because it sounded "safe". Which of these choices is "correct"?
src/soc/intel/apollolake/Kconfig
choice prompt "Cache-as-ram implementation" default CAR_CQOS if !SOC_INTEL_GEMINILAKE default CAR_NEM help This option allows you to select how cache-as-ram (CAR) is set up.
config CAR_NEM bool "Non-evict mode" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_NEM help Traditionally, CAR is set up by using Non-Evict mode. This method does not allow CAR and cache to co-exist, because cache fills are block in NEM mode.
config CAR_CQOS bool "Cache Quality of Service" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_CQOS help Cache Quality of Service allows more fine-grained control of cache usage. As result, it is possible to set up portion of L2 cache for CAR and use remainder for actual caching.
config USE_APOLLOLAKE_FSP_CAR bool "Use FSP CAR" select FSP_CAR help Use FSP APIs to initialize & tear down the Cache-As-Ram.
endchoice
"Cache Quality of Service" seems more functional than "Non-Evict mode", but is it "better"?
Selecting *either* CONFIG_CAR_CQOS=y or the default CONFIG_CAR_NEM=y, the compile seems mostly successful, but then ends the same, with:
... Platform is: glk File build/coreboot.pre is 16777216 bytes Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000 make: *** [src/southbridge/intel/common/firmware/Makefile.inc:39: add_intel_firmware] Error 1
I need help with that.
Also, though I'm not sure what this does, coreboot does not like my enabling CONFIG_EC_GOOGLE_CHROMEEC_RTC, which then gives:
/var/src/coreboot/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/bootblock/ec/google/chromeec/ec.o: in function `rtc_get': /var/src/coreboot/coreboot/src/ec/google/chromeec/ec.c:776: multiple definition of `rtc_get'; build/bootblock/drivers/pc80/rtc/mc146818rtc.o:/var/src/coreboot/coreboot/src/drivers/pc80/rtc/mc146818rtc.c:225: first defined here make: *** [src/arch/x86/Makefile.inc:92: build/cbfs/fallback/bootblock.debug] Error 1
By the way, this chromebook recovery file includes a distinct SAR file that can be extracted from the COREBOOT section, but the SAR file-path option is not present in the config menu, using the current Kconfig:
src/drivers/wifi/generic/Kconfig
config USE_SAR bool default n help Enable it when wifi driver uses SAR configuration feature. ...
config WIFI_SAR_CBFS_FILEPATH string "The cbfs file which has WIFI SAR defaults" depends on USE_SAR default ""
Adding any kind of "prompt text" after "bool" causes the option to appear, and then the SAR file-path can be added.
Is this a mistake in the Kconfig? Or, what should be done with this SAR file?
Coreboot does seem to properly include my SAR file, since the coreboot.pre wifi_sar_defaults.hex file exactly matches the SAR file I specified in the WIFI_SAR_CBFS_FILEPATH.
Thanks James
$ cat defconfig CONFIG_ANY_TOOLCHAIN=y CONFIG_VENDOR_GOOGLE=y CONFIG_MAINBOARD_VENDOR="Octopus" CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Coreboot" # CONFIG_POST_IO is not set CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_USE_LEGACY_8254_TIMER=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CAR_CQOS=y # CONFIG_PAVP is not set CONFIG_X2APIC_RUNTIME=y CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_VALIDATE_INTEL_DESCRIPTOR=y CONFIG_ME_REGION_ALLOW_CPU_READ_ACCESS=y CONFIG_RUN_FSP_GOP=y CONFIG_TPM_PPI=y CONFIG_USE_SAR=y CONFIG_WIFI_SAR_CBFS_FILEPATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/wifi_sar-bluebird.hex" CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y CONFIG_COREINFO_SECONDARY_PAYLOAD=y CONFIG_MEMTEST_SECONDARY_PAYLOAD=y
$ util/cbfstool/cbfstool build/coreboot.pre print FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 59136 none cpu_microcode_blob.bin 0xe800 microcode 148480 none intel_fit 0x32c40 raw 80 none fallback/ramstage 0x32cc0 stage 110054 LZMA (257508 decompressed) config 0x4db00 raw 1184 none revision 0x4dfc0 raw 722 none build_info 0x4e2c0 raw 100 none fallback/dsdt.aml 0x4e380 raw 13347 none pt 0x51800 raw 20480 none pdpt 0x56840 raw 32 none dmic-2ch-48khz-16b.bin 0x56880 raw 3048 none dmic-4ch-48khz-16b.bin 0x574c0 raw 3048 none max98357-render-2ch-48khz-24b.bin 0x58100 raw 116 none dialog-2ch-48khz-24b.bin 0x581c0 raw 100 none fspm.bin 0x58280 fsp 417792 none vbt.bin 0xbe2c0 raw 1334 LZMA (5632 decompressed) wifi_sar_defaults.hex 0xbe840 raw 119 none (empty) 0xbe900 null 932 none fsps.bin 0xbecc0 fsp 192512 none fallback/postcar 0xedd00 stage 20388 none img/coreinfo 0xf2d00 simple elf 54609 none fallback/payload 0x100280 simple elf 249347 none img/memtest 0x13d0c0 simple elf 47497 none (empty) 0x148a80 null 3234276 none bootblock 0x45e480 bootblock 10288 none
On 6/22/21 8:17 AM, Matt DeVillier wrote:
FSP-T isn't used for APL/GLK Chromebooks. Sounds like your .config is selecting something it shouldn't. run `make savedefconfig` then post the contents of the defconfig. Possible CONFIG_USE_APOLLOLAKE_FSP_CAR is selected when it shouldn't be.
On Mon, Jun 21, 2021 at 9:17 PM James Feeney james@nurealm.net wrote:
$ cat defconfig ... CONFIG_ADD_FSP_BINARIES=y ...
There is *no* "fspt.bin" file in this chromebook recovery bios file used as source.
$ make ... src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file or directory #include <FsptUpd.h> ^~~~~~~~~~~ compilation terminated. make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 1
What Makefile is that? There is no such line 379.
$ find -name FsptUpd.h ... ./3rdparty/fsp/ApolloLakeFspBinPkg/Include/FsptUpd.h ...
$ less src/soc/intel/alderlake/Kconfig ... config FSP_HEADER_PATH string "Location of FSP headers" default "src/vendorcode/intel/fsp/fsp2_0/alderlake/"
$ less src/drivers/intel/fsp2_0/Kconfig ...
config FSP_T_FILE string "Intel FSP-T (temp RAM init) binary path and filename" if !FSP_FULL_FD depends on ADD_FSP_BINARIES depends on FSP_CAR default "$(obj)/Fsp_T.fd" if FSP_FULL_FD help The path and filename of the Intel FSP-T binary for this platform.
$ make nconfig ... > Generic Drivers ... (src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers
How did that get there? Not me...
$ ll src/vendorcode/intel/fsp/fsp2_0/glk total 116 drwxr-x--- 2 james james 4096 Oct 29 2020 . drwxr-x--- 9 james james 4096 Jun 14 19:04 .. -rw-r----- 1 james james 45977 Oct 29 2020 FspmUpd.h -rw-r----- 1 james james 57332 Oct 29 2020 FspsUpd.h -rw-r----- 1 james james 1967 Oct 29 2020 FspUpd.h
Why is src/soc/intel/apollolake/fspcar.c being built here? It seems that no fspt.bin file is needed.
James _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 6/22/21 4:32 PM, Matt DeVillier wrote:
I'm not sure why you enabled so many things not selected in my defconfig -- that's your issue.
Ha! Quite! Bit of a learning curve, though...
Ok, thanks for the clarifications - lots of things I do not need.
Use:
CONFIG_VENDOR_GOOGLE=y CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_RUN_FSP_GOP=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y
save as .config, then make olddefconfig.
CAR NEM (non-evict mode) is default, leave that.
No reason to select ChromeEC RTC, it's not supported.
WiFi SAR is only used by ChromeOS, only selectable when CONFIG_CHROMEOS=y
secondary payloads are almost certainly not useful with u-boot as primary payload.
I don't get any size mismatch errors when building for CASTA using the default FMAP. Have you modified your IFD at all?
I have not touched it.
Did you *actually* run ifdtool validate? Is your build, with no size mismatch, recent?
Using your config, and following your instructions, I get still the same result:
$ util/ifdtool/ifdtool -t build/coreboot.rom File build/coreboot.rom is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000
I see now that I need *not* enable "Validate Intel firmware descriptor", and the compile will complete without error.
But - I still have to wonder about that: "This config enables validating the Intel firmware descriptor against the fmap layout."
Does that not matter? Is that another "ChromeOS only" thing?
They differ in size by 60kiB. Hmm - "SI-BIOS" is one of the read-only sections given by "cbfstool /build/coreboot.rom layout -w", as is "FMAP". "BIOS" is one of the sections given by "ifdtool -d build/coreboot.rom". They just happen to have different sizes. It looks like "FMAP" is specifically a coreboot thing? The "SI" is an abbreviation for what?
As I understand, the IFD section was simply copied from the recovery file, and the FMAP section was generated from scratch, in the coreboot compile. Did coreboot make an error in not matching the given IFD?
Since the IFD BIOS region is larger in size than the FMAP SI-BIOS region, does it matter that the sizes are different? The IFD Intel ME, GbE, and Platform Data regions are all unused. There is nothing there to "mis-read", because of any potential location mistake - unless something tries to calculate a location "backward", from the end of the IFD BIOS region. Could the 60kiB size difference represent some kind of "padding"?
By the way, do I need to be concerned with the final note at the end of the compile, "Written area will abut bottom of target region: any unused space will keep its current contents"? A 16MiB file written onto a 16MiB rom doesn't leave any "unused" space. Or, is this "unused space" referring to "unused" and "unusable" regions described in the FMAP layout?
I should be able to write this coreboot.rom file directly to the boot rom now?
Thanks James
On Tue, Jun 22, 2021 at 4:10 PM James Feeney james@nurealm.net wrote:
defconfig below, but:
$ grep -i fsp_car defconfig CONFIG_USE_APOLLOLAKE_FSP_CAR=y
$ grep -i fsp_car .config CONFIG_USE_APOLLOLAKE_FSP_CAR=y CONFIG_FSP_CAR=y
Hmm - I must have done that because it sounded "safe". Which of these choices is "correct"?
src/soc/intel/apollolake/Kconfig
choice prompt "Cache-as-ram implementation" default CAR_CQOS if !SOC_INTEL_GEMINILAKE default CAR_NEM help This option allows you to select how cache-as-ram (CAR) is set up.
config CAR_NEM bool "Non-evict mode" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_NEM help Traditionally, CAR is set up by using Non-Evict mode. This method does not allow CAR and cache to co-exist, because cache fills are block in NEM mode.
config CAR_CQOS bool "Cache Quality of Service" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_CQOS help Cache Quality of Service allows more fine-grained control of cache usage. As result, it is possible to set up portion of L2 cache for CAR and use remainder for actual caching.
config USE_APOLLOLAKE_FSP_CAR bool "Use FSP CAR" select FSP_CAR help Use FSP APIs to initialize & tear down the Cache-As-Ram.
endchoice
"Cache Quality of Service" seems more functional than "Non-Evict mode", but is it "better"?
Selecting *either* CONFIG_CAR_CQOS=y or the default CONFIG_CAR_NEM=y, the compile seems mostly successful, but then ends the same, with:
... Platform is: glk File build/coreboot.pre is 16777216 bytes Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000 make: *** [src/southbridge/intel/common/firmware/Makefile.inc:39: add_intel_firmware] Error 1
I need help with that.
Also, though I'm not sure what this does, coreboot does not like my enabling CONFIG_EC_GOOGLE_CHROMEEC_RTC, which then gives:
/var/src/coreboot/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/bootblock/ec/google/chromeec/ec.o: in function `rtc_get': /var/src/coreboot/coreboot/src/ec/google/chromeec/ec.c:776: multiple definition of `rtc_get'; build/bootblock/drivers/pc80/rtc/mc146818rtc.o:/var/src/coreboot/coreboot/src/drivers/pc80/rtc/mc146818rtc.c:225: first defined here make: *** [src/arch/x86/Makefile.inc:92: build/cbfs/fallback/bootblock.debug] Error 1
By the way, this chromebook recovery file includes a distinct SAR file that can be extracted from the COREBOOT section, but the SAR file-path option is not present in the config menu, using the current Kconfig:
src/drivers/wifi/generic/Kconfig
config USE_SAR bool default n help Enable it when wifi driver uses SAR configuration feature. ...
config WIFI_SAR_CBFS_FILEPATH string "The cbfs file which has WIFI SAR defaults" depends on USE_SAR default ""
Adding any kind of "prompt text" after "bool" causes the option to appear, and then the SAR file-path can be added.
Is this a mistake in the Kconfig? Or, what should be done with this SAR file?
Coreboot does seem to properly include my SAR file, since the coreboot.pre wifi_sar_defaults.hex file exactly matches the SAR file I specified in the WIFI_SAR_CBFS_FILEPATH.
Thanks James
$ cat defconfig CONFIG_ANY_TOOLCHAIN=y CONFIG_VENDOR_GOOGLE=y CONFIG_MAINBOARD_VENDOR="Octopus" CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Coreboot" # CONFIG_POST_IO is not set CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_USE_LEGACY_8254_TIMER=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CAR_CQOS=y # CONFIG_PAVP is not set CONFIG_X2APIC_RUNTIME=y CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_VALIDATE_INTEL_DESCRIPTOR=y CONFIG_ME_REGION_ALLOW_CPU_READ_ACCESS=y CONFIG_RUN_FSP_GOP=y CONFIG_TPM_PPI=y CONFIG_USE_SAR=y CONFIG_WIFI_SAR_CBFS_FILEPATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/wifi_sar-bluebird.hex" CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y CONFIG_COREINFO_SECONDARY_PAYLOAD=y CONFIG_MEMTEST_SECONDARY_PAYLOAD=y
$ util/cbfstool/cbfstool build/coreboot.pre print FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 59136 none cpu_microcode_blob.bin 0xe800 microcode 148480 none intel_fit 0x32c40 raw 80 none fallback/ramstage 0x32cc0 stage 110054 LZMA (257508 decompressed) config 0x4db00 raw 1184 none revision 0x4dfc0 raw 722 none build_info 0x4e2c0 raw 100 none fallback/dsdt.aml 0x4e380 raw 13347 none pt 0x51800 raw 20480 none pdpt 0x56840 raw 32 none dmic-2ch-48khz-16b.bin 0x56880 raw 3048 none dmic-4ch-48khz-16b.bin 0x574c0 raw 3048 none max98357-render-2ch-48khz-24b.bin 0x58100 raw 116 none dialog-2ch-48khz-24b.bin 0x581c0 raw 100 none fspm.bin 0x58280 fsp 417792 none vbt.bin 0xbe2c0 raw 1334 LZMA (5632 decompressed) wifi_sar_defaults.hex 0xbe840 raw 119 none (empty) 0xbe900 null 932 none fsps.bin 0xbecc0 fsp 192512 none fallback/postcar 0xedd00 stage 20388 none img/coreinfo 0xf2d00 simple elf 54609 none fallback/payload 0x100280 simple elf 249347 none img/memtest 0x13d0c0 simple elf 47497 none (empty) 0x148a80 null 3234276 none bootblock 0x45e480 bootblock 10288 none
On 6/22/21 8:17 AM, Matt DeVillier wrote:
FSP-T isn't used for APL/GLK Chromebooks. Sounds like your .config is selecting something it shouldn't. run `make savedefconfig` then post the contents of the defconfig. Possible CONFIG_USE_APOLLOLAKE_FSP_CAR is selected when it shouldn't be.
On Mon, Jun 21, 2021 at 9:17 PM James Feeney james@nurealm.net wrote:
$ cat defconfig ... CONFIG_ADD_FSP_BINARIES=y ...
There is *no* "fspt.bin" file in this chromebook recovery bios file used as source.
$ make ... src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file or directory #include <FsptUpd.h> ^~~~~~~~~~~ compilation terminated. make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 1
What Makefile is that? There is no such line 379.
$ find -name FsptUpd.h ... ./3rdparty/fsp/ApolloLakeFspBinPkg/Include/FsptUpd.h ...
$ less src/soc/intel/alderlake/Kconfig ... config FSP_HEADER_PATH string "Location of FSP headers" default "src/vendorcode/intel/fsp/fsp2_0/alderlake/"
$ less src/drivers/intel/fsp2_0/Kconfig ...
config FSP_T_FILE string "Intel FSP-T (temp RAM init) binary path and filename" if !FSP_FULL_FD depends on ADD_FSP_BINARIES depends on FSP_CAR default "$(obj)/Fsp_T.fd" if FSP_FULL_FD help The path and filename of the Intel FSP-T binary for this platform.
$ make nconfig ... > Generic Drivers ... (src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers
How did that get there? Not me...
$ ll src/vendorcode/intel/fsp/fsp2_0/glk total 116 drwxr-x--- 2 james james 4096 Oct 29 2020 . drwxr-x--- 9 james james 4096 Jun 14 19:04 .. -rw-r----- 1 james james 45977 Oct 29 2020 FspmUpd.h -rw-r----- 1 james james 57332 Oct 29 2020 FspsUpd.h -rw-r----- 1 james james 1967 Oct 29 2020 FspUpd.h
Why is src/soc/intel/apollolake/fspcar.c being built here? It seems that no fspt.bin file is needed.
James _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Tue, Jun 22, 2021 at 10:59 PM James Feeney james@nurealm.net wrote:
On 6/22/21 4:32 PM, Matt DeVillier wrote:
I'm not sure why you enabled so many things not selected in my defconfig -- that's your issue.
Ha! Quite! Bit of a learning curve, though...
Ok, thanks for the clarifications - lots of things I do not need.
Use:
CONFIG_VENDOR_GOOGLE=y CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_RUN_FSP_GOP=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y
save as .config, then make olddefconfig.
CAR NEM (non-evict mode) is default, leave that.
No reason to select ChromeEC RTC, it's not supported.
WiFi SAR is only used by ChromeOS, only selectable when CONFIG_CHROMEOS=y
secondary payloads are almost certainly not useful with u-boot as primary payload.
I don't get any size mismatch errors when building for CASTA using the default FMAP. Have you modified your IFD at all?
I have not touched it.
Did you *actually* run ifdtool validate? Is your build, with no size mismatch, recent?
Using your config, and following your instructions, I get still the same result:
$ util/ifdtool/ifdtool -t build/coreboot.rom File build/coreboot.rom is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000
I see now that I need *not* enable "Validate Intel firmware descriptor", and the compile will complete without error.
But - I still have to wonder about that: "This config enables validating the Intel firmware descriptor against the fmap layout."
Does that not matter? Is that another "ChromeOS only" thing?
This issue has nothing to do with ChromeOS.
They differ in size by 60kiB. Hmm - "SI-BIOS" is one of the read-only sections given by "cbfstool /build/coreboot.rom layout -w", as is "FMAP". "BIOS" is one of the sections given by "ifdtool -d build/coreboot.rom". They just happen to have different sizes. It looks like "FMAP" is specifically a coreboot thing? The "SI" is an abbreviation for what?
As I understand, the IFD section was simply copied from the recovery file, and the FMAP section was generated from scratch, in the coreboot compile. Did coreboot make an error in not matching the given IFD?
the FMAP isn't generated from scratch, it's the default.fmd file in the google/octopus directory. If you look at that file (and at chromeos.fms), you can see why the layout and sizes are the way they are.
Since the IFD BIOS region is larger in size than the FMAP SI-BIOS region, does it matter that the sizes are different? The IFD Intel ME, GbE, and Platform Data regions are all unused. There is nothing there to "mis-read", because of any potential location mistake - unless something tries to calculate a location "backward", from the end of the IFD BIOS region. Could the 60kiB size difference represent some kind of "padding"?
I'm curious about the IFD you're using. Dumping the IFD from bios-casta.ro-11297-83-3.rw-11297-83-3.bin (extracted from the octopus recovery image), the IFD layout matches that of the default.fmd used by coreboot.
By the way, do I need to be concerned with the final note at the end of the compile, "Written area will abut bottom of target region: any unused space will keep its current contents"? A 16MiB file written onto a 16MiB rom doesn't leave any "unused" space. Or, is this "unused space" referring to "unused" and "unusable" regions described in the FMAP layout?
I should be able to write this coreboot.rom file directly to the boot rom now?
I would resolve the IFD/FMAP discrepancy first. The IFD from the firmware images for all the octopus based boards I'm seeing here use the same BIOS region size as the SI_BIOS region in the FMAP.
Thanks James
On Tue, Jun 22, 2021 at 4:10 PM James Feeney james@nurealm.net wrote:
defconfig below, but:
$ grep -i fsp_car defconfig CONFIG_USE_APOLLOLAKE_FSP_CAR=y
$ grep -i fsp_car .config CONFIG_USE_APOLLOLAKE_FSP_CAR=y CONFIG_FSP_CAR=y
Hmm - I must have done that because it sounded "safe". Which of these choices is "correct"?
src/soc/intel/apollolake/Kconfig
choice prompt "Cache-as-ram implementation" default CAR_CQOS if !SOC_INTEL_GEMINILAKE default CAR_NEM help This option allows you to select how cache-as-ram (CAR) is set up.
config CAR_NEM bool "Non-evict mode" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_NEM help Traditionally, CAR is set up by using Non-Evict mode. This method does not allow CAR and cache to co-exist, because cache fills are block in NEM mode.
config CAR_CQOS bool "Cache Quality of Service" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_CQOS help Cache Quality of Service allows more fine-grained control of cache usage. As result, it is possible to set up portion of L2 cache for CAR and use remainder for actual caching.
config USE_APOLLOLAKE_FSP_CAR bool "Use FSP CAR" select FSP_CAR help Use FSP APIs to initialize & tear down the Cache-As-Ram.
endchoice
"Cache Quality of Service" seems more functional than "Non-Evict mode", but is it "better"?
Selecting *either* CONFIG_CAR_CQOS=y or the default CONFIG_CAR_NEM=y, the compile seems mostly successful, but then ends the same, with:
... Platform is: glk File build/coreboot.pre is 16777216 bytes Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000 make: *** [src/southbridge/intel/common/firmware/Makefile.inc:39: add_intel_firmware] Error 1
I need help with that.
Also, though I'm not sure what this does, coreboot does not like my enabling CONFIG_EC_GOOGLE_CHROMEEC_RTC, which then gives:
/var/src/coreboot/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/bootblock/ec/google/chromeec/ec.o: in function `rtc_get': /var/src/coreboot/coreboot/src/ec/google/chromeec/ec.c:776: multiple definition of `rtc_get'; build/bootblock/drivers/pc80/rtc/mc146818rtc.o:/var/src/coreboot/coreboot/src/drivers/pc80/rtc/mc146818rtc.c:225: first defined here make: *** [src/arch/x86/Makefile.inc:92: build/cbfs/fallback/bootblock.debug] Error 1
By the way, this chromebook recovery file includes a distinct SAR file that can be extracted from the COREBOOT section, but the SAR file-path option is not present in the config menu, using the current Kconfig:
src/drivers/wifi/generic/Kconfig
config USE_SAR bool default n help Enable it when wifi driver uses SAR configuration feature. ...
config WIFI_SAR_CBFS_FILEPATH string "The cbfs file which has WIFI SAR defaults" depends on USE_SAR default ""
Adding any kind of "prompt text" after "bool" causes the option to appear, and then the SAR file-path can be added.
Is this a mistake in the Kconfig? Or, what should be done with this SAR file?
Coreboot does seem to properly include my SAR file, since the coreboot.pre wifi_sar_defaults.hex file exactly matches the SAR file I specified in the WIFI_SAR_CBFS_FILEPATH.
Thanks James
$ cat defconfig CONFIG_ANY_TOOLCHAIN=y CONFIG_VENDOR_GOOGLE=y CONFIG_MAINBOARD_VENDOR="Octopus" CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Coreboot" # CONFIG_POST_IO is not set CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_USE_LEGACY_8254_TIMER=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CAR_CQOS=y # CONFIG_PAVP is not set CONFIG_X2APIC_RUNTIME=y CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_VALIDATE_INTEL_DESCRIPTOR=y CONFIG_ME_REGION_ALLOW_CPU_READ_ACCESS=y CONFIG_RUN_FSP_GOP=y CONFIG_TPM_PPI=y CONFIG_USE_SAR=y CONFIG_WIFI_SAR_CBFS_FILEPATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/wifi_sar-bluebird.hex" CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y CONFIG_COREINFO_SECONDARY_PAYLOAD=y CONFIG_MEMTEST_SECONDARY_PAYLOAD=y
$ util/cbfstool/cbfstool build/coreboot.pre print FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 59136 none cpu_microcode_blob.bin 0xe800 microcode 148480 none intel_fit 0x32c40 raw 80 none fallback/ramstage 0x32cc0 stage 110054 LZMA (257508 decompressed) config 0x4db00 raw 1184 none revision 0x4dfc0 raw 722 none build_info 0x4e2c0 raw 100 none fallback/dsdt.aml 0x4e380 raw 13347 none pt 0x51800 raw 20480 none pdpt 0x56840 raw 32 none dmic-2ch-48khz-16b.bin 0x56880 raw 3048 none dmic-4ch-48khz-16b.bin 0x574c0 raw 3048 none max98357-render-2ch-48khz-24b.bin 0x58100 raw 116 none dialog-2ch-48khz-24b.bin 0x581c0 raw 100 none fspm.bin 0x58280 fsp 417792 none vbt.bin 0xbe2c0 raw 1334 LZMA (5632 decompressed) wifi_sar_defaults.hex 0xbe840 raw 119 none (empty) 0xbe900 null 932 none fsps.bin 0xbecc0 fsp 192512 none fallback/postcar 0xedd00 stage 20388 none img/coreinfo 0xf2d00 simple elf 54609 none fallback/payload 0x100280 simple elf 249347 none img/memtest 0x13d0c0 simple elf 47497 none (empty) 0x148a80 null 3234276 none bootblock 0x45e480 bootblock 10288 none
On 6/22/21 8:17 AM, Matt DeVillier wrote:
FSP-T isn't used for APL/GLK Chromebooks. Sounds like your .config is selecting something it shouldn't. run `make savedefconfig` then post the contents of the defconfig. Possible CONFIG_USE_APOLLOLAKE_FSP_CAR is selected when it shouldn't be.
On Mon, Jun 21, 2021 at 9:17 PM James Feeney james@nurealm.net wrote:
$ cat defconfig ... CONFIG_ADD_FSP_BINARIES=y ...
There is *no* "fspt.bin" file in this chromebook recovery bios file used as source.
$ make ... src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file or directory #include <FsptUpd.h> ^~~~~~~~~~~ compilation terminated. make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 1
What Makefile is that? There is no such line 379.
$ find -name FsptUpd.h ... ./3rdparty/fsp/ApolloLakeFspBinPkg/Include/FsptUpd.h ...
$ less src/soc/intel/alderlake/Kconfig ... config FSP_HEADER_PATH string "Location of FSP headers" default "src/vendorcode/intel/fsp/fsp2_0/alderlake/"
$ less src/drivers/intel/fsp2_0/Kconfig ...
config FSP_T_FILE string "Intel FSP-T (temp RAM init) binary path and filename" if !FSP_FULL_FD depends on ADD_FSP_BINARIES depends on FSP_CAR default "$(obj)/Fsp_T.fd" if FSP_FULL_FD help The path and filename of the Intel FSP-T binary for this platform.
$ make nconfig ... > Generic Drivers ... (src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers
How did that get there? Not me...
$ ll src/vendorcode/intel/fsp/fsp2_0/glk total 116 drwxr-x--- 2 james james 4096 Oct 29 2020 . drwxr-x--- 9 james james 4096 Jun 14 19:04 .. -rw-r----- 1 james james 45977 Oct 29 2020 FspmUpd.h -rw-r----- 1 james james 57332 Oct 29 2020 FspsUpd.h -rw-r----- 1 james james 1967 Oct 29 2020 FspUpd.h
Why is src/soc/intel/apollolake/fspcar.c being built here? It seems that no fspt.bin file is needed.
James _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 6/22/21 11:13 PM, Matt DeVillier wrote:
On Tue, Jun 22, 2021 at 10:59 PM James Feeney james@nurealm.net wrote:
On 6/22/21 4:32 PM, Matt DeVillier wrote:
I'm not sure why you enabled so many things not selected in my defconfig -- that's your issue.
Ha! Quite! Bit of a learning curve, though...
Ok, thanks for the clarifications - lots of things I do not need.
Use:
CONFIG_VENDOR_GOOGLE=y CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_RUN_FSP_GOP=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y
save as .config, then make olddefconfig.
CAR NEM (non-evict mode) is default, leave that.
No reason to select ChromeEC RTC, it's not supported.
WiFi SAR is only used by ChromeOS, only selectable when CONFIG_CHROMEOS=y
secondary payloads are almost certainly not useful with u-boot as primary payload.
I don't get any size mismatch errors when building for CASTA using the default FMAP. Have you modified your IFD at all?
I have not touched it.
Did you *actually* run ifdtool validate? Is your build, with no size mismatch, recent?
Using your config, and following your instructions, I get still the same result:
$ util/ifdtool/ifdtool -t build/coreboot.rom File build/coreboot.rom is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000
I see now that I need *not* enable "Validate Intel firmware descriptor", and the compile will complete without error.
But - I still have to wonder about that: "This config enables validating the Intel firmware descriptor against the fmap layout."
Does that not matter? Is that another "ChromeOS only" thing?
This issue has nothing to do with ChromeOS.
They differ in size by 60kiB. Hmm - "SI-BIOS" is one of the read-only sections given by "cbfstool /build/coreboot.rom layout -w", as is "FMAP". "BIOS" is one of the sections given by "ifdtool -d build/coreboot.rom". They just happen to have different sizes. It looks like "FMAP" is specifically a coreboot thing? The "SI" is an abbreviation for what?
As I understand, the IFD section was simply copied from the recovery file, and the FMAP section was generated from scratch, in the coreboot compile. Did coreboot make an error in not matching the given IFD?
the FMAP isn't generated from scratch, it's the default.fmd file in the google/octopus directory. If you look at that file (and at chromeos.fms), you can see why the layout and sizes are the way they are.
Aha! Ok, thanks for that.
src/mainboard/google/octopus/chromeos.fmd
# BIOS --> 4K to 0xf7f000
Since the IFD BIOS region is larger in size than the FMAP SI-BIOS region, does it matter that the sizes are different? The IFD Intel ME, GbE, and Platform Data regions are all unused. There is nothing there to "mis-read", because of any potential location mistake - unless something tries to calculate a location "backward", from the end of the IFD BIOS region. Could the 60kiB size difference represent some kind of "padding"?
I'm curious about the IFD you're using. Dumping the IFD from bios-casta.ro-11297-83-3.rw-11297-83-3.bin (extracted from the octopus recovery image), the IFD layout matches that of the default.fmd used by coreboot.
Uhm - I'm confused. Using the value given in src/mainboard/google/octopus/chromeos.fmd, and reading the *comment*, which describes the BIOS region as from 0x1000 to 0xf7f000, then subtracting, gives the *size* of the - presumably - fmap "SI-BIOS" region as 0xf7e000, which exactly matches the value reported by ifdtool from the ChromeOS recovery bios file provided IFD BIOS region.
There is no discrepancy there - though, of course, this conclusion is presuming that the comment correctly interprets the meaning of the "BIOS" region, as everything between the "SI-DESC" region and the "DEVICE_EXTENSION" region, and that the chromeos.fmd file use of the term "BIOS" means exactly "SI-BIOS", as the term is expressed by cbfstool.
Incidentally, when I apply the ifdtool "validate" function to the ChromeOS recovery bios file, there is no output returned.
Is that the "correct" output when the validation is successful? If so, that's a really bad user interface design for ifdtool, since it is impossible to distinguish "no output" from "fails silently", as in "broken", especially given the otherwise "chatty" output, and the cryptic comment "Peculiar firmware descriptor", which casts doubt upon the result given. Is "Peculiar firmware descriptor" a kind of "error"?
Using the oldest recovery bios file that I have gives:
$ ifdtool -t images/bios-casta.ro-11297-193-0.rw-11297-217-0.bin File images/bios-casta.ro-11297-193-0.rw-11297-217-0.bin is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. [ That's the complete output. ]
Using the current recovery bios file gives the same truncated output:
$ ifdtool -t images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin File images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility.
To introspect further, there is the "fmap_decode" tool from the "flashmap" package, at https://chromium.googlesource.com/chromiumos/third_party/flashmap.
$ fmap_decode build/coreboot.rom fmap_signature="0x5f5f464d41505f5f" fmap_ver_major="1" fmap_ver_minor="1" fmap_base="0x0000000000000000" fmap_size="0x1000000" fmap_name="FLASH" fmap_nareas="13" area_offset="0x00000000" area_size="0x00001000" area_name="SI_DESC" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x00f6f000" area_name="SI_BIOS" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x001ff000" area_name="IFWI" area_flags_raw="0x00" area_flags="" area_offset="0x00a5f000" area_size="0x00040000" area_name="SMMSTORE" area_flags_raw="0x00" area_flags="" area_offset="0x00a9f000" area_size="0x00021000" area_name="UNIFIED_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00a9f000" area_size="0x00010000" area_name="RECOVERY_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00aaf000" area_size="0x00010000" area_name="RW_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00abf000" area_size="0x00001000" area_name="RW_VAR_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00ac0000" area_size="0x00000300" area_name="FMAP" area_flags_raw="0x00" area_flags="" area_offset="0x00ac0300" area_size="0x00460d00" area_name="COREBOOT" area_flags_raw="0x00" area_flags="" area_offset="0x00f21000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags="" area_offset="0x00f7f000" area_size="0x00080000" area_name="DEVICE_EXTENSION" area_flags_raw="0x00" area_flags="" area_offset="0x00fff000" area_size="0x00001000" area_name="UNUSED_HOLE" area_flags_raw="0x00" area_flags=""
Again, interpreting the comment in the chromeos.fmd file, everything between 0x00001000 and 0x00f7f000 does, in fact, have size 0x00f7e000, exactly matching the value as stated in the IFD. However, there is also an explicit "SI-BIOS" region given here, which does *not* correspond to the comment in the chromeos.fmd file, and which here has the size given as 0x00f6f000 != 0x00f7e000.
Similarly,
$ cbfstool build/coreboot.rom layout -w This image contains the following sections that can be accessed with this tool:
'SI_DESC' (size 4096, offset 0) 'SI_BIOS' (read-only, size 16183296, offset 4096) 'IFWI' (size 2093056, offset 4096) 'SMMSTORE' (size 262144, offset 10874880) 'UNIFIED_MRC_CACHE' (read-only, size 135168, offset 11137024) 'RECOVERY_MRC_CACHE' (size 65536, offset 11137024) 'RW_MRC_CACHE' (size 65536, offset 11202560) 'RW_VAR_MRC_CACHE' (size 4096, offset 11268096) 'FMAP' (read-only, size 768, offset 11272192) 'COREBOOT' (CBFS, size 4590848, offset 11272960) 'BIOS_UNUSABLE' (size 323584, offset 15863808) 'DEVICE_EXTENSION' (size 524288, offset 16248832) 'UNUSED_HOLE' (size 4096, offset 16773120)
...
The offset to the start of both the BIOS region and the SI_BIOS region are the same, given as 0x00001000. Taking the *size* of the SI_BIOS region, 0x00f6f000, and adding the offset, 0x00001000, then gives the offset to the beginning of the region immediately following the SI_BIOS region, 0x00f6f000 + 0x00001000 = 0x00f70000.
Compare this value to the offset to the beginning of the region immediately following the "BIOS_UNUSABLE" region, 0x00f21000 + 0x0004f000 = 0x00f70000. We shall note that they are exactly the same, 0x00f70000 = 0x00f70000.
There exists, then, an "undesignated" region, implied by the coreboot flashmap format, *between* the end of the "SI_BIOS" region, and the beginning of the "DEVICE_EXTENSION" region, from 0x00f70000 to 0x00f7f000, of size 0xf000.
(0x00f7f000 - 0x00f70000) = (0x00f7e000 - 0x00f6f000) = 0xf000
We may also note that there is a discrepancy between the definition of the "BIOS_UNUSABLE" region, as given in src/mainboard/google/octopus/chromeos.fmd, and this same region, as reported for the actual coreboot.rom file, as generated from the coreboot compile.
chromeos.fmd BIOS_UNUSABLE@0xf30000 0x4f000
fmap_decode build/coreboot.rom area_offset="0x00f21000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags=""
We may note that the region sizes given are the same, but that the entry offsets are different.
Comparing these offsets, we see this same discrepancy, 0xf000, here a result of a discrepancy in the offset location of this "BIOS_UNUSABLE" region, 0xf30000, as given in the chromeos.fmd file, when compared to the location of this region in the actually created coreboot.rom file, 0x00f21000.
0xf30000 - 0x00f21000 = 0xf000
Incidentally, we may note that there exists a similar flashmap file, src/mainboard/google/octopus/default.fmd, in which the definition of the "BIOS_UNUSABLE" regiion is not so precise, with no specific entry point offset defined:
src/mainboard/google/octopus/default.fmd
BIOS_UNUSABLE 0x4f000
We may also note that the given size of the "SI_BIOS" region, 0x00f6f000, violates the rule described in these chromeos.fmd and default.fmd files:
# Currently, it is required that the BIOS region be a multiple of 8KiB.
0x00f6f000 / 0x2000 -> 16183296 / 8192 = 1975.5
We then note that the difference in *size* between the "BIOS" and "SI_BIOS" regions, 0x00f7e000 - 0x00f6f000 = 0xf000, does not seem to have any clear relationship to the difference in the *end points* of these regions, 0x00f7f000 and 0xf70000, respectively. The *size* provided for the actual "BIOS" region does conform to the rule.
And finally, we may note additionally in the comment:
# ... Since the # descriptor at the beginning uses 4K and BIOS starts at an offset of # 4K, a hole of 4K is created towards the end of the flash to compensate # for the size requirement of BIOS region. and UNUSED_HOLE@0xfff000 0x1000
but, while the "undesignated" region of size of 0xf000 bytes is not an even multiple of 0x2000, being instead 7.5 multiples, it also encompasses a region with 6 multiples of 0x2000, such that the rule itself does not provide any justification for having an "undesignated" region of size 0xf000. The "undesignated" region size of precisely 0xf000 bytes does not seem to have any obvious motivation or rationale.
These results, then, raise questions:
Is the location of the "BIOS_UNUSABLE" region, as created in the coreboot.rom, in error, beginning 0xf000 bytes below where it is "suppose" to have been located, according to the chromeos.fmd specification file?
Why has this "undesgnated" 0xf000 byte region not, instead, been allocated to the "COREBOOT" region?
Are mystery "undesignated" regions in the rom layout "allowed/legal", under the rules of the coreboot fmap format?
Is this "undesignated" region a mistake?
Is there some error in the chromeos.fmd file, or in the google/octopus/default.fmd file?
Is the coreboot fmap format specification too ambiguous to provide precise results?
What is the definition of "SI_BIOS" region, precisely? What is the definition of "BIOS" region, precisely?
Why is "ifdtool --validate" comparing the size of the "BIOS" region to the size of the "SI_BIOS" region? Is this comparison a mistake? Is ifdtool "broken"? Or, was illuminating this kind of discrepancy the whole point of the validate function?
What, then, is the precise meaning of the implied state "ifdtool validated"?
Is the definition of the "SI-BIOS" region suppose to include the area to the *end* of the "BIOS_UNUSABLE" region, or instead, to the *beginning* of the "DEVICE_EXTENSION" region?
Who, or what, or where, is the "official" source of these definitions?
It may be important to note that there exists no such "SI_BIOS" region in the ChromeOS recovery bios file:
$ fmap_decode images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin fmap_signature="0x5f5f464d41505f5f" fmap_ver_major="1" fmap_ver_minor="1" fmap_base="0x0000000000000000" fmap_size="0x1000000" fmap_name="FLASH" fmap_nareas="36" area_offset="0x00000000" area_size="0x00400000" area_name="WP_RO" area_flags_raw="0x00" area_flags="" area_offset="0x00000000" area_size="0x00001000" area_name="SI_DESC" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x001ff000" area_name="IFWI" area_flags_raw="0x00" area_flags="" area_offset="0x00200000" area_size="0x00004000" area_name="RO_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x001fc000" area_name="RO_SECTION" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x00000800" area_name="FMAP" area_flags_raw="0x00" area_flags="" area_offset="0x00204800" area_size="0x00000040" area_name="RO_FRID" area_flags_raw="0x00" area_flags="" area_offset="0x00204840" area_size="0x000007c0" area_name="RO_FRID_PAD" area_flags_raw="0x00" area_flags="" area_offset="0x00205000" area_size="0x001bb000" area_name="COREBOOT" area_flags_raw="0x00" area_flags="" area_offset="0x003c0000" area_size="0x00040000" area_name="GBB" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00030000" area_name="MISC_RW" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00021000" area_name="RW_PRESERVE" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00021000" area_name="UNIFIED_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00010000" area_name="RECOVERY_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00410000" area_size="0x00010000" area_name="RW_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00420000" area_size="0x00001000" area_name="RW_VAR_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00421000" area_size="0x00003000" area_name="RW_ELOG" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00004000" area_name="RW_SHARED" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00002000" area_name="SHARED_DATA" area_flags_raw="0x00" area_flags="" area_offset="0x00426000" area_size="0x00002000" area_name="VBLOCK_DEV" area_flags_raw="0x00" area_flags="" area_offset="0x00428000" area_size="0x00002000" area_name="RW_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x0042a000" area_size="0x00005000" area_name="RW_NVRAM" area_flags_raw="0x00" area_flags="" area_offset="0x0042f000" area_size="0x00001000" area_name="FPF_STATUS" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00480000" area_name="RW_SECTION_A" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00010000" area_name="VBLOCK_A" area_flags_raw="0x00" area_flags="" area_offset="0x00440000" area_size="0x0046ffc0" area_name="FW_MAIN_A" area_flags_raw="0x00" area_flags="" area_offset="0x008affc0" area_size="0x00000040" area_name="RW_FWID_A" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00480000" area_name="RW_SECTION_B" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00010000" area_name="VBLOCK_B" area_flags_raw="0x00" area_flags="" area_offset="0x008c0000" area_size="0x0046ffc0" area_name="FW_MAIN_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d2ffc0" area_size="0x00000040" area_name="RW_FWID_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d30000" area_size="0x00040000" area_name="SMMSTORE" area_flags_raw="0x00" area_flags="" area_offset="0x00d70000" area_size="0x001c0000" area_name="RW_LEGACY" area_flags_raw="0x00" area_flags="" area_offset="0x00f30000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags="" area_offset="0x00f7f000" area_size="0x00080000" area_name="DEVICE_EXTENSION" area_flags_raw="0x00" area_flags="" area_offset="0x00fff000" area_size="0x00001000" area_name="UNUSED_HOLE" area_flags_raw="0x00" area_flags=""
Thanks James
By the way, do I need to be concerned with the final note at the end of the compile, "Written area will abut bottom of target region: any unused space will keep its current contents"? A 16MiB file written onto a 16MiB rom doesn't leave any "unused" space. Or, is this "unused space" referring to "unused" and "unusable" regions described in the FMAP layout?
I should be able to write this coreboot.rom file directly to the boot rom now?
I would resolve the IFD/FMAP discrepancy first. The IFD from the firmware images for all the octopus based boards I'm seeing here use the same BIOS region size as the SI_BIOS region in the FMAP.
Thanks James
On Tue, Jun 22, 2021 at 4:10 PM James Feeney james@nurealm.net wrote:
defconfig below, but:
$ grep -i fsp_car defconfig CONFIG_USE_APOLLOLAKE_FSP_CAR=y
$ grep -i fsp_car .config CONFIG_USE_APOLLOLAKE_FSP_CAR=y CONFIG_FSP_CAR=y
Hmm - I must have done that because it sounded "safe". Which of these choices is "correct"?
src/soc/intel/apollolake/Kconfig
choice prompt "Cache-as-ram implementation" default CAR_CQOS if !SOC_INTEL_GEMINILAKE default CAR_NEM help This option allows you to select how cache-as-ram (CAR) is set up.
config CAR_NEM bool "Non-evict mode" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_NEM help Traditionally, CAR is set up by using Non-Evict mode. This method does not allow CAR and cache to co-exist, because cache fills are block in NEM mode.
config CAR_CQOS bool "Cache Quality of Service" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_CQOS help Cache Quality of Service allows more fine-grained control of cache usage. As result, it is possible to set up portion of L2 cache for CAR and use remainder for actual caching.
config USE_APOLLOLAKE_FSP_CAR bool "Use FSP CAR" select FSP_CAR help Use FSP APIs to initialize & tear down the Cache-As-Ram.
endchoice
"Cache Quality of Service" seems more functional than "Non-Evict mode", but is it "better"?
Selecting *either* CONFIG_CAR_CQOS=y or the default CONFIG_CAR_NEM=y, the compile seems mostly successful, but then ends the same, with:
... Platform is: glk File build/coreboot.pre is 16777216 bytes Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000 make: *** [src/southbridge/intel/common/firmware/Makefile.inc:39: add_intel_firmware] Error 1
I need help with that.
Also, though I'm not sure what this does, coreboot does not like my enabling CONFIG_EC_GOOGLE_CHROMEEC_RTC, which then gives:
/var/src/coreboot/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/bootblock/ec/google/chromeec/ec.o: in function `rtc_get': /var/src/coreboot/coreboot/src/ec/google/chromeec/ec.c:776: multiple definition of `rtc_get'; build/bootblock/drivers/pc80/rtc/mc146818rtc.o:/var/src/coreboot/coreboot/src/drivers/pc80/rtc/mc146818rtc.c:225: first defined here make: *** [src/arch/x86/Makefile.inc:92: build/cbfs/fallback/bootblock.debug] Error 1
By the way, this chromebook recovery file includes a distinct SAR file that can be extracted from the COREBOOT section, but the SAR file-path option is not present in the config menu, using the current Kconfig:
src/drivers/wifi/generic/Kconfig
config USE_SAR bool default n help Enable it when wifi driver uses SAR configuration feature. ...
config WIFI_SAR_CBFS_FILEPATH string "The cbfs file which has WIFI SAR defaults" depends on USE_SAR default ""
Adding any kind of "prompt text" after "bool" causes the option to appear, and then the SAR file-path can be added.
Is this a mistake in the Kconfig? Or, what should be done with this SAR file?
Coreboot does seem to properly include my SAR file, since the coreboot.pre wifi_sar_defaults.hex file exactly matches the SAR file I specified in the WIFI_SAR_CBFS_FILEPATH.
Thanks James
$ cat defconfig CONFIG_ANY_TOOLCHAIN=y CONFIG_VENDOR_GOOGLE=y CONFIG_MAINBOARD_VENDOR="Octopus" CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Coreboot" # CONFIG_POST_IO is not set CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_USE_LEGACY_8254_TIMER=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CAR_CQOS=y # CONFIG_PAVP is not set CONFIG_X2APIC_RUNTIME=y CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_VALIDATE_INTEL_DESCRIPTOR=y CONFIG_ME_REGION_ALLOW_CPU_READ_ACCESS=y CONFIG_RUN_FSP_GOP=y CONFIG_TPM_PPI=y CONFIG_USE_SAR=y CONFIG_WIFI_SAR_CBFS_FILEPATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/wifi_sar-bluebird.hex" CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y CONFIG_COREINFO_SECONDARY_PAYLOAD=y CONFIG_MEMTEST_SECONDARY_PAYLOAD=y
$ util/cbfstool/cbfstool build/coreboot.pre print FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 59136 none cpu_microcode_blob.bin 0xe800 microcode 148480 none intel_fit 0x32c40 raw 80 none fallback/ramstage 0x32cc0 stage 110054 LZMA (257508 decompressed) config 0x4db00 raw 1184 none revision 0x4dfc0 raw 722 none build_info 0x4e2c0 raw 100 none fallback/dsdt.aml 0x4e380 raw 13347 none pt 0x51800 raw 20480 none pdpt 0x56840 raw 32 none dmic-2ch-48khz-16b.bin 0x56880 raw 3048 none dmic-4ch-48khz-16b.bin 0x574c0 raw 3048 none max98357-render-2ch-48khz-24b.bin 0x58100 raw 116 none dialog-2ch-48khz-24b.bin 0x581c0 raw 100 none fspm.bin 0x58280 fsp 417792 none vbt.bin 0xbe2c0 raw 1334 LZMA (5632 decompressed) wifi_sar_defaults.hex 0xbe840 raw 119 none (empty) 0xbe900 null 932 none fsps.bin 0xbecc0 fsp 192512 none fallback/postcar 0xedd00 stage 20388 none img/coreinfo 0xf2d00 simple elf 54609 none fallback/payload 0x100280 simple elf 249347 none img/memtest 0x13d0c0 simple elf 47497 none (empty) 0x148a80 null 3234276 none bootblock 0x45e480 bootblock 10288 none
On 6/22/21 8:17 AM, Matt DeVillier wrote:
FSP-T isn't used for APL/GLK Chromebooks. Sounds like your .config is selecting something it shouldn't. run `make savedefconfig` then post the contents of the defconfig. Possible CONFIG_USE_APOLLOLAKE_FSP_CAR is selected when it shouldn't be.
On Mon, Jun 21, 2021 at 9:17 PM James Feeney james@nurealm.net wrote:
$ cat defconfig ... CONFIG_ADD_FSP_BINARIES=y ...
There is *no* "fspt.bin" file in this chromebook recovery bios file used as source.
$ make ... src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file or directory #include <FsptUpd.h> ^~~~~~~~~~~ compilation terminated. make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 1
What Makefile is that? There is no such line 379.
$ find -name FsptUpd.h ... ./3rdparty/fsp/ApolloLakeFspBinPkg/Include/FsptUpd.h ...
$ less src/soc/intel/alderlake/Kconfig ... config FSP_HEADER_PATH string "Location of FSP headers" default "src/vendorcode/intel/fsp/fsp2_0/alderlake/"
$ less src/drivers/intel/fsp2_0/Kconfig ...
config FSP_T_FILE string "Intel FSP-T (temp RAM init) binary path and filename" if !FSP_FULL_FD depends on ADD_FSP_BINARIES depends on FSP_CAR default "$(obj)/Fsp_T.fd" if FSP_FULL_FD help The path and filename of the Intel FSP-T binary for this platform.
$ make nconfig ... > Generic Drivers ... (src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers
How did that get there? Not me...
$ ll src/vendorcode/intel/fsp/fsp2_0/glk total 116 drwxr-x--- 2 james james 4096 Oct 29 2020 . drwxr-x--- 9 james james 4096 Jun 14 19:04 .. -rw-r----- 1 james james 45977 Oct 29 2020 FspmUpd.h -rw-r----- 1 james james 57332 Oct 29 2020 FspsUpd.h -rw-r----- 1 james james 1967 Oct 29 2020 FspUpd.h
Why is src/soc/intel/apollolake/fspcar.c being built here? It seems that no fspt.bin file is needed.
James _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I'm an idiot and made a stupid math error when I calculated the size of the SI_BIOS region. 0xF7F000 - 0x1000 is 0xF7E000, not 0xF6F000.
https://review.coreboot.org/c/coreboot/+/55815 fixes it
On Wed, Jun 23, 2021 at 1:48 PM James Feeney james@nurealm.net wrote:
On 6/22/21 11:13 PM, Matt DeVillier wrote:
On Tue, Jun 22, 2021 at 10:59 PM James Feeney james@nurealm.net wrote:
On 6/22/21 4:32 PM, Matt DeVillier wrote:
I'm not sure why you enabled so many things not selected in my defconfig -- that's your issue.
Ha! Quite! Bit of a learning curve, though...
Ok, thanks for the clarifications - lots of things I do not need.
Use:
CONFIG_VENDOR_GOOGLE=y CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_RUN_FSP_GOP=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y
save as .config, then make olddefconfig.
CAR NEM (non-evict mode) is default, leave that.
No reason to select ChromeEC RTC, it's not supported.
WiFi SAR is only used by ChromeOS, only selectable when CONFIG_CHROMEOS=y
secondary payloads are almost certainly not useful with u-boot as primary payload.
I don't get any size mismatch errors when building for CASTA using the default FMAP. Have you modified your IFD at all?
I have not touched it.
Did you *actually* run ifdtool validate? Is your build, with no size mismatch, recent?
Using your config, and following your instructions, I get still the same result:
$ util/ifdtool/ifdtool -t build/coreboot.rom File build/coreboot.rom is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000
I see now that I need *not* enable "Validate Intel firmware descriptor", and the compile will complete without error.
But - I still have to wonder about that: "This config enables validating the Intel firmware descriptor against the fmap layout."
Does that not matter? Is that another "ChromeOS only" thing?
This issue has nothing to do with ChromeOS.
They differ in size by 60kiB. Hmm - "SI-BIOS" is one of the read-only sections given by "cbfstool /build/coreboot.rom layout -w", as is "FMAP". "BIOS" is one of the sections given by "ifdtool -d build/coreboot.rom". They just happen to have different sizes. It looks like "FMAP" is specifically a coreboot thing? The "SI" is an abbreviation for what?
As I understand, the IFD section was simply copied from the recovery file, and the FMAP section was generated from scratch, in the coreboot compile. Did coreboot make an error in not matching the given IFD?
the FMAP isn't generated from scratch, it's the default.fmd file in the google/octopus directory. If you look at that file (and at chromeos.fms), you can see why the layout and sizes are the way they are.
Aha! Ok, thanks for that.
src/mainboard/google/octopus/chromeos.fmd
# BIOS --> 4K to 0xf7f000Since the IFD BIOS region is larger in size than the FMAP SI-BIOS region, does it matter that the sizes are different? The IFD Intel ME, GbE, and Platform Data regions are all unused. There is nothing there to "mis-read", because of any potential location mistake - unless something tries to calculate a location "backward", from the end of the IFD BIOS region. Could the 60kiB size difference represent some kind of "padding"?
I'm curious about the IFD you're using. Dumping the IFD from bios-casta.ro-11297-83-3.rw-11297-83-3.bin (extracted from the octopus recovery image), the IFD layout matches that of the default.fmd used by coreboot.
Uhm - I'm confused. Using the value given in src/mainboard/google/octopus/chromeos.fmd, and reading the *comment*, which describes the BIOS region as from 0x1000 to 0xf7f000, then subtracting, gives the *size* of the - presumably - fmap "SI-BIOS" region as 0xf7e000, which exactly matches the value reported by ifdtool from the ChromeOS recovery bios file provided IFD BIOS region.
There is no discrepancy there - though, of course, this conclusion is presuming that the comment correctly interprets the meaning of the "BIOS" region, as everything between the "SI-DESC" region and the "DEVICE_EXTENSION" region, and that the chromeos.fmd file use of the term "BIOS" means exactly "SI-BIOS", as the term is expressed by cbfstool.
Incidentally, when I apply the ifdtool "validate" function to the ChromeOS recovery bios file, there is no output returned.
Is that the "correct" output when the validation is successful? If so, that's a really bad user interface design for ifdtool, since it is impossible to distinguish "no output" from "fails silently", as in "broken", especially given the otherwise "chatty" output, and the cryptic comment "Peculiar firmware descriptor", which casts doubt upon the result given. Is "Peculiar firmware descriptor" a kind of "error"?
Using the oldest recovery bios file that I have gives:
$ ifdtool -t images/bios-casta.ro-11297-193-0.rw-11297-217-0.bin File images/bios-casta.ro-11297-193-0.rw-11297-217-0.bin is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. [ That's the complete output. ]
Using the current recovery bios file gives the same truncated output:
$ ifdtool -t images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin File images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility.
To introspect further, there is the "fmap_decode" tool from the "flashmap" package, at https://chromium.googlesource.com/chromiumos/third_party/flashmap.
$ fmap_decode build/coreboot.rom fmap_signature="0x5f5f464d41505f5f" fmap_ver_major="1" fmap_ver_minor="1" fmap_base="0x0000000000000000" fmap_size="0x1000000" fmap_name="FLASH" fmap_nareas="13" area_offset="0x00000000" area_size="0x00001000" area_name="SI_DESC" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x00f6f000" area_name="SI_BIOS" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x001ff000" area_name="IFWI" area_flags_raw="0x00" area_flags="" area_offset="0x00a5f000" area_size="0x00040000" area_name="SMMSTORE" area_flags_raw="0x00" area_flags="" area_offset="0x00a9f000" area_size="0x00021000" area_name="UNIFIED_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00a9f000" area_size="0x00010000" area_name="RECOVERY_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00aaf000" area_size="0x00010000" area_name="RW_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00abf000" area_size="0x00001000" area_name="RW_VAR_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00ac0000" area_size="0x00000300" area_name="FMAP" area_flags_raw="0x00" area_flags="" area_offset="0x00ac0300" area_size="0x00460d00" area_name="COREBOOT" area_flags_raw="0x00" area_flags="" area_offset="0x00f21000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags="" area_offset="0x00f7f000" area_size="0x00080000" area_name="DEVICE_EXTENSION" area_flags_raw="0x00" area_flags="" area_offset="0x00fff000" area_size="0x00001000" area_name="UNUSED_HOLE" area_flags_raw="0x00" area_flags=""
Again, interpreting the comment in the chromeos.fmd file, everything between 0x00001000 and 0x00f7f000 does, in fact, have size 0x00f7e000, exactly matching the value as stated in the IFD. However, there is also an explicit "SI-BIOS" region given here, which does *not* correspond to the comment in the chromeos.fmd file, and which here has the size given as 0x00f6f000 != 0x00f7e000.
Similarly,
$ cbfstool build/coreboot.rom layout -w This image contains the following sections that can be accessed with this tool:
'SI_DESC' (size 4096, offset 0) 'SI_BIOS' (read-only, size 16183296, offset 4096) 'IFWI' (size 2093056, offset 4096) 'SMMSTORE' (size 262144, offset 10874880) 'UNIFIED_MRC_CACHE' (read-only, size 135168, offset 11137024) 'RECOVERY_MRC_CACHE' (size 65536, offset 11137024) 'RW_MRC_CACHE' (size 65536, offset 11202560) 'RW_VAR_MRC_CACHE' (size 4096, offset 11268096) 'FMAP' (read-only, size 768, offset 11272192) 'COREBOOT' (CBFS, size 4590848, offset 11272960) 'BIOS_UNUSABLE' (size 323584, offset 15863808) 'DEVICE_EXTENSION' (size 524288, offset 16248832) 'UNUSED_HOLE' (size 4096, offset 16773120)
...
The offset to the start of both the BIOS region and the SI_BIOS region are the same, given as 0x00001000. Taking the *size* of the SI_BIOS region, 0x00f6f000, and adding the offset, 0x00001000, then gives the offset to the beginning of the region immediately following the SI_BIOS region, 0x00f6f000 + 0x00001000 = 0x00f70000.
Compare this value to the offset to the beginning of the region immediately following the "BIOS_UNUSABLE" region, 0x00f21000 + 0x0004f000 = 0x00f70000. We shall note that they are exactly the same, 0x00f70000 = 0x00f70000.
There exists, then, an "undesignated" region, implied by the coreboot flashmap format, *between* the end of the "SI_BIOS" region, and the beginning of the "DEVICE_EXTENSION" region, from 0x00f70000 to 0x00f7f000, of size 0xf000.
(0x00f7f000 - 0x00f70000) = (0x00f7e000 - 0x00f6f000) = 0xf000
We may also note that there is a discrepancy between the definition of the "BIOS_UNUSABLE" region, as given in src/mainboard/google/octopus/chromeos.fmd, and this same region, as reported for the actual coreboot.rom file, as generated from the coreboot compile.
chromeos.fmd BIOS_UNUSABLE@0xf30000 0x4f000
fmap_decode build/coreboot.rom area_offset="0x00f21000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags=""
We may note that the region sizes given are the same, but that the entry offsets are different.
Comparing these offsets, we see this same discrepancy, 0xf000, here a result of a discrepancy in the offset location of this "BIOS_UNUSABLE" region, 0xf30000, as given in the chromeos.fmd file, when compared to the location of this region in the actually created coreboot.rom file, 0x00f21000.
0xf30000 - 0x00f21000 = 0xf000
Incidentally, we may note that there exists a similar flashmap file, src/mainboard/google/octopus/default.fmd, in which the definition of the "BIOS_UNUSABLE" regiion is not so precise, with no specific entry point offset defined:
src/mainboard/google/octopus/default.fmd
BIOS_UNUSABLE 0x4f000We may also note that the given size of the "SI_BIOS" region, 0x00f6f000, violates the rule described in these chromeos.fmd and default.fmd files:
# Currently, it is required that the BIOS region be a multiple of 8KiB.0x00f6f000 / 0x2000 -> 16183296 / 8192 = 1975.5
We then note that the difference in *size* between the "BIOS" and "SI_BIOS" regions, 0x00f7e000 - 0x00f6f000 = 0xf000, does not seem to have any clear relationship to the difference in the *end points* of these regions, 0x00f7f000 and 0xf70000, respectively. The *size* provided for the actual "BIOS" region does conform to the rule.
And finally, we may note additionally in the comment:
# ... Since the # descriptor at the beginning uses 4K and BIOS starts at an offset of # 4K, a hole of 4K is created towards the end of the flash to compensate # for the size requirement of BIOS region.and UNUSED_HOLE@0xfff000 0x1000
but, while the "undesignated" region of size of 0xf000 bytes is not an even multiple of 0x2000, being instead 7.5 multiples, it also encompasses a region with 6 multiples of 0x2000, such that the rule itself does not provide any justification for having an "undesignated" region of size 0xf000. The "undesignated" region size of precisely 0xf000 bytes does not seem to have any obvious motivation or rationale.
These results, then, raise questions:
Is the location of the "BIOS_UNUSABLE" region, as created in the coreboot.rom, in error, beginning 0xf000 bytes below where it is "suppose" to have been located, according to the chromeos.fmd specification file?
Why has this "undesgnated" 0xf000 byte region not, instead, been allocated to the "COREBOOT" region?
Are mystery "undesignated" regions in the rom layout "allowed/legal", under the rules of the coreboot fmap format?
Is this "undesignated" region a mistake?
Is there some error in the chromeos.fmd file, or in the google/octopus/default.fmd file?
Is the coreboot fmap format specification too ambiguous to provide precise results?
What is the definition of "SI_BIOS" region, precisely? What is the definition of "BIOS" region, precisely?
Why is "ifdtool --validate" comparing the size of the "BIOS" region to the size of the "SI_BIOS" region? Is this comparison a mistake? Is ifdtool "broken"? Or, was illuminating this kind of discrepancy the whole point of the validate function?
What, then, is the precise meaning of the implied state "ifdtool validated"?
Is the definition of the "SI-BIOS" region suppose to include the area to the *end* of the "BIOS_UNUSABLE" region, or instead, to the *beginning* of the "DEVICE_EXTENSION" region?
Who, or what, or where, is the "official" source of these definitions?
It may be important to note that there exists no such "SI_BIOS" region in the ChromeOS recovery bios file:
$ fmap_decode images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin fmap_signature="0x5f5f464d41505f5f" fmap_ver_major="1" fmap_ver_minor="1" fmap_base="0x0000000000000000" fmap_size="0x1000000" fmap_name="FLASH" fmap_nareas="36" area_offset="0x00000000" area_size="0x00400000" area_name="WP_RO" area_flags_raw="0x00" area_flags="" area_offset="0x00000000" area_size="0x00001000" area_name="SI_DESC" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x001ff000" area_name="IFWI" area_flags_raw="0x00" area_flags="" area_offset="0x00200000" area_size="0x00004000" area_name="RO_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x001fc000" area_name="RO_SECTION" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x00000800" area_name="FMAP" area_flags_raw="0x00" area_flags="" area_offset="0x00204800" area_size="0x00000040" area_name="RO_FRID" area_flags_raw="0x00" area_flags="" area_offset="0x00204840" area_size="0x000007c0" area_name="RO_FRID_PAD" area_flags_raw="0x00" area_flags="" area_offset="0x00205000" area_size="0x001bb000" area_name="COREBOOT" area_flags_raw="0x00" area_flags="" area_offset="0x003c0000" area_size="0x00040000" area_name="GBB" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00030000" area_name="MISC_RW" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00021000" area_name="RW_PRESERVE" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00021000" area_name="UNIFIED_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00010000" area_name="RECOVERY_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00410000" area_size="0x00010000" area_name="RW_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00420000" area_size="0x00001000" area_name="RW_VAR_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00421000" area_size="0x00003000" area_name="RW_ELOG" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00004000" area_name="RW_SHARED" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00002000" area_name="SHARED_DATA" area_flags_raw="0x00" area_flags="" area_offset="0x00426000" area_size="0x00002000" area_name="VBLOCK_DEV" area_flags_raw="0x00" area_flags="" area_offset="0x00428000" area_size="0x00002000" area_name="RW_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x0042a000" area_size="0x00005000" area_name="RW_NVRAM" area_flags_raw="0x00" area_flags="" area_offset="0x0042f000" area_size="0x00001000" area_name="FPF_STATUS" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00480000" area_name="RW_SECTION_A" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00010000" area_name="VBLOCK_A" area_flags_raw="0x00" area_flags="" area_offset="0x00440000" area_size="0x0046ffc0" area_name="FW_MAIN_A" area_flags_raw="0x00" area_flags="" area_offset="0x008affc0" area_size="0x00000040" area_name="RW_FWID_A" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00480000" area_name="RW_SECTION_B" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00010000" area_name="VBLOCK_B" area_flags_raw="0x00" area_flags="" area_offset="0x008c0000" area_size="0x0046ffc0" area_name="FW_MAIN_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d2ffc0" area_size="0x00000040" area_name="RW_FWID_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d30000" area_size="0x00040000" area_name="SMMSTORE" area_flags_raw="0x00" area_flags="" area_offset="0x00d70000" area_size="0x001c0000" area_name="RW_LEGACY" area_flags_raw="0x00" area_flags="" area_offset="0x00f30000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags="" area_offset="0x00f7f000" area_size="0x00080000" area_name="DEVICE_EXTENSION" area_flags_raw="0x00" area_flags="" area_offset="0x00fff000" area_size="0x00001000" area_name="UNUSED_HOLE" area_flags_raw="0x00" area_flags=""
Thanks James
By the way, do I need to be concerned with the final note at the end of the compile, "Written area will abut bottom of target region: any unused space will keep its current contents"? A 16MiB file written onto a 16MiB rom doesn't leave any "unused" space. Or, is this "unused space" referring to "unused" and "unusable" regions described in the FMAP layout?
I should be able to write this coreboot.rom file directly to the boot rom now?
I would resolve the IFD/FMAP discrepancy first. The IFD from the firmware images for all the octopus based boards I'm seeing here use the same BIOS region size as the SI_BIOS region in the FMAP.
Thanks James
On Tue, Jun 22, 2021 at 4:10 PM James Feeney james@nurealm.net wrote:
defconfig below, but:
$ grep -i fsp_car defconfig CONFIG_USE_APOLLOLAKE_FSP_CAR=y
$ grep -i fsp_car .config CONFIG_USE_APOLLOLAKE_FSP_CAR=y CONFIG_FSP_CAR=y
Hmm - I must have done that because it sounded "safe". Which of these choices is "correct"?
src/soc/intel/apollolake/Kconfig
choice prompt "Cache-as-ram implementation" default CAR_CQOS if !SOC_INTEL_GEMINILAKE default CAR_NEM help This option allows you to select how cache-as-ram (CAR) is set up.
config CAR_NEM bool "Non-evict mode" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_NEM help Traditionally, CAR is set up by using Non-Evict mode. This method does not allow CAR and cache to co-exist, because cache fills are block in NEM mode.
config CAR_CQOS bool "Cache Quality of Service" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_CQOS help Cache Quality of Service allows more fine-grained control of cache usage. As result, it is possible to set up portion of L2 cache for CAR and use remainder for actual caching.
config USE_APOLLOLAKE_FSP_CAR bool "Use FSP CAR" select FSP_CAR help Use FSP APIs to initialize & tear down the Cache-As-Ram.
endchoice
"Cache Quality of Service" seems more functional than "Non-Evict mode", but is it "better"?
Selecting *either* CONFIG_CAR_CQOS=y or the default CONFIG_CAR_NEM=y, the compile seems mostly successful, but then ends the same, with:
... Platform is: glk File build/coreboot.pre is 16777216 bytes Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000 make: *** [src/southbridge/intel/common/firmware/Makefile.inc:39: add_intel_firmware] Error 1
I need help with that.
Also, though I'm not sure what this does, coreboot does not like my enabling CONFIG_EC_GOOGLE_CHROMEEC_RTC, which then gives:
/var/src/coreboot/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/bootblock/ec/google/chromeec/ec.o: in function `rtc_get': /var/src/coreboot/coreboot/src/ec/google/chromeec/ec.c:776: multiple definition of `rtc_get'; build/bootblock/drivers/pc80/rtc/mc146818rtc.o:/var/src/coreboot/coreboot/src/drivers/pc80/rtc/mc146818rtc.c:225: first defined here make: *** [src/arch/x86/Makefile.inc:92: build/cbfs/fallback/bootblock.debug] Error 1
By the way, this chromebook recovery file includes a distinct SAR file that can be extracted from the COREBOOT section, but the SAR file-path option is not present in the config menu, using the current Kconfig:
src/drivers/wifi/generic/Kconfig
config USE_SAR bool default n help Enable it when wifi driver uses SAR configuration feature. ...
config WIFI_SAR_CBFS_FILEPATH string "The cbfs file which has WIFI SAR defaults" depends on USE_SAR default ""
Adding any kind of "prompt text" after "bool" causes the option to appear, and then the SAR file-path can be added.
Is this a mistake in the Kconfig? Or, what should be done with this SAR file?
Coreboot does seem to properly include my SAR file, since the coreboot.pre wifi_sar_defaults.hex file exactly matches the SAR file I specified in the WIFI_SAR_CBFS_FILEPATH.
Thanks James
$ cat defconfig CONFIG_ANY_TOOLCHAIN=y CONFIG_VENDOR_GOOGLE=y CONFIG_MAINBOARD_VENDOR="Octopus" CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Coreboot" # CONFIG_POST_IO is not set CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_USE_LEGACY_8254_TIMER=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CAR_CQOS=y # CONFIG_PAVP is not set CONFIG_X2APIC_RUNTIME=y CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_VALIDATE_INTEL_DESCRIPTOR=y CONFIG_ME_REGION_ALLOW_CPU_READ_ACCESS=y CONFIG_RUN_FSP_GOP=y CONFIG_TPM_PPI=y CONFIG_USE_SAR=y CONFIG_WIFI_SAR_CBFS_FILEPATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/wifi_sar-bluebird.hex" CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y CONFIG_COREINFO_SECONDARY_PAYLOAD=y CONFIG_MEMTEST_SECONDARY_PAYLOAD=y
$ util/cbfstool/cbfstool build/coreboot.pre print FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 59136 none cpu_microcode_blob.bin 0xe800 microcode 148480 none intel_fit 0x32c40 raw 80 none fallback/ramstage 0x32cc0 stage 110054 LZMA (257508 decompressed) config 0x4db00 raw 1184 none revision 0x4dfc0 raw 722 none build_info 0x4e2c0 raw 100 none fallback/dsdt.aml 0x4e380 raw 13347 none pt 0x51800 raw 20480 none pdpt 0x56840 raw 32 none dmic-2ch-48khz-16b.bin 0x56880 raw 3048 none dmic-4ch-48khz-16b.bin 0x574c0 raw 3048 none max98357-render-2ch-48khz-24b.bin 0x58100 raw 116 none dialog-2ch-48khz-24b.bin 0x581c0 raw 100 none fspm.bin 0x58280 fsp 417792 none vbt.bin 0xbe2c0 raw 1334 LZMA (5632 decompressed) wifi_sar_defaults.hex 0xbe840 raw 119 none (empty) 0xbe900 null 932 none fsps.bin 0xbecc0 fsp 192512 none fallback/postcar 0xedd00 stage 20388 none img/coreinfo 0xf2d00 simple elf 54609 none fallback/payload 0x100280 simple elf 249347 none img/memtest 0x13d0c0 simple elf 47497 none (empty) 0x148a80 null 3234276 none bootblock 0x45e480 bootblock 10288 none
On 6/22/21 8:17 AM, Matt DeVillier wrote:
FSP-T isn't used for APL/GLK Chromebooks. Sounds like your .config is selecting something it shouldn't. run `make savedefconfig` then post the contents of the defconfig. Possible CONFIG_USE_APOLLOLAKE_FSP_CAR is selected when it shouldn't be.
On Mon, Jun 21, 2021 at 9:17 PM James Feeney james@nurealm.net wrote: > > $ cat defconfig > ... > CONFIG_ADD_FSP_BINARIES=y > ... > > There is *no* "fspt.bin" file in this chromebook recovery bios file used as source. > > > $ make > ... > src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file or directory > #include <FsptUpd.h> > ^~~~~~~~~~~ > compilation terminated. > make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 1 > > > What Makefile is that? There is no such line 379. > > > $ find -name FsptUpd.h > ... > ./3rdparty/fsp/ApolloLakeFspBinPkg/Include/FsptUpd.h > ... > > > > $ less src/soc/intel/alderlake/Kconfig > ... > config FSP_HEADER_PATH > string "Location of FSP headers" > default "src/vendorcode/intel/fsp/fsp2_0/alderlake/" > > > $ less src/drivers/intel/fsp2_0/Kconfig > ... > > config FSP_T_FILE > string "Intel FSP-T (temp RAM init) binary path and filename" if !FSP_FULL_FD > depends on ADD_FSP_BINARIES > depends on FSP_CAR > default "$(obj)/Fsp_T.fd" if FSP_FULL_FD > help > The path and filename of the Intel FSP-T binary for this platform. > > > > > $ make nconfig > ... > > Generic Drivers > ... > (src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers > > How did that get there? Not me... > > $ ll src/vendorcode/intel/fsp/fsp2_0/glk > total 116 > drwxr-x--- 2 james james 4096 Oct 29 2020 . > drwxr-x--- 9 james james 4096 Jun 14 19:04 .. > -rw-r----- 1 james james 45977 Oct 29 2020 FspmUpd.h > -rw-r----- 1 james james 57332 Oct 29 2020 FspsUpd.h > -rw-r----- 1 james james 1967 Oct 29 2020 FspUpd.h > > > Why is src/soc/intel/apollolake/fspcar.c being built here? It seems that no fspt.bin file is needed. > > > James > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-leave@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 6/23/21 1:40 PM, Matt DeVillier wrote:
I'm an idiot and made a stupid math error when I calculated the size of the SI_BIOS region. 0xF7F000 - 0x1000 is 0xF7E000, not 0xF6F000.
Ha! I was a little suspicious of the suggestive pattern, 0xF7F000 - 0x10000 = 0xF6F000 vs 0xF7F000 - 0x1000 = 0xF7E000. But, I missed the hard-coded "SI_BIOS@0x1000 0xf6f000".
So, I see src/mainboard/google/octopus/default.fmd, specifically, is determining here.
Still, many questions from those of us less familiar. What is the meaning of "SI"? Does "SI_BIOS" have the same usage as "BIOS"? Coreboot "BIOS" is not the same thing as original "BIOS". <rant>...</rant>
Are there any "official" specifications for coreboot fmap format?
Wish me luck. I should have a functional bootrom image now!
Thanks James
On Wed, Jun 23, 2021 at 1:48 PM James Feeney james@nurealm.net wrote:
On 6/22/21 11:13 PM, Matt DeVillier wrote:
On Tue, Jun 22, 2021 at 10:59 PM James Feeney james@nurealm.net wrote:
On 6/22/21 4:32 PM, Matt DeVillier wrote:
I'm not sure why you enabled so many things not selected in my defconfig -- that's your issue.
Ha! Quite! Bit of a learning curve, though...
Ok, thanks for the clarifications - lots of things I do not need.
Use:
CONFIG_VENDOR_GOOGLE=y CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_RUN_FSP_GOP=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y
save as .config, then make olddefconfig.
CAR NEM (non-evict mode) is default, leave that.
No reason to select ChromeEC RTC, it's not supported.
WiFi SAR is only used by ChromeOS, only selectable when CONFIG_CHROMEOS=y
secondary payloads are almost certainly not useful with u-boot as primary payload.
I don't get any size mismatch errors when building for CASTA using the default FMAP. Have you modified your IFD at all?
I have not touched it.
Did you *actually* run ifdtool validate? Is your build, with no size mismatch, recent?
Using your config, and following your instructions, I get still the same result:
$ util/ifdtool/ifdtool -t build/coreboot.rom File build/coreboot.rom is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000
I see now that I need *not* enable "Validate Intel firmware descriptor", and the compile will complete without error.
But - I still have to wonder about that: "This config enables validating the Intel firmware descriptor against the fmap layout."
Does that not matter? Is that another "ChromeOS only" thing?
This issue has nothing to do with ChromeOS.
They differ in size by 60kiB. Hmm - "SI-BIOS" is one of the read-only sections given by "cbfstool /build/coreboot.rom layout -w", as is "FMAP". "BIOS" is one of the sections given by "ifdtool -d build/coreboot.rom". They just happen to have different sizes. It looks like "FMAP" is specifically a coreboot thing? The "SI" is an abbreviation for what?
As I understand, the IFD section was simply copied from the recovery file, and the FMAP section was generated from scratch, in the coreboot compile. Did coreboot make an error in not matching the given IFD?
the FMAP isn't generated from scratch, it's the default.fmd file in the google/octopus directory. If you look at that file (and at chromeos.fms), you can see why the layout and sizes are the way they are.
Aha! Ok, thanks for that.
src/mainboard/google/octopus/chromeos.fmd
# BIOS --> 4K to 0xf7f000Since the IFD BIOS region is larger in size than the FMAP SI-BIOS region, does it matter that the sizes are different? The IFD Intel ME, GbE, and Platform Data regions are all unused. There is nothing there to "mis-read", because of any potential location mistake - unless something tries to calculate a location "backward", from the end of the IFD BIOS region. Could the 60kiB size difference represent some kind of "padding"?
I'm curious about the IFD you're using. Dumping the IFD from bios-casta.ro-11297-83-3.rw-11297-83-3.bin (extracted from the octopus recovery image), the IFD layout matches that of the default.fmd used by coreboot.
Uhm - I'm confused. Using the value given in src/mainboard/google/octopus/chromeos.fmd, and reading the *comment*, which describes the BIOS region as from 0x1000 to 0xf7f000, then subtracting, gives the *size* of the - presumably - fmap "SI-BIOS" region as 0xf7e000, which exactly matches the value reported by ifdtool from the ChromeOS recovery bios file provided IFD BIOS region.
There is no discrepancy there - though, of course, this conclusion is presuming that the comment correctly interprets the meaning of the "BIOS" region, as everything between the "SI-DESC" region and the "DEVICE_EXTENSION" region, and that the chromeos.fmd file use of the term "BIOS" means exactly "SI-BIOS", as the term is expressed by cbfstool.
Incidentally, when I apply the ifdtool "validate" function to the ChromeOS recovery bios file, there is no output returned.
Is that the "correct" output when the validation is successful? If so, that's a really bad user interface design for ifdtool, since it is impossible to distinguish "no output" from "fails silently", as in "broken", especially given the otherwise "chatty" output, and the cryptic comment "Peculiar firmware descriptor", which casts doubt upon the result given. Is "Peculiar firmware descriptor" a kind of "error"?
Using the oldest recovery bios file that I have gives:
$ ifdtool -t images/bios-casta.ro-11297-193-0.rw-11297-217-0.bin File images/bios-casta.ro-11297-193-0.rw-11297-217-0.bin is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. [ That's the complete output. ]
Using the current recovery bios file gives the same truncated output:
$ ifdtool -t images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin File images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility.
To introspect further, there is the "fmap_decode" tool from the "flashmap" package, at https://chromium.googlesource.com/chromiumos/third_party/flashmap.
$ fmap_decode build/coreboot.rom fmap_signature="0x5f5f464d41505f5f" fmap_ver_major="1" fmap_ver_minor="1" fmap_base="0x0000000000000000" fmap_size="0x1000000" fmap_name="FLASH" fmap_nareas="13" area_offset="0x00000000" area_size="0x00001000" area_name="SI_DESC" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x00f6f000" area_name="SI_BIOS" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x001ff000" area_name="IFWI" area_flags_raw="0x00" area_flags="" area_offset="0x00a5f000" area_size="0x00040000" area_name="SMMSTORE" area_flags_raw="0x00" area_flags="" area_offset="0x00a9f000" area_size="0x00021000" area_name="UNIFIED_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00a9f000" area_size="0x00010000" area_name="RECOVERY_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00aaf000" area_size="0x00010000" area_name="RW_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00abf000" area_size="0x00001000" area_name="RW_VAR_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00ac0000" area_size="0x00000300" area_name="FMAP" area_flags_raw="0x00" area_flags="" area_offset="0x00ac0300" area_size="0x00460d00" area_name="COREBOOT" area_flags_raw="0x00" area_flags="" area_offset="0x00f21000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags="" area_offset="0x00f7f000" area_size="0x00080000" area_name="DEVICE_EXTENSION" area_flags_raw="0x00" area_flags="" area_offset="0x00fff000" area_size="0x00001000" area_name="UNUSED_HOLE" area_flags_raw="0x00" area_flags=""
Again, interpreting the comment in the chromeos.fmd file, everything between 0x00001000 and 0x00f7f000 does, in fact, have size 0x00f7e000, exactly matching the value as stated in the IFD. However, there is also an explicit "SI-BIOS" region given here, which does *not* correspond to the comment in the chromeos.fmd file, and which here has the size given as 0x00f6f000 != 0x00f7e000.
Similarly,
$ cbfstool build/coreboot.rom layout -w This image contains the following sections that can be accessed with this tool:
'SI_DESC' (size 4096, offset 0) 'SI_BIOS' (read-only, size 16183296, offset 4096) 'IFWI' (size 2093056, offset 4096) 'SMMSTORE' (size 262144, offset 10874880) 'UNIFIED_MRC_CACHE' (read-only, size 135168, offset 11137024) 'RECOVERY_MRC_CACHE' (size 65536, offset 11137024) 'RW_MRC_CACHE' (size 65536, offset 11202560) 'RW_VAR_MRC_CACHE' (size 4096, offset 11268096) 'FMAP' (read-only, size 768, offset 11272192) 'COREBOOT' (CBFS, size 4590848, offset 11272960) 'BIOS_UNUSABLE' (size 323584, offset 15863808) 'DEVICE_EXTENSION' (size 524288, offset 16248832) 'UNUSED_HOLE' (size 4096, offset 16773120)
...
The offset to the start of both the BIOS region and the SI_BIOS region are the same, given as 0x00001000. Taking the *size* of the SI_BIOS region, 0x00f6f000, and adding the offset, 0x00001000, then gives the offset to the beginning of the region immediately following the SI_BIOS region, 0x00f6f000 + 0x00001000 = 0x00f70000.
Compare this value to the offset to the beginning of the region immediately following the "BIOS_UNUSABLE" region, 0x00f21000 + 0x0004f000 = 0x00f70000. We shall note that they are exactly the same, 0x00f70000 = 0x00f70000.
There exists, then, an "undesignated" region, implied by the coreboot flashmap format, *between* the end of the "SI_BIOS" region, and the beginning of the "DEVICE_EXTENSION" region, from 0x00f70000 to 0x00f7f000, of size 0xf000.
(0x00f7f000 - 0x00f70000) = (0x00f7e000 - 0x00f6f000) = 0xf000
We may also note that there is a discrepancy between the definition of the "BIOS_UNUSABLE" region, as given in src/mainboard/google/octopus/chromeos.fmd, and this same region, as reported for the actual coreboot.rom file, as generated from the coreboot compile.
chromeos.fmd BIOS_UNUSABLE@0xf30000 0x4f000
fmap_decode build/coreboot.rom area_offset="0x00f21000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags=""
We may note that the region sizes given are the same, but that the entry offsets are different.
Comparing these offsets, we see this same discrepancy, 0xf000, here a result of a discrepancy in the offset location of this "BIOS_UNUSABLE" region, 0xf30000, as given in the chromeos.fmd file, when compared to the location of this region in the actually created coreboot.rom file, 0x00f21000.
0xf30000 - 0x00f21000 = 0xf000
Incidentally, we may note that there exists a similar flashmap file, src/mainboard/google/octopus/default.fmd, in which the definition of the "BIOS_UNUSABLE" regiion is not so precise, with no specific entry point offset defined:
src/mainboard/google/octopus/default.fmd
BIOS_UNUSABLE 0x4f000We may also note that the given size of the "SI_BIOS" region, 0x00f6f000, violates the rule described in these chromeos.fmd and default.fmd files:
# Currently, it is required that the BIOS region be a multiple of 8KiB.0x00f6f000 / 0x2000 -> 16183296 / 8192 = 1975.5
We then note that the difference in *size* between the "BIOS" and "SI_BIOS" regions, 0x00f7e000 - 0x00f6f000 = 0xf000, does not seem to have any clear relationship to the difference in the *end points* of these regions, 0x00f7f000 and 0xf70000, respectively. The *size* provided for the actual "BIOS" region does conform to the rule.
And finally, we may note additionally in the comment:
# ... Since the # descriptor at the beginning uses 4K and BIOS starts at an offset of # 4K, a hole of 4K is created towards the end of the flash to compensate # for the size requirement of BIOS region.and UNUSED_HOLE@0xfff000 0x1000
but, while the "undesignated" region of size of 0xf000 bytes is not an even multiple of 0x2000, being instead 7.5 multiples, it also encompasses a region with 6 multiples of 0x2000, such that the rule itself does not provide any justification for having an "undesignated" region of size 0xf000. The "undesignated" region size of precisely 0xf000 bytes does not seem to have any obvious motivation or rationale.
These results, then, raise questions:
Is the location of the "BIOS_UNUSABLE" region, as created in the coreboot.rom, in error, beginning 0xf000 bytes below where it is "suppose" to have been located, according to the chromeos.fmd specification file?
Why has this "undesgnated" 0xf000 byte region not, instead, been allocated to the "COREBOOT" region?
Are mystery "undesignated" regions in the rom layout "allowed/legal", under the rules of the coreboot fmap format?
Is this "undesignated" region a mistake?
Is there some error in the chromeos.fmd file, or in the google/octopus/default.fmd file?
Is the coreboot fmap format specification too ambiguous to provide precise results?
What is the definition of "SI_BIOS" region, precisely? What is the definition of "BIOS" region, precisely?
Why is "ifdtool --validate" comparing the size of the "BIOS" region to the size of the "SI_BIOS" region? Is this comparison a mistake? Is ifdtool "broken"? Or, was illuminating this kind of discrepancy the whole point of the validate function?
What, then, is the precise meaning of the implied state "ifdtool validated"?
Is the definition of the "SI-BIOS" region suppose to include the area to the *end* of the "BIOS_UNUSABLE" region, or instead, to the *beginning* of the "DEVICE_EXTENSION" region?
Who, or what, or where, is the "official" source of these definitions?
It may be important to note that there exists no such "SI_BIOS" region in the ChromeOS recovery bios file:
$ fmap_decode images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin fmap_signature="0x5f5f464d41505f5f" fmap_ver_major="1" fmap_ver_minor="1" fmap_base="0x0000000000000000" fmap_size="0x1000000" fmap_name="FLASH" fmap_nareas="36" area_offset="0x00000000" area_size="0x00400000" area_name="WP_RO" area_flags_raw="0x00" area_flags="" area_offset="0x00000000" area_size="0x00001000" area_name="SI_DESC" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x001ff000" area_name="IFWI" area_flags_raw="0x00" area_flags="" area_offset="0x00200000" area_size="0x00004000" area_name="RO_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x001fc000" area_name="RO_SECTION" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x00000800" area_name="FMAP" area_flags_raw="0x00" area_flags="" area_offset="0x00204800" area_size="0x00000040" area_name="RO_FRID" area_flags_raw="0x00" area_flags="" area_offset="0x00204840" area_size="0x000007c0" area_name="RO_FRID_PAD" area_flags_raw="0x00" area_flags="" area_offset="0x00205000" area_size="0x001bb000" area_name="COREBOOT" area_flags_raw="0x00" area_flags="" area_offset="0x003c0000" area_size="0x00040000" area_name="GBB" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00030000" area_name="MISC_RW" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00021000" area_name="RW_PRESERVE" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00021000" area_name="UNIFIED_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00010000" area_name="RECOVERY_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00410000" area_size="0x00010000" area_name="RW_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00420000" area_size="0x00001000" area_name="RW_VAR_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00421000" area_size="0x00003000" area_name="RW_ELOG" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00004000" area_name="RW_SHARED" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00002000" area_name="SHARED_DATA" area_flags_raw="0x00" area_flags="" area_offset="0x00426000" area_size="0x00002000" area_name="VBLOCK_DEV" area_flags_raw="0x00" area_flags="" area_offset="0x00428000" area_size="0x00002000" area_name="RW_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x0042a000" area_size="0x00005000" area_name="RW_NVRAM" area_flags_raw="0x00" area_flags="" area_offset="0x0042f000" area_size="0x00001000" area_name="FPF_STATUS" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00480000" area_name="RW_SECTION_A" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00010000" area_name="VBLOCK_A" area_flags_raw="0x00" area_flags="" area_offset="0x00440000" area_size="0x0046ffc0" area_name="FW_MAIN_A" area_flags_raw="0x00" area_flags="" area_offset="0x008affc0" area_size="0x00000040" area_name="RW_FWID_A" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00480000" area_name="RW_SECTION_B" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00010000" area_name="VBLOCK_B" area_flags_raw="0x00" area_flags="" area_offset="0x008c0000" area_size="0x0046ffc0" area_name="FW_MAIN_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d2ffc0" area_size="0x00000040" area_name="RW_FWID_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d30000" area_size="0x00040000" area_name="SMMSTORE" area_flags_raw="0x00" area_flags="" area_offset="0x00d70000" area_size="0x001c0000" area_name="RW_LEGACY" area_flags_raw="0x00" area_flags="" area_offset="0x00f30000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags="" area_offset="0x00f7f000" area_size="0x00080000" area_name="DEVICE_EXTENSION" area_flags_raw="0x00" area_flags="" area_offset="0x00fff000" area_size="0x00001000" area_name="UNUSED_HOLE" area_flags_raw="0x00" area_flags=""
Thanks James
By the way, do I need to be concerned with the final note at the end of the compile, "Written area will abut bottom of target region: any unused space will keep its current contents"? A 16MiB file written onto a 16MiB rom doesn't leave any "unused" space. Or, is this "unused space" referring to "unused" and "unusable" regions described in the FMAP layout?
I should be able to write this coreboot.rom file directly to the boot rom now?
I would resolve the IFD/FMAP discrepancy first. The IFD from the firmware images for all the octopus based boards I'm seeing here use the same BIOS region size as the SI_BIOS region in the FMAP.
Thanks James
On Tue, Jun 22, 2021 at 4:10 PM James Feeney james@nurealm.net wrote:
defconfig below, but:
$ grep -i fsp_car defconfig CONFIG_USE_APOLLOLAKE_FSP_CAR=y
$ grep -i fsp_car .config CONFIG_USE_APOLLOLAKE_FSP_CAR=y CONFIG_FSP_CAR=y
Hmm - I must have done that because it sounded "safe". Which of these choices is "correct"?
src/soc/intel/apollolake/Kconfig
choice prompt "Cache-as-ram implementation" default CAR_CQOS if !SOC_INTEL_GEMINILAKE default CAR_NEM help This option allows you to select how cache-as-ram (CAR) is set up.
config CAR_NEM bool "Non-evict mode" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_NEM help Traditionally, CAR is set up by using Non-Evict mode. This method does not allow CAR and cache to co-exist, because cache fills are block in NEM mode.
config CAR_CQOS bool "Cache Quality of Service" select SOC_INTEL_COMMON_BLOCK_CAR select INTEL_CAR_CQOS help Cache Quality of Service allows more fine-grained control of cache usage. As result, it is possible to set up portion of L2 cache for CAR and use remainder for actual caching.
config USE_APOLLOLAKE_FSP_CAR bool "Use FSP CAR" select FSP_CAR help Use FSP APIs to initialize & tear down the Cache-As-Ram.
endchoice
"Cache Quality of Service" seems more functional than "Non-Evict mode", but is it "better"?
Selecting *either* CONFIG_CAR_CQOS=y or the default CONFIG_CAR_NEM=y, the compile seems mostly successful, but then ends the same, with:
... Platform is: glk File build/coreboot.pre is 16777216 bytes Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000 make: *** [src/southbridge/intel/common/firmware/Makefile.inc:39: add_intel_firmware] Error 1
I need help with that.
Also, though I'm not sure what this does, coreboot does not like my enabling CONFIG_EC_GOOGLE_CHROMEEC_RTC, which then gives:
/var/src/coreboot/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/bootblock/ec/google/chromeec/ec.o: in function `rtc_get': /var/src/coreboot/coreboot/src/ec/google/chromeec/ec.c:776: multiple definition of `rtc_get'; build/bootblock/drivers/pc80/rtc/mc146818rtc.o:/var/src/coreboot/coreboot/src/drivers/pc80/rtc/mc146818rtc.c:225: first defined here make: *** [src/arch/x86/Makefile.inc:92: build/cbfs/fallback/bootblock.debug] Error 1
By the way, this chromebook recovery file includes a distinct SAR file that can be extracted from the COREBOOT section, but the SAR file-path option is not present in the config menu, using the current Kconfig:
src/drivers/wifi/generic/Kconfig
config USE_SAR bool default n help Enable it when wifi driver uses SAR configuration feature. ...
config WIFI_SAR_CBFS_FILEPATH string "The cbfs file which has WIFI SAR defaults" depends on USE_SAR default ""
Adding any kind of "prompt text" after "bool" causes the option to appear, and then the SAR file-path can be added.
Is this a mistake in the Kconfig? Or, what should be done with this SAR file?
Coreboot does seem to properly include my SAR file, since the coreboot.pre wifi_sar_defaults.hex file exactly matches the SAR file I specified in the WIFI_SAR_CBFS_FILEPATH.
Thanks James
$ cat defconfig CONFIG_ANY_TOOLCHAIN=y CONFIG_VENDOR_GOOGLE=y CONFIG_MAINBOARD_VENDOR="Octopus" CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Coreboot" # CONFIG_POST_IO is not set CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_USE_LEGACY_8254_TIMER=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CAR_CQOS=y # CONFIG_PAVP is not set CONFIG_X2APIC_RUNTIME=y CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_VALIDATE_INTEL_DESCRIPTOR=y CONFIG_ME_REGION_ALLOW_CPU_READ_ACCESS=y CONFIG_RUN_FSP_GOP=y CONFIG_TPM_PPI=y CONFIG_USE_SAR=y CONFIG_WIFI_SAR_CBFS_FILEPATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/wifi_sar-bluebird.hex" CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y CONFIG_COREINFO_SECONDARY_PAYLOAD=y CONFIG_MEMTEST_SECONDARY_PAYLOAD=y
$ util/cbfstool/cbfstool build/coreboot.pre print FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 59136 none cpu_microcode_blob.bin 0xe800 microcode 148480 none intel_fit 0x32c40 raw 80 none fallback/ramstage 0x32cc0 stage 110054 LZMA (257508 decompressed) config 0x4db00 raw 1184 none revision 0x4dfc0 raw 722 none build_info 0x4e2c0 raw 100 none fallback/dsdt.aml 0x4e380 raw 13347 none pt 0x51800 raw 20480 none pdpt 0x56840 raw 32 none dmic-2ch-48khz-16b.bin 0x56880 raw 3048 none dmic-4ch-48khz-16b.bin 0x574c0 raw 3048 none max98357-render-2ch-48khz-24b.bin 0x58100 raw 116 none dialog-2ch-48khz-24b.bin 0x581c0 raw 100 none fspm.bin 0x58280 fsp 417792 none vbt.bin 0xbe2c0 raw 1334 LZMA (5632 decompressed) wifi_sar_defaults.hex 0xbe840 raw 119 none (empty) 0xbe900 null 932 none fsps.bin 0xbecc0 fsp 192512 none fallback/postcar 0xedd00 stage 20388 none img/coreinfo 0xf2d00 simple elf 54609 none fallback/payload 0x100280 simple elf 249347 none img/memtest 0x13d0c0 simple elf 47497 none (empty) 0x148a80 null 3234276 none bootblock 0x45e480 bootblock 10288 none
On 6/22/21 8:17 AM, Matt DeVillier wrote: > FSP-T isn't used for APL/GLK Chromebooks. Sounds like your .config is > selecting something it shouldn't. run `make savedefconfig` then post > the contents of the defconfig. Possible CONFIG_USE_APOLLOLAKE_FSP_CAR > is selected when it shouldn't be. > > On Mon, Jun 21, 2021 at 9:17 PM James Feeney james@nurealm.net wrote: >> >> $ cat defconfig >> ... >> CONFIG_ADD_FSP_BINARIES=y >> ... >> >> There is *no* "fspt.bin" file in this chromebook recovery bios file used as source. >> >> >> $ make >> ... >> src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file or directory >> #include <FsptUpd.h> >> ^~~~~~~~~~~ >> compilation terminated. >> make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 1 >> >> >> What Makefile is that? There is no such line 379. >> >> >> $ find -name FsptUpd.h >> ... >> ./3rdparty/fsp/ApolloLakeFspBinPkg/Include/FsptUpd.h >> ... >> >> >> >> $ less src/soc/intel/alderlake/Kconfig >> ... >> config FSP_HEADER_PATH >> string "Location of FSP headers" >> default "src/vendorcode/intel/fsp/fsp2_0/alderlake/" >> >> >> $ less src/drivers/intel/fsp2_0/Kconfig >> ... >> >> config FSP_T_FILE >> string "Intel FSP-T (temp RAM init) binary path and filename" if !FSP_FULL_FD >> depends on ADD_FSP_BINARIES >> depends on FSP_CAR >> default "$(obj)/Fsp_T.fd" if FSP_FULL_FD >> help >> The path and filename of the Intel FSP-T binary for this platform. >> >> >> >> >> $ make nconfig >> ... >> > Generic Drivers >> ... >> (src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers >> >> How did that get there? Not me... >> >> $ ll src/vendorcode/intel/fsp/fsp2_0/glk >> total 116 >> drwxr-x--- 2 james james 4096 Oct 29 2020 . >> drwxr-x--- 9 james james 4096 Jun 14 19:04 .. >> -rw-r----- 1 james james 45977 Oct 29 2020 FspmUpd.h >> -rw-r----- 1 james james 57332 Oct 29 2020 FspsUpd.h >> -rw-r----- 1 james james 1967 Oct 29 2020 FspUpd.h >> >> >> Why is src/soc/intel/apollolake/fspcar.c being built here? It seems that no fspt.bin file is needed. >> >> >> James >> _______________________________________________ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-leave@coreboot.org > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-leave@coreboot.org >
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Wed, Jun 23, 2021 at 4:36 PM James Feeney james@nurealm.net wrote:
On 6/23/21 1:40 PM, Matt DeVillier wrote:
I'm an idiot and made a stupid math error when I calculated the size of the SI_BIOS region. 0xF7F000 - 0x1000 is 0xF7E000, not 0xF6F000.
Ha! I was a little suspicious of the suggestive pattern, 0xF7F000 - 0x10000 = 0xF6F000 vs 0xF7F000 - 0x1000 = 0xF7E000. But, I missed the hard-coded "SI_BIOS@0x1000 0xf6f000".
So, I see src/mainboard/google/octopus/default.fmd, specifically, is determining here.
Still, many questions from those of us less familiar. What is the meaning of "SI"? Does "SI_BIOS" have the same usage as "BIOS"? Coreboot "BIOS" is not the same thing as original "BIOS". <rant>...</rant>
coreboot's FMAP is a more finely grained map of the firmware image than the IFD's, which is necessary for coreboot (and vboot, and other utils) to locate things in the different regions.
I'm not sure where the SI_BIOS nomenclature comes from, it's a Google thing I think so one of those folks from the old days would have to chime in. On older boards it did/does encapsulate all of the coreboot FMAP regions which reside inside the IFD's BIOS region.
Are there any "official" specifications for coreboot fmap format?
https://doc.coreboot.org/lib/flashmap.html
Wish me luck. I should have a functional bootrom image now!
well, it would have been functional before, as I've apparently been using improperly sized images for quite some time :)
Thanks James
On Wed, Jun 23, 2021 at 1:48 PM James Feeney james@nurealm.net wrote:
On 6/22/21 11:13 PM, Matt DeVillier wrote:
On Tue, Jun 22, 2021 at 10:59 PM James Feeney james@nurealm.net wrote:
On 6/22/21 4:32 PM, Matt DeVillier wrote:
I'm not sure why you enabled so many things not selected in my defconfig -- that's your issue.
Ha! Quite! Bit of a learning curve, though...
Ok, thanks for the clarifications - lots of things I do not need.
Use:
CONFIG_VENDOR_GOOGLE=y CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" # CONFIG_POST_DEVICE is not set CONFIG_BOARD_GOOGLE_CASTA=y CONFIG_INCLUDE_NHLT_BLOBS=y CONFIG_NEED_IFWI=y CONFIG_HAVE_IFD_BIN=y CONFIG_ADD_FSP_BINARIES=y CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" CONFIG_RUN_FSP_GOP=y CONFIG_PAYLOAD_UBOOT=y CONFIG_UBOOT_MASTER=y
save as .config, then make olddefconfig.
CAR NEM (non-evict mode) is default, leave that.
No reason to select ChromeEC RTC, it's not supported.
WiFi SAR is only used by ChromeOS, only selectable when CONFIG_CHROMEOS=y
secondary payloads are almost certainly not useful with u-boot as primary payload.
I don't get any size mismatch errors when building for CASTA using the default FMAP. Have you modified your IFD at all?
I have not touched it.
Did you *actually* run ifdtool validate? Is your build, with no size mismatch, recent?
Using your config, and following your instructions, I get still the same result:
$ util/ifdtool/ifdtool -t build/coreboot.rom File build/coreboot.rom is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000
I see now that I need *not* enable "Validate Intel firmware descriptor", and the compile will complete without error.
But - I still have to wonder about that: "This config enables validating the Intel firmware descriptor against the fmap layout."
Does that not matter? Is that another "ChromeOS only" thing?
This issue has nothing to do with ChromeOS.
They differ in size by 60kiB. Hmm - "SI-BIOS" is one of the read-only sections given by "cbfstool /build/coreboot.rom layout -w", as is "FMAP". "BIOS" is one of the sections given by "ifdtool -d build/coreboot.rom". They just happen to have different sizes. It looks like "FMAP" is specifically a coreboot thing? The "SI" is an abbreviation for what?
As I understand, the IFD section was simply copied from the recovery file, and the FMAP section was generated from scratch, in the coreboot compile. Did coreboot make an error in not matching the given IFD?
the FMAP isn't generated from scratch, it's the default.fmd file in the google/octopus directory. If you look at that file (and at chromeos.fms), you can see why the layout and sizes are the way they are.
Aha! Ok, thanks for that.
src/mainboard/google/octopus/chromeos.fmd
# BIOS --> 4K to 0xf7f000Since the IFD BIOS region is larger in size than the FMAP SI-BIOS region, does it matter that the sizes are different? The IFD Intel ME, GbE, and Platform Data regions are all unused. There is nothing there to "mis-read", because of any potential location mistake - unless something tries to calculate a location "backward", from the end of the IFD BIOS region. Could the 60kiB size difference represent some kind of "padding"?
I'm curious about the IFD you're using. Dumping the IFD from bios-casta.ro-11297-83-3.rw-11297-83-3.bin (extracted from the octopus recovery image), the IFD layout matches that of the default.fmd used by coreboot.
Uhm - I'm confused. Using the value given in src/mainboard/google/octopus/chromeos.fmd, and reading the *comment*, which describes the BIOS region as from 0x1000 to 0xf7f000, then subtracting, gives the *size* of the - presumably - fmap "SI-BIOS" region as 0xf7e000, which exactly matches the value reported by ifdtool from the ChromeOS recovery bios file provided IFD BIOS region.
There is no discrepancy there - though, of course, this conclusion is presuming that the comment correctly interprets the meaning of the "BIOS" region, as everything between the "SI-DESC" region and the "DEVICE_EXTENSION" region, and that the chromeos.fmd file use of the term "BIOS" means exactly "SI-BIOS", as the term is expressed by cbfstool.
Incidentally, when I apply the ifdtool "validate" function to the ChromeOS recovery bios file, there is no output returned.
Is that the "correct" output when the validation is successful? If so, that's a really bad user interface design for ifdtool, since it is impossible to distinguish "no output" from "fails silently", as in "broken", especially given the otherwise "chatty" output, and the cryptic comment "Peculiar firmware descriptor", which casts doubt upon the result given. Is "Peculiar firmware descriptor" a kind of "error"?
Using the oldest recovery bios file that I have gives:
$ ifdtool -t images/bios-casta.ro-11297-193-0.rw-11297-217-0.bin File images/bios-casta.ro-11297-193-0.rw-11297-217-0.bin is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. [ That's the complete output. ]
Using the current recovery bios file gives the same truncated output:
$ ifdtool -t images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin File images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility.
To introspect further, there is the "fmap_decode" tool from the "flashmap" package, at https://chromium.googlesource.com/chromiumos/third_party/flashmap.
$ fmap_decode build/coreboot.rom fmap_signature="0x5f5f464d41505f5f" fmap_ver_major="1" fmap_ver_minor="1" fmap_base="0x0000000000000000" fmap_size="0x1000000" fmap_name="FLASH" fmap_nareas="13" area_offset="0x00000000" area_size="0x00001000" area_name="SI_DESC" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x00f6f000" area_name="SI_BIOS" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x001ff000" area_name="IFWI" area_flags_raw="0x00" area_flags="" area_offset="0x00a5f000" area_size="0x00040000" area_name="SMMSTORE" area_flags_raw="0x00" area_flags="" area_offset="0x00a9f000" area_size="0x00021000" area_name="UNIFIED_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00a9f000" area_size="0x00010000" area_name="RECOVERY_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00aaf000" area_size="0x00010000" area_name="RW_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00abf000" area_size="0x00001000" area_name="RW_VAR_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00ac0000" area_size="0x00000300" area_name="FMAP" area_flags_raw="0x00" area_flags="" area_offset="0x00ac0300" area_size="0x00460d00" area_name="COREBOOT" area_flags_raw="0x00" area_flags="" area_offset="0x00f21000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags="" area_offset="0x00f7f000" area_size="0x00080000" area_name="DEVICE_EXTENSION" area_flags_raw="0x00" area_flags="" area_offset="0x00fff000" area_size="0x00001000" area_name="UNUSED_HOLE" area_flags_raw="0x00" area_flags=""
Again, interpreting the comment in the chromeos.fmd file, everything between 0x00001000 and 0x00f7f000 does, in fact, have size 0x00f7e000, exactly matching the value as stated in the IFD. However, there is also an explicit "SI-BIOS" region given here, which does *not* correspond to the comment in the chromeos.fmd file, and which here has the size given as 0x00f6f000 != 0x00f7e000.
Similarly,
$ cbfstool build/coreboot.rom layout -w This image contains the following sections that can be accessed with this tool:
'SI_DESC' (size 4096, offset 0) 'SI_BIOS' (read-only, size 16183296, offset 4096) 'IFWI' (size 2093056, offset 4096) 'SMMSTORE' (size 262144, offset 10874880) 'UNIFIED_MRC_CACHE' (read-only, size 135168, offset 11137024) 'RECOVERY_MRC_CACHE' (size 65536, offset 11137024) 'RW_MRC_CACHE' (size 65536, offset 11202560) 'RW_VAR_MRC_CACHE' (size 4096, offset 11268096) 'FMAP' (read-only, size 768, offset 11272192) 'COREBOOT' (CBFS, size 4590848, offset 11272960) 'BIOS_UNUSABLE' (size 323584, offset 15863808) 'DEVICE_EXTENSION' (size 524288, offset 16248832) 'UNUSED_HOLE' (size 4096, offset 16773120)
...
The offset to the start of both the BIOS region and the SI_BIOS region are the same, given as 0x00001000. Taking the *size* of the SI_BIOS region, 0x00f6f000, and adding the offset, 0x00001000, then gives the offset to the beginning of the region immediately following the SI_BIOS region, 0x00f6f000 + 0x00001000 = 0x00f70000.
Compare this value to the offset to the beginning of the region immediately following the "BIOS_UNUSABLE" region, 0x00f21000 + 0x0004f000 = 0x00f70000. We shall note that they are exactly the same, 0x00f70000 = 0x00f70000.
There exists, then, an "undesignated" region, implied by the coreboot flashmap format, *between* the end of the "SI_BIOS" region, and the beginning of the "DEVICE_EXTENSION" region, from 0x00f70000 to 0x00f7f000, of size 0xf000.
(0x00f7f000 - 0x00f70000) = (0x00f7e000 - 0x00f6f000) = 0xf000
We may also note that there is a discrepancy between the definition of the "BIOS_UNUSABLE" region, as given in src/mainboard/google/octopus/chromeos.fmd, and this same region, as reported for the actual coreboot.rom file, as generated from the coreboot compile.
chromeos.fmd BIOS_UNUSABLE@0xf30000 0x4f000
fmap_decode build/coreboot.rom area_offset="0x00f21000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags=""
We may note that the region sizes given are the same, but that the entry offsets are different.
Comparing these offsets, we see this same discrepancy, 0xf000, here a result of a discrepancy in the offset location of this "BIOS_UNUSABLE" region, 0xf30000, as given in the chromeos.fmd file, when compared to the location of this region in the actually created coreboot.rom file, 0x00f21000.
0xf30000 - 0x00f21000 = 0xf000
Incidentally, we may note that there exists a similar flashmap file, src/mainboard/google/octopus/default.fmd, in which the definition of the "BIOS_UNUSABLE" regiion is not so precise, with no specific entry point offset defined:
src/mainboard/google/octopus/default.fmd
BIOS_UNUSABLE 0x4f000We may also note that the given size of the "SI_BIOS" region, 0x00f6f000, violates the rule described in these chromeos.fmd and default.fmd files:
# Currently, it is required that the BIOS region be a multiple of 8KiB.0x00f6f000 / 0x2000 -> 16183296 / 8192 = 1975.5
We then note that the difference in *size* between the "BIOS" and "SI_BIOS" regions, 0x00f7e000 - 0x00f6f000 = 0xf000, does not seem to have any clear relationship to the difference in the *end points* of these regions, 0x00f7f000 and 0xf70000, respectively. The *size* provided for the actual "BIOS" region does conform to the rule.
And finally, we may note additionally in the comment:
# ... Since the # descriptor at the beginning uses 4K and BIOS starts at an offset of # 4K, a hole of 4K is created towards the end of the flash to compensate # for the size requirement of BIOS region.and UNUSED_HOLE@0xfff000 0x1000
but, while the "undesignated" region of size of 0xf000 bytes is not an even multiple of 0x2000, being instead 7.5 multiples, it also encompasses a region with 6 multiples of 0x2000, such that the rule itself does not provide any justification for having an "undesignated" region of size 0xf000. The "undesignated" region size of precisely 0xf000 bytes does not seem to have any obvious motivation or rationale.
These results, then, raise questions:
Is the location of the "BIOS_UNUSABLE" region, as created in the coreboot.rom, in error, beginning 0xf000 bytes below where it is "suppose" to have been located, according to the chromeos.fmd specification file?
Why has this "undesgnated" 0xf000 byte region not, instead, been allocated to the "COREBOOT" region?
Are mystery "undesignated" regions in the rom layout "allowed/legal", under the rules of the coreboot fmap format?
Is this "undesignated" region a mistake?
Is there some error in the chromeos.fmd file, or in the google/octopus/default.fmd file?
Is the coreboot fmap format specification too ambiguous to provide precise results?
What is the definition of "SI_BIOS" region, precisely? What is the definition of "BIOS" region, precisely?
Why is "ifdtool --validate" comparing the size of the "BIOS" region to the size of the "SI_BIOS" region? Is this comparison a mistake? Is ifdtool "broken"? Or, was illuminating this kind of discrepancy the whole point of the validate function?
What, then, is the precise meaning of the implied state "ifdtool validated"?
Is the definition of the "SI-BIOS" region suppose to include the area to the *end* of the "BIOS_UNUSABLE" region, or instead, to the *beginning* of the "DEVICE_EXTENSION" region?
Who, or what, or where, is the "official" source of these definitions?
It may be important to note that there exists no such "SI_BIOS" region in the ChromeOS recovery bios file:
$ fmap_decode images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin fmap_signature="0x5f5f464d41505f5f" fmap_ver_major="1" fmap_ver_minor="1" fmap_base="0x0000000000000000" fmap_size="0x1000000" fmap_name="FLASH" fmap_nareas="36" area_offset="0x00000000" area_size="0x00400000" area_name="WP_RO" area_flags_raw="0x00" area_flags="" area_offset="0x00000000" area_size="0x00001000" area_name="SI_DESC" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x001ff000" area_name="IFWI" area_flags_raw="0x00" area_flags="" area_offset="0x00200000" area_size="0x00004000" area_name="RO_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x001fc000" area_name="RO_SECTION" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x00000800" area_name="FMAP" area_flags_raw="0x00" area_flags="" area_offset="0x00204800" area_size="0x00000040" area_name="RO_FRID" area_flags_raw="0x00" area_flags="" area_offset="0x00204840" area_size="0x000007c0" area_name="RO_FRID_PAD" area_flags_raw="0x00" area_flags="" area_offset="0x00205000" area_size="0x001bb000" area_name="COREBOOT" area_flags_raw="0x00" area_flags="" area_offset="0x003c0000" area_size="0x00040000" area_name="GBB" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00030000" area_name="MISC_RW" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00021000" area_name="RW_PRESERVE" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00021000" area_name="UNIFIED_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00010000" area_name="RECOVERY_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00410000" area_size="0x00010000" area_name="RW_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00420000" area_size="0x00001000" area_name="RW_VAR_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00421000" area_size="0x00003000" area_name="RW_ELOG" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00004000" area_name="RW_SHARED" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00002000" area_name="SHARED_DATA" area_flags_raw="0x00" area_flags="" area_offset="0x00426000" area_size="0x00002000" area_name="VBLOCK_DEV" area_flags_raw="0x00" area_flags="" area_offset="0x00428000" area_size="0x00002000" area_name="RW_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x0042a000" area_size="0x00005000" area_name="RW_NVRAM" area_flags_raw="0x00" area_flags="" area_offset="0x0042f000" area_size="0x00001000" area_name="FPF_STATUS" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00480000" area_name="RW_SECTION_A" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00010000" area_name="VBLOCK_A" area_flags_raw="0x00" area_flags="" area_offset="0x00440000" area_size="0x0046ffc0" area_name="FW_MAIN_A" area_flags_raw="0x00" area_flags="" area_offset="0x008affc0" area_size="0x00000040" area_name="RW_FWID_A" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00480000" area_name="RW_SECTION_B" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00010000" area_name="VBLOCK_B" area_flags_raw="0x00" area_flags="" area_offset="0x008c0000" area_size="0x0046ffc0" area_name="FW_MAIN_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d2ffc0" area_size="0x00000040" area_name="RW_FWID_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d30000" area_size="0x00040000" area_name="SMMSTORE" area_flags_raw="0x00" area_flags="" area_offset="0x00d70000" area_size="0x001c0000" area_name="RW_LEGACY" area_flags_raw="0x00" area_flags="" area_offset="0x00f30000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags="" area_offset="0x00f7f000" area_size="0x00080000" area_name="DEVICE_EXTENSION" area_flags_raw="0x00" area_flags="" area_offset="0x00fff000" area_size="0x00001000" area_name="UNUSED_HOLE" area_flags_raw="0x00" area_flags=""
Thanks James
By the way, do I need to be concerned with the final note at the end of the compile, "Written area will abut bottom of target region: any unused space will keep its current contents"? A 16MiB file written onto a 16MiB rom doesn't leave any "unused" space. Or, is this "unused space" referring to "unused" and "unusable" regions described in the FMAP layout?
I should be able to write this coreboot.rom file directly to the boot rom now?
I would resolve the IFD/FMAP discrepancy first. The IFD from the firmware images for all the octopus based boards I'm seeing here use the same BIOS region size as the SI_BIOS region in the FMAP.
Thanks James
On Tue, Jun 22, 2021 at 4:10 PM James Feeney james@nurealm.net wrote: > > defconfig below, but: > > $ grep -i fsp_car defconfig > CONFIG_USE_APOLLOLAKE_FSP_CAR=y > > $ grep -i fsp_car .config > CONFIG_USE_APOLLOLAKE_FSP_CAR=y > CONFIG_FSP_CAR=y > > > Hmm - I must have done that because it sounded "safe". Which of these choices is "correct"? > > src/soc/intel/apollolake/Kconfig > > > choice > prompt "Cache-as-ram implementation" > default CAR_CQOS if !SOC_INTEL_GEMINILAKE > default CAR_NEM > help > This option allows you to select how cache-as-ram (CAR) is set up. > > config CAR_NEM > bool "Non-evict mode" > select SOC_INTEL_COMMON_BLOCK_CAR > select INTEL_CAR_NEM > help > Traditionally, CAR is set up by using Non-Evict mode. This method > does not allow CAR and cache to co-exist, because cache fills are > block in NEM mode. > > config CAR_CQOS > bool "Cache Quality of Service" > select SOC_INTEL_COMMON_BLOCK_CAR > select INTEL_CAR_CQOS > help > Cache Quality of Service allows more fine-grained control of cache > usage. As result, it is possible to set up portion of L2 cache for > CAR and use remainder for actual caching. > > config USE_APOLLOLAKE_FSP_CAR > bool "Use FSP CAR" > select FSP_CAR > help > Use FSP APIs to initialize & tear down the Cache-As-Ram. > > endchoice > > > > "Cache Quality of Service" seems more functional than "Non-Evict mode", but is it "better"? > > Selecting *either* CONFIG_CAR_CQOS=y or the default CONFIG_CAR_NEM=y, the compile seems mostly successful, but then ends the same, with: > > ... > Platform is: glk > File build/coreboot.pre is 16777216 bytes > Region mismatch between bios and SI_BIOS > Descriptor region bios: > offset: 0x00001000 > length: 0x00f7e000 > FMAP area SI_BIOS: > offset: 0x00001000 > length: 0x00f6f000 > make: *** [src/southbridge/intel/common/firmware/Makefile.inc:39: add_intel_firmware] Error 1 > > > I need help with that. > > > Also, though I'm not sure what this does, coreboot does not like my enabling CONFIG_EC_GOOGLE_CHROMEEC_RTC, which then gives: > > /var/src/coreboot/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/bootblock/ec/google/chromeec/ec.o: in function `rtc_get': > /var/src/coreboot/coreboot/src/ec/google/chromeec/ec.c:776: multiple definition of `rtc_get'; build/bootblock/drivers/pc80/rtc/mc146818rtc.o:/var/src/coreboot/coreboot/src/drivers/pc80/rtc/mc146818rtc.c:225: first defined here > make: *** [src/arch/x86/Makefile.inc:92: build/cbfs/fallback/bootblock.debug] Error 1 > > > > By the way, this chromebook recovery file includes a distinct SAR file that can be extracted from the COREBOOT section, but the SAR file-path option is not present in the config menu, using the current Kconfig: > > src/drivers/wifi/generic/Kconfig > > config USE_SAR > bool > default n > help > Enable it when wifi driver uses SAR configuration feature. > ... > > config WIFI_SAR_CBFS_FILEPATH > string "The cbfs file which has WIFI SAR defaults" > depends on USE_SAR > default "" > > Adding any kind of "prompt text" after "bool" causes the option to appear, and then the SAR file-path can be added. > > Is this a mistake in the Kconfig? Or, what should be done with this SAR file? > > Coreboot does seem to properly include my SAR file, since the coreboot.pre wifi_sar_defaults.hex file exactly matches the SAR file I specified in the WIFI_SAR_CBFS_FILEPATH. > > > Thanks > James > > $ cat defconfig > CONFIG_ANY_TOOLCHAIN=y > CONFIG_VENDOR_GOOGLE=y > CONFIG_MAINBOARD_VENDOR="Octopus" > CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Coreboot" > # CONFIG_POST_IO is not set > CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" > # CONFIG_POST_DEVICE is not set > CONFIG_BOARD_GOOGLE_CASTA=y > CONFIG_INCLUDE_NHLT_BLOBS=y > CONFIG_USE_LEGACY_8254_TIMER=y > CONFIG_NEED_IFWI=y > CONFIG_HAVE_IFD_BIN=y > CONFIG_ADD_FSP_BINARIES=y > CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" > CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" > CONFIG_CAR_CQOS=y > # CONFIG_PAVP is not set > CONFIG_X2APIC_RUNTIME=y > CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y > CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" > CONFIG_VALIDATE_INTEL_DESCRIPTOR=y > CONFIG_ME_REGION_ALLOW_CPU_READ_ACCESS=y > CONFIG_RUN_FSP_GOP=y > CONFIG_TPM_PPI=y > CONFIG_USE_SAR=y > CONFIG_WIFI_SAR_CBFS_FILEPATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/wifi_sar-bluebird.hex" > CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6=y > CONFIG_PAYLOAD_UBOOT=y > CONFIG_UBOOT_MASTER=y > CONFIG_COREINFO_SECONDARY_PAYLOAD=y > CONFIG_MEMTEST_SECONDARY_PAYLOAD=y > > $ util/cbfstool/cbfstool build/coreboot.pre print > FMAP REGION: COREBOOT > Name Offset Type Size Comp > cbfs master header 0x0 cbfs header 32 none > fallback/romstage 0x80 stage 59136 none > cpu_microcode_blob.bin 0xe800 microcode 148480 none > intel_fit 0x32c40 raw 80 none > fallback/ramstage 0x32cc0 stage 110054 LZMA (257508 decompressed) > config 0x4db00 raw 1184 none > revision 0x4dfc0 raw 722 none > build_info 0x4e2c0 raw 100 none > fallback/dsdt.aml 0x4e380 raw 13347 none > pt 0x51800 raw 20480 none > pdpt 0x56840 raw 32 none > dmic-2ch-48khz-16b.bin 0x56880 raw 3048 none > dmic-4ch-48khz-16b.bin 0x574c0 raw 3048 none > max98357-render-2ch-48khz-24b.bin 0x58100 raw 116 none > dialog-2ch-48khz-24b.bin 0x581c0 raw 100 none > fspm.bin 0x58280 fsp 417792 none > vbt.bin 0xbe2c0 raw 1334 LZMA (5632 decompressed) > wifi_sar_defaults.hex 0xbe840 raw 119 none > (empty) 0xbe900 null 932 none > fsps.bin 0xbecc0 fsp 192512 none > fallback/postcar 0xedd00 stage 20388 none > img/coreinfo 0xf2d00 simple elf 54609 none > fallback/payload 0x100280 simple elf 249347 none > img/memtest 0x13d0c0 simple elf 47497 none > (empty) 0x148a80 null 3234276 none > bootblock 0x45e480 bootblock 10288 none > > > On 6/22/21 8:17 AM, Matt DeVillier wrote: >> FSP-T isn't used for APL/GLK Chromebooks. Sounds like your .config is >> selecting something it shouldn't. run `make savedefconfig` then post >> the contents of the defconfig. Possible CONFIG_USE_APOLLOLAKE_FSP_CAR >> is selected when it shouldn't be. >> >> On Mon, Jun 21, 2021 at 9:17 PM James Feeney james@nurealm.net wrote: >>> >>> $ cat defconfig >>> ... >>> CONFIG_ADD_FSP_BINARIES=y >>> ... >>> >>> There is *no* "fspt.bin" file in this chromebook recovery bios file used as source. >>> >>> >>> $ make >>> ... >>> src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file or directory >>> #include <FsptUpd.h> >>> ^~~~~~~~~~~ >>> compilation terminated. >>> make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 1 >>> >>> >>> What Makefile is that? There is no such line 379. >>> >>> >>> $ find -name FsptUpd.h >>> ... >>> ./3rdparty/fsp/ApolloLakeFspBinPkg/Include/FsptUpd.h >>> ... >>> >>> >>> >>> $ less src/soc/intel/alderlake/Kconfig >>> ... >>> config FSP_HEADER_PATH >>> string "Location of FSP headers" >>> default "src/vendorcode/intel/fsp/fsp2_0/alderlake/" >>> >>> >>> $ less src/drivers/intel/fsp2_0/Kconfig >>> ... >>> >>> config FSP_T_FILE >>> string "Intel FSP-T (temp RAM init) binary path and filename" if !FSP_FULL_FD >>> depends on ADD_FSP_BINARIES >>> depends on FSP_CAR >>> default "$(obj)/Fsp_T.fd" if FSP_FULL_FD >>> help >>> The path and filename of the Intel FSP-T binary for this platform. >>> >>> >>> >>> >>> $ make nconfig >>> ... >>> > Generic Drivers >>> ... >>> (src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers >>> >>> How did that get there? Not me... >>> >>> $ ll src/vendorcode/intel/fsp/fsp2_0/glk >>> total 116 >>> drwxr-x--- 2 james james 4096 Oct 29 2020 . >>> drwxr-x--- 9 james james 4096 Jun 14 19:04 .. >>> -rw-r----- 1 james james 45977 Oct 29 2020 FspmUpd.h >>> -rw-r----- 1 james james 57332 Oct 29 2020 FspsUpd.h >>> -rw-r----- 1 james james 1967 Oct 29 2020 FspUpd.h >>> >>> >>> Why is src/soc/intel/apollolake/fspcar.c being built here? It seems that no fspt.bin file is needed. >>> >>> >>> James >>> _______________________________________________ >>> coreboot mailing list -- coreboot@coreboot.org >>> To unsubscribe send an email to coreboot-leave@coreboot.org >> _______________________________________________ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-leave@coreboot.org >>
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 6/23/21 6:51 PM, Matt DeVillier wrote:
On Wed, Jun 23, 2021 at 4:36 PM James Feeney james@nurealm.net wrote:
On 6/23/21 1:40 PM, Matt DeVillier wrote:
I'm an idiot and made a stupid math error when I calculated the size of the SI_BIOS region. 0xF7F000 - 0x1000 is 0xF7E000, not 0xF6F000.
Ha! I was a little suspicious of the suggestive pattern, 0xF7F000 - 0x10000 = 0xF6F000 vs 0xF7F000 - 0x1000 = 0xF7E000. But, I missed the hard-coded "SI_BIOS@0x1000 0xf6f000".
So, I see src/mainboard/google/octopus/default.fmd, specifically, is determining here.
Still, many questions from those of us less familiar. What is the meaning of "SI"? Does "SI_BIOS" have the same usage as "BIOS"? Coreboot "BIOS" is not the same thing as original "BIOS". <rant>...</rant>
coreboot's FMAP is a more finely grained map of the firmware image than the IFD's, which is necessary for coreboot (and vboot, and other utils) to locate things in the different regions.
I'm not sure where the SI_BIOS nomenclature comes from, it's a Google thing I think so one of those folks from the old days would have to chime in. On older boards it did/does encapsulate all of the coreboot FMAP regions which reside inside the IFD's BIOS region.
Are there any "official" specifications for coreboot fmap format?
https://doc.coreboot.org/lib/flashmap.html
Wish me luck. I should have a functional bootrom image now!
well, it would have been functional before, as I've apparently been using improperly sized images for quite some time :)
https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+...
"... gaps are allowed ..."
So then, your images are actually, technically, "proper", even though some rom space was wasted.
But, this element of the specification strikes me as a waking big security problem waiting to happen.
I don't see any substantive reason for the Flashmap Descriptor specification to allow gaps, and, as we have seen, allowing gaps can also lead to inadvertant errors being introduced into the resulting flashmap descriptor files.
I believe, instead, that gaps should specifically be *prohibited* in the Flashmap Descriptor specification.
I suggest that the question of allowing gaps in the flashmap descriptor should receive wider discussion, particularly as having - I would think obvious - security implications, if not simply to avoid inadvertant errors.
James
Thanks James
On Wed, Jun 23, 2021 at 1:48 PM James Feeney james@nurealm.net wrote:
On 6/22/21 11:13 PM, Matt DeVillier wrote:
On Tue, Jun 22, 2021 at 10:59 PM James Feeney james@nurealm.net wrote:
On 6/22/21 4:32 PM, Matt DeVillier wrote: > I'm not sure why you enabled so many things not selected in my > defconfig -- that's your issue.
Ha! Quite! Bit of a learning curve, though...
Ok, thanks for the clarifications - lots of things I do not need.
> Use: > > CONFIG_VENDOR_GOOGLE=y > CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" > # CONFIG_POST_DEVICE is not set > CONFIG_BOARD_GOOGLE_CASTA=y > CONFIG_INCLUDE_NHLT_BLOBS=y > CONFIG_NEED_IFWI=y > CONFIG_HAVE_IFD_BIN=y > CONFIG_ADD_FSP_BINARIES=y > CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" > CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" > CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y > CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" > CONFIG_RUN_FSP_GOP=y > CONFIG_PAYLOAD_UBOOT=y > CONFIG_UBOOT_MASTER=y > > save as .config, then make olddefconfig. > > CAR NEM (non-evict mode) is default, leave that. > > No reason to select ChromeEC RTC, it's not supported. > > WiFi SAR is only used by ChromeOS, only selectable when CONFIG_CHROMEOS=y > > secondary payloads are almost certainly not useful with u-boot as > primary payload. > > I don't get any size mismatch errors when building for CASTA using the > default FMAP. Have you modified your IFD at all?
I have not touched it.
Did you *actually* run ifdtool validate? Is your build, with no size mismatch, recent?
Using your config, and following your instructions, I get still the same result:
$ util/ifdtool/ifdtool -t build/coreboot.rom File build/coreboot.rom is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. Region mismatch between bios and SI_BIOS Descriptor region bios: offset: 0x00001000 length: 0x00f7e000 FMAP area SI_BIOS: offset: 0x00001000 length: 0x00f6f000
I see now that I need *not* enable "Validate Intel firmware descriptor", and the compile will complete without error.
But - I still have to wonder about that: "This config enables validating the Intel firmware descriptor against the fmap layout."
Does that not matter? Is that another "ChromeOS only" thing?
This issue has nothing to do with ChromeOS.
They differ in size by 60kiB. Hmm - "SI-BIOS" is one of the read-only sections given by "cbfstool /build/coreboot.rom layout -w", as is "FMAP". "BIOS" is one of the sections given by "ifdtool -d build/coreboot.rom". They just happen to have different sizes. It looks like "FMAP" is specifically a coreboot thing? The "SI" is an abbreviation for what?
As I understand, the IFD section was simply copied from the recovery file, and the FMAP section was generated from scratch, in the coreboot compile. Did coreboot make an error in not matching the given IFD?
the FMAP isn't generated from scratch, it's the default.fmd file in the google/octopus directory. If you look at that file (and at chromeos.fms), you can see why the layout and sizes are the way they are.
Aha! Ok, thanks for that.
src/mainboard/google/octopus/chromeos.fmd
# BIOS --> 4K to 0xf7f000Since the IFD BIOS region is larger in size than the FMAP SI-BIOS region, does it matter that the sizes are different? The IFD Intel ME, GbE, and Platform Data regions are all unused. There is nothing there to "mis-read", because of any potential location mistake - unless something tries to calculate a location "backward", from the end of the IFD BIOS region. Could the 60kiB size difference represent some kind of "padding"?
I'm curious about the IFD you're using. Dumping the IFD from bios-casta.ro-11297-83-3.rw-11297-83-3.bin (extracted from the octopus recovery image), the IFD layout matches that of the default.fmd used by coreboot.
Uhm - I'm confused. Using the value given in src/mainboard/google/octopus/chromeos.fmd, and reading the *comment*, which describes the BIOS region as from 0x1000 to 0xf7f000, then subtracting, gives the *size* of the - presumably - fmap "SI-BIOS" region as 0xf7e000, which exactly matches the value reported by ifdtool from the ChromeOS recovery bios file provided IFD BIOS region.
There is no discrepancy there - though, of course, this conclusion is presuming that the comment correctly interprets the meaning of the "BIOS" region, as everything between the "SI-DESC" region and the "DEVICE_EXTENSION" region, and that the chromeos.fmd file use of the term "BIOS" means exactly "SI-BIOS", as the term is expressed by cbfstool.
Incidentally, when I apply the ifdtool "validate" function to the ChromeOS recovery bios file, there is no output returned.
Is that the "correct" output when the validation is successful? If so, that's a really bad user interface design for ifdtool, since it is impossible to distinguish "no output" from "fails silently", as in "broken", especially given the otherwise "chatty" output, and the cryptic comment "Peculiar firmware descriptor", which casts doubt upon the result given. Is "Peculiar firmware descriptor" a kind of "error"?
Using the oldest recovery bios file that I have gives:
$ ifdtool -t images/bios-casta.ro-11297-193-0.rw-11297-217-0.bin File images/bios-casta.ro-11297-193-0.rw-11297-217-0.bin is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. [ That's the complete output. ]
Using the current recovery bios file gives the same truncated output:
$ ifdtool -t images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin File images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility.
To introspect further, there is the "fmap_decode" tool from the "flashmap" package, at https://chromium.googlesource.com/chromiumos/third_party/flashmap.
$ fmap_decode build/coreboot.rom fmap_signature="0x5f5f464d41505f5f" fmap_ver_major="1" fmap_ver_minor="1" fmap_base="0x0000000000000000" fmap_size="0x1000000" fmap_name="FLASH" fmap_nareas="13" area_offset="0x00000000" area_size="0x00001000" area_name="SI_DESC" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x00f6f000" area_name="SI_BIOS" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x001ff000" area_name="IFWI" area_flags_raw="0x00" area_flags="" area_offset="0x00a5f000" area_size="0x00040000" area_name="SMMSTORE" area_flags_raw="0x00" area_flags="" area_offset="0x00a9f000" area_size="0x00021000" area_name="UNIFIED_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00a9f000" area_size="0x00010000" area_name="RECOVERY_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00aaf000" area_size="0x00010000" area_name="RW_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00abf000" area_size="0x00001000" area_name="RW_VAR_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00ac0000" area_size="0x00000300" area_name="FMAP" area_flags_raw="0x00" area_flags="" area_offset="0x00ac0300" area_size="0x00460d00" area_name="COREBOOT" area_flags_raw="0x00" area_flags="" area_offset="0x00f21000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags="" area_offset="0x00f7f000" area_size="0x00080000" area_name="DEVICE_EXTENSION" area_flags_raw="0x00" area_flags="" area_offset="0x00fff000" area_size="0x00001000" area_name="UNUSED_HOLE" area_flags_raw="0x00" area_flags=""
Again, interpreting the comment in the chromeos.fmd file, everything between 0x00001000 and 0x00f7f000 does, in fact, have size 0x00f7e000, exactly matching the value as stated in the IFD. However, there is also an explicit "SI-BIOS" region given here, which does *not* correspond to the comment in the chromeos.fmd file, and which here has the size given as 0x00f6f000 != 0x00f7e000.
Similarly,
$ cbfstool build/coreboot.rom layout -w This image contains the following sections that can be accessed with this tool:
'SI_DESC' (size 4096, offset 0) 'SI_BIOS' (read-only, size 16183296, offset 4096) 'IFWI' (size 2093056, offset 4096) 'SMMSTORE' (size 262144, offset 10874880) 'UNIFIED_MRC_CACHE' (read-only, size 135168, offset 11137024) 'RECOVERY_MRC_CACHE' (size 65536, offset 11137024) 'RW_MRC_CACHE' (size 65536, offset 11202560) 'RW_VAR_MRC_CACHE' (size 4096, offset 11268096) 'FMAP' (read-only, size 768, offset 11272192) 'COREBOOT' (CBFS, size 4590848, offset 11272960) 'BIOS_UNUSABLE' (size 323584, offset 15863808) 'DEVICE_EXTENSION' (size 524288, offset 16248832) 'UNUSED_HOLE' (size 4096, offset 16773120)
...
The offset to the start of both the BIOS region and the SI_BIOS region are the same, given as 0x00001000. Taking the *size* of the SI_BIOS region, 0x00f6f000, and adding the offset, 0x00001000, then gives the offset to the beginning of the region immediately following the SI_BIOS region, 0x00f6f000 + 0x00001000 = 0x00f70000.
Compare this value to the offset to the beginning of the region immediately following the "BIOS_UNUSABLE" region, 0x00f21000 + 0x0004f000 = 0x00f70000. We shall note that they are exactly the same, 0x00f70000 = 0x00f70000.
There exists, then, an "undesignated" region, implied by the coreboot flashmap format, *between* the end of the "SI_BIOS" region, and the beginning of the "DEVICE_EXTENSION" region, from 0x00f70000 to 0x00f7f000, of size 0xf000.
(0x00f7f000 - 0x00f70000) = (0x00f7e000 - 0x00f6f000) = 0xf000
We may also note that there is a discrepancy between the definition of the "BIOS_UNUSABLE" region, as given in src/mainboard/google/octopus/chromeos.fmd, and this same region, as reported for the actual coreboot.rom file, as generated from the coreboot compile.
chromeos.fmd BIOS_UNUSABLE@0xf30000 0x4f000
fmap_decode build/coreboot.rom area_offset="0x00f21000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags=""
We may note that the region sizes given are the same, but that the entry offsets are different.
Comparing these offsets, we see this same discrepancy, 0xf000, here a result of a discrepancy in the offset location of this "BIOS_UNUSABLE" region, 0xf30000, as given in the chromeos.fmd file, when compared to the location of this region in the actually created coreboot.rom file, 0x00f21000.
0xf30000 - 0x00f21000 = 0xf000
Incidentally, we may note that there exists a similar flashmap file, src/mainboard/google/octopus/default.fmd, in which the definition of the "BIOS_UNUSABLE" regiion is not so precise, with no specific entry point offset defined:
src/mainboard/google/octopus/default.fmd
BIOS_UNUSABLE 0x4f000We may also note that the given size of the "SI_BIOS" region, 0x00f6f000, violates the rule described in these chromeos.fmd and default.fmd files:
# Currently, it is required that the BIOS region be a multiple of 8KiB.0x00f6f000 / 0x2000 -> 16183296 / 8192 = 1975.5
We then note that the difference in *size* between the "BIOS" and "SI_BIOS" regions, 0x00f7e000 - 0x00f6f000 = 0xf000, does not seem to have any clear relationship to the difference in the *end points* of these regions, 0x00f7f000 and 0xf70000, respectively. The *size* provided for the actual "BIOS" region does conform to the rule.
And finally, we may note additionally in the comment:
# ... Since the # descriptor at the beginning uses 4K and BIOS starts at an offset of # 4K, a hole of 4K is created towards the end of the flash to compensate # for the size requirement of BIOS region.and UNUSED_HOLE@0xfff000 0x1000
but, while the "undesignated" region of size of 0xf000 bytes is not an even multiple of 0x2000, being instead 7.5 multiples, it also encompasses a region with 6 multiples of 0x2000, such that the rule itself does not provide any justification for having an "undesignated" region of size 0xf000. The "undesignated" region size of precisely 0xf000 bytes does not seem to have any obvious motivation or rationale.
These results, then, raise questions:
Is the location of the "BIOS_UNUSABLE" region, as created in the coreboot.rom, in error, beginning 0xf000 bytes below where it is "suppose" to have been located, according to the chromeos.fmd specification file?
Why has this "undesgnated" 0xf000 byte region not, instead, been allocated to the "COREBOOT" region?
Are mystery "undesignated" regions in the rom layout "allowed/legal", under the rules of the coreboot fmap format?
Is this "undesignated" region a mistake?
Is there some error in the chromeos.fmd file, or in the google/octopus/default.fmd file?
Is the coreboot fmap format specification too ambiguous to provide precise results?
What is the definition of "SI_BIOS" region, precisely? What is the definition of "BIOS" region, precisely?
Why is "ifdtool --validate" comparing the size of the "BIOS" region to the size of the "SI_BIOS" region? Is this comparison a mistake? Is ifdtool "broken"? Or, was illuminating this kind of discrepancy the whole point of the validate function?
What, then, is the precise meaning of the implied state "ifdtool validated"?
Is the definition of the "SI-BIOS" region suppose to include the area to the *end* of the "BIOS_UNUSABLE" region, or instead, to the *beginning* of the "DEVICE_EXTENSION" region?
Who, or what, or where, is the "official" source of these definitions?
It may be important to note that there exists no such "SI_BIOS" region in the ChromeOS recovery bios file:
$ fmap_decode images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin fmap_signature="0x5f5f464d41505f5f" fmap_ver_major="1" fmap_ver_minor="1" fmap_base="0x0000000000000000" fmap_size="0x1000000" fmap_name="FLASH" fmap_nareas="36" area_offset="0x00000000" area_size="0x00400000" area_name="WP_RO" area_flags_raw="0x00" area_flags="" area_offset="0x00000000" area_size="0x00001000" area_name="SI_DESC" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x001ff000" area_name="IFWI" area_flags_raw="0x00" area_flags="" area_offset="0x00200000" area_size="0x00004000" area_name="RO_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x001fc000" area_name="RO_SECTION" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x00000800" area_name="FMAP" area_flags_raw="0x00" area_flags="" area_offset="0x00204800" area_size="0x00000040" area_name="RO_FRID" area_flags_raw="0x00" area_flags="" area_offset="0x00204840" area_size="0x000007c0" area_name="RO_FRID_PAD" area_flags_raw="0x00" area_flags="" area_offset="0x00205000" area_size="0x001bb000" area_name="COREBOOT" area_flags_raw="0x00" area_flags="" area_offset="0x003c0000" area_size="0x00040000" area_name="GBB" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00030000" area_name="MISC_RW" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00021000" area_name="RW_PRESERVE" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00021000" area_name="UNIFIED_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00010000" area_name="RECOVERY_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00410000" area_size="0x00010000" area_name="RW_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00420000" area_size="0x00001000" area_name="RW_VAR_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00421000" area_size="0x00003000" area_name="RW_ELOG" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00004000" area_name="RW_SHARED" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00002000" area_name="SHARED_DATA" area_flags_raw="0x00" area_flags="" area_offset="0x00426000" area_size="0x00002000" area_name="VBLOCK_DEV" area_flags_raw="0x00" area_flags="" area_offset="0x00428000" area_size="0x00002000" area_name="RW_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x0042a000" area_size="0x00005000" area_name="RW_NVRAM" area_flags_raw="0x00" area_flags="" area_offset="0x0042f000" area_size="0x00001000" area_name="FPF_STATUS" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00480000" area_name="RW_SECTION_A" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00010000" area_name="VBLOCK_A" area_flags_raw="0x00" area_flags="" area_offset="0x00440000" area_size="0x0046ffc0" area_name="FW_MAIN_A" area_flags_raw="0x00" area_flags="" area_offset="0x008affc0" area_size="0x00000040" area_name="RW_FWID_A" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00480000" area_name="RW_SECTION_B" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00010000" area_name="VBLOCK_B" area_flags_raw="0x00" area_flags="" area_offset="0x008c0000" area_size="0x0046ffc0" area_name="FW_MAIN_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d2ffc0" area_size="0x00000040" area_name="RW_FWID_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d30000" area_size="0x00040000" area_name="SMMSTORE" area_flags_raw="0x00" area_flags="" area_offset="0x00d70000" area_size="0x001c0000" area_name="RW_LEGACY" area_flags_raw="0x00" area_flags="" area_offset="0x00f30000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags="" area_offset="0x00f7f000" area_size="0x00080000" area_name="DEVICE_EXTENSION" area_flags_raw="0x00" area_flags="" area_offset="0x00fff000" area_size="0x00001000" area_name="UNUSED_HOLE" area_flags_raw="0x00" area_flags=""
Thanks James
By the way, do I need to be concerned with the final note at the end of the compile, "Written area will abut bottom of target region: any unused space will keep its current contents"? A 16MiB file written onto a 16MiB rom doesn't leave any "unused" space. Or, is this "unused space" referring to "unused" and "unusable" regions described in the FMAP layout?
I should be able to write this coreboot.rom file directly to the boot rom now?
I would resolve the IFD/FMAP discrepancy first. The IFD from the firmware images for all the octopus based boards I'm seeing here use the same BIOS region size as the SI_BIOS region in the FMAP.
Thanks James
> > On Tue, Jun 22, 2021 at 4:10 PM James Feeney james@nurealm.net wrote: >> >> defconfig below, but: >> >> $ grep -i fsp_car defconfig >> CONFIG_USE_APOLLOLAKE_FSP_CAR=y >> >> $ grep -i fsp_car .config >> CONFIG_USE_APOLLOLAKE_FSP_CAR=y >> CONFIG_FSP_CAR=y >> >> >> Hmm - I must have done that because it sounded "safe". Which of these choices is "correct"? >> >> src/soc/intel/apollolake/Kconfig >> >> >> choice >> prompt "Cache-as-ram implementation" >> default CAR_CQOS if !SOC_INTEL_GEMINILAKE >> default CAR_NEM >> help >> This option allows you to select how cache-as-ram (CAR) is set up. >> >> config CAR_NEM >> bool "Non-evict mode" >> select SOC_INTEL_COMMON_BLOCK_CAR >> select INTEL_CAR_NEM >> help >> Traditionally, CAR is set up by using Non-Evict mode. This method >> does not allow CAR and cache to co-exist, because cache fills are >> block in NEM mode. >> >> config CAR_CQOS >> bool "Cache Quality of Service" >> select SOC_INTEL_COMMON_BLOCK_CAR >> select INTEL_CAR_CQOS >> help >> Cache Quality of Service allows more fine-grained control of cache >> usage. As result, it is possible to set up portion of L2 cache for >> CAR and use remainder for actual caching. >> >> config USE_APOLLOLAKE_FSP_CAR >> bool "Use FSP CAR" >> select FSP_CAR >> help >> Use FSP APIs to initialize & tear down the Cache-As-Ram. >> >> endchoice >> >> >> >> "Cache Quality of Service" seems more functional than "Non-Evict mode", but is it "better"? >> >> Selecting *either* CONFIG_CAR_CQOS=y or the default CONFIG_CAR_NEM=y, the compile seems mostly successful, but then ends the same, with: >> >> ... >> Platform is: glk >> File build/coreboot.pre is 16777216 bytes >> Region mismatch between bios and SI_BIOS >> Descriptor region bios: >> offset: 0x00001000 >> length: 0x00f7e000 >> FMAP area SI_BIOS: >> offset: 0x00001000 >> length: 0x00f6f000 >> make: *** [src/southbridge/intel/common/firmware/Makefile.inc:39: add_intel_firmware] Error 1 >> >> >> I need help with that. >> >> >> Also, though I'm not sure what this does, coreboot does not like my enabling CONFIG_EC_GOOGLE_CHROMEEC_RTC, which then gives: >> >> /var/src/coreboot/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/bootblock/ec/google/chromeec/ec.o: in function `rtc_get': >> /var/src/coreboot/coreboot/src/ec/google/chromeec/ec.c:776: multiple definition of `rtc_get'; build/bootblock/drivers/pc80/rtc/mc146818rtc.o:/var/src/coreboot/coreboot/src/drivers/pc80/rtc/mc146818rtc.c:225: first defined here >> make: *** [src/arch/x86/Makefile.inc:92: build/cbfs/fallback/bootblock.debug] Error 1 >> >> >> >> By the way, this chromebook recovery file includes a distinct SAR file that can be extracted from the COREBOOT section, but the SAR file-path option is not present in the config menu, using the current Kconfig: >> >> src/drivers/wifi/generic/Kconfig >> >> config USE_SAR >> bool >> default n >> help >> Enable it when wifi driver uses SAR configuration feature. >> ... >> >> config WIFI_SAR_CBFS_FILEPATH >> string "The cbfs file which has WIFI SAR defaults" >> depends on USE_SAR >> default "" >> >> Adding any kind of "prompt text" after "bool" causes the option to appear, and then the SAR file-path can be added. >> >> Is this a mistake in the Kconfig? Or, what should be done with this SAR file? >> >> Coreboot does seem to properly include my SAR file, since the coreboot.pre wifi_sar_defaults.hex file exactly matches the SAR file I specified in the WIFI_SAR_CBFS_FILEPATH. >> >> >> Thanks >> James >> >> $ cat defconfig >> CONFIG_ANY_TOOLCHAIN=y >> CONFIG_VENDOR_GOOGLE=y >> CONFIG_MAINBOARD_VENDOR="Octopus" >> CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Coreboot" >> # CONFIG_POST_IO is not set >> CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" >> # CONFIG_POST_DEVICE is not set >> CONFIG_BOARD_GOOGLE_CASTA=y >> CONFIG_INCLUDE_NHLT_BLOBS=y >> CONFIG_USE_LEGACY_8254_TIMER=y >> CONFIG_NEED_IFWI=y >> CONFIG_HAVE_IFD_BIN=y >> CONFIG_ADD_FSP_BINARIES=y >> CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" >> CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" >> CONFIG_CAR_CQOS=y >> # CONFIG_PAVP is not set >> CONFIG_X2APIC_RUNTIME=y >> CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y >> CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" >> CONFIG_VALIDATE_INTEL_DESCRIPTOR=y >> CONFIG_ME_REGION_ALLOW_CPU_READ_ACCESS=y >> CONFIG_RUN_FSP_GOP=y >> CONFIG_TPM_PPI=y >> CONFIG_USE_SAR=y >> CONFIG_WIFI_SAR_CBFS_FILEPATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/wifi_sar-bluebird.hex" >> CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6=y >> CONFIG_PAYLOAD_UBOOT=y >> CONFIG_UBOOT_MASTER=y >> CONFIG_COREINFO_SECONDARY_PAYLOAD=y >> CONFIG_MEMTEST_SECONDARY_PAYLOAD=y >> >> $ util/cbfstool/cbfstool build/coreboot.pre print >> FMAP REGION: COREBOOT >> Name Offset Type Size Comp >> cbfs master header 0x0 cbfs header 32 none >> fallback/romstage 0x80 stage 59136 none >> cpu_microcode_blob.bin 0xe800 microcode 148480 none >> intel_fit 0x32c40 raw 80 none >> fallback/ramstage 0x32cc0 stage 110054 LZMA (257508 decompressed) >> config 0x4db00 raw 1184 none >> revision 0x4dfc0 raw 722 none >> build_info 0x4e2c0 raw 100 none >> fallback/dsdt.aml 0x4e380 raw 13347 none >> pt 0x51800 raw 20480 none >> pdpt 0x56840 raw 32 none >> dmic-2ch-48khz-16b.bin 0x56880 raw 3048 none >> dmic-4ch-48khz-16b.bin 0x574c0 raw 3048 none >> max98357-render-2ch-48khz-24b.bin 0x58100 raw 116 none >> dialog-2ch-48khz-24b.bin 0x581c0 raw 100 none >> fspm.bin 0x58280 fsp 417792 none >> vbt.bin 0xbe2c0 raw 1334 LZMA (5632 decompressed) >> wifi_sar_defaults.hex 0xbe840 raw 119 none >> (empty) 0xbe900 null 932 none >> fsps.bin 0xbecc0 fsp 192512 none >> fallback/postcar 0xedd00 stage 20388 none >> img/coreinfo 0xf2d00 simple elf 54609 none >> fallback/payload 0x100280 simple elf 249347 none >> img/memtest 0x13d0c0 simple elf 47497 none >> (empty) 0x148a80 null 3234276 none >> bootblock 0x45e480 bootblock 10288 none >> >> >> On 6/22/21 8:17 AM, Matt DeVillier wrote: >>> FSP-T isn't used for APL/GLK Chromebooks. Sounds like your .config is >>> selecting something it shouldn't. run `make savedefconfig` then post >>> the contents of the defconfig. Possible CONFIG_USE_APOLLOLAKE_FSP_CAR >>> is selected when it shouldn't be. >>> >>> On Mon, Jun 21, 2021 at 9:17 PM James Feeney james@nurealm.net wrote: >>>> >>>> $ cat defconfig >>>> ... >>>> CONFIG_ADD_FSP_BINARIES=y >>>> ... >>>> >>>> There is *no* "fspt.bin" file in this chromebook recovery bios file used as source. >>>> >>>> >>>> $ make >>>> ... >>>> src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file or directory >>>> #include <FsptUpd.h> >>>> ^~~~~~~~~~~ >>>> compilation terminated. >>>> make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 1 >>>> >>>> >>>> What Makefile is that? There is no such line 379. >>>> >>>> >>>> $ find -name FsptUpd.h >>>> ... >>>> ./3rdparty/fsp/ApolloLakeFspBinPkg/Include/FsptUpd.h >>>> ... >>>> >>>> >>>> >>>> $ less src/soc/intel/alderlake/Kconfig >>>> ... >>>> config FSP_HEADER_PATH >>>> string "Location of FSP headers" >>>> default "src/vendorcode/intel/fsp/fsp2_0/alderlake/" >>>> >>>> >>>> $ less src/drivers/intel/fsp2_0/Kconfig >>>> ... >>>> >>>> config FSP_T_FILE >>>> string "Intel FSP-T (temp RAM init) binary path and filename" if !FSP_FULL_FD >>>> depends on ADD_FSP_BINARIES >>>> depends on FSP_CAR >>>> default "$(obj)/Fsp_T.fd" if FSP_FULL_FD >>>> help >>>> The path and filename of the Intel FSP-T binary for this platform. >>>> >>>> >>>> >>>> >>>> $ make nconfig >>>> ... >>>> > Generic Drivers >>>> ... >>>> (src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers >>>> >>>> How did that get there? Not me... >>>> >>>> $ ll src/vendorcode/intel/fsp/fsp2_0/glk >>>> total 116 >>>> drwxr-x--- 2 james james 4096 Oct 29 2020 . >>>> drwxr-x--- 9 james james 4096 Jun 14 19:04 .. >>>> -rw-r----- 1 james james 45977 Oct 29 2020 FspmUpd.h >>>> -rw-r----- 1 james james 57332 Oct 29 2020 FspsUpd.h >>>> -rw-r----- 1 james james 1967 Oct 29 2020 FspUpd.h >>>> >>>> >>>> Why is src/soc/intel/apollolake/fspcar.c being built here? It seems that no fspt.bin file is needed. >>>> >>>> >>>> James >>>> _______________________________________________ >>>> coreboot mailing list -- coreboot@coreboot.org >>>> To unsubscribe send an email to coreboot-leave@coreboot.org >>> _______________________________________________ >>> coreboot mailing list -- coreboot@coreboot.org >>> To unsubscribe send an email to coreboot-leave@coreboot.org >>>
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 6/23/21 8:59 PM, James Feeney wrote:
On 6/23/21 6:51 PM, Matt DeVillier wrote:
On Wed, Jun 23, 2021 at 4:36 PM James Feeney james@nurealm.net wrote:
On 6/23/21 1:40 PM, Matt DeVillier wrote:
I'm an idiot and made a stupid math error when I calculated the size of the SI_BIOS region. 0xF7F000 - 0x1000 is 0xF7E000, not 0xF6F000.
Ha! I was a little suspicious of the suggestive pattern, 0xF7F000 - 0x10000 = 0xF6F000 vs 0xF7F000 - 0x1000 = 0xF7E000. But, I missed the hard-coded "SI_BIOS@0x1000 0xf6f000".
So, I see src/mainboard/google/octopus/default.fmd, specifically, is determining here.
Still, many questions from those of us less familiar. What is the meaning of "SI"? Does "SI_BIOS" have the same usage as "BIOS"? Coreboot "BIOS" is not the same thing as original "BIOS". <rant>...</rant>
coreboot's FMAP is a more finely grained map of the firmware image than the IFD's, which is necessary for coreboot (and vboot, and other utils) to locate things in the different regions.
I'm not sure where the SI_BIOS nomenclature comes from, it's a Google thing I think so one of those folks from the old days would have to chime in. On older boards it did/does encapsulate all of the coreboot FMAP regions which reside inside the IFD's BIOS region.
Are there any "official" specifications for coreboot fmap format?
https://doc.coreboot.org/lib/flashmap.html
Wish me luck. I should have a functional bootrom image now!
well, it would have been functional before, as I've apparently been using improperly sized images for quite some time :)
https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+...
"... gaps are allowed ..."
So then, your images are actually, technically, "proper", even though some rom space was wasted.
But, this element of the specification strikes me as a waking big security problem waiting to happen.
I don't see any substantive reason for the Flashmap Descriptor specification to allow gaps, and, as we have seen, allowing gaps can also lead to inadvertant errors being introduced into the resulting flashmap descriptor files.
I believe, instead, that gaps should specifically be *prohibited* in the Flashmap Descriptor specification.
I suggest that the question of allowing gaps in the flashmap descriptor should receive wider discussion, particularly as having - I would think obvious - security implications, if not simply to avoid inadvertant errors.
James
Hmm - on second thought, I suppose that there are *always* going to be "gaps", since the rom is never "full", and the actual space taken by some random mix of files will not be known in advance.
Maybe the only alternative, simply for the sake of consistency and error checking, is to require and define certain "contiguous" regions of rom, within which gaps would not be allowed. That way, errors would be disclosed, while gaps might be "forced" into defined regions, which could be specifically "locked", if desired.
Other people have thought about this?
James
Thanks James
On Wed, Jun 23, 2021 at 1:48 PM James Feeney james@nurealm.net wrote:
On 6/22/21 11:13 PM, Matt DeVillier wrote:
On Tue, Jun 22, 2021 at 10:59 PM James Feeney james@nurealm.net wrote: > > On 6/22/21 4:32 PM, Matt DeVillier wrote: >> I'm not sure why you enabled so many things not selected in my >> defconfig -- that's your issue. > > Ha! Quite! Bit of a learning curve, though... > > Ok, thanks for the clarifications - lots of things I do not need. > >> Use: >> >> CONFIG_VENDOR_GOOGLE=y >> CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" >> # CONFIG_POST_DEVICE is not set >> CONFIG_BOARD_GOOGLE_CASTA=y >> CONFIG_INCLUDE_NHLT_BLOBS=y >> CONFIG_NEED_IFWI=y >> CONFIG_HAVE_IFD_BIN=y >> CONFIG_ADD_FSP_BINARIES=y >> CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" >> CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" >> CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y >> CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" >> CONFIG_RUN_FSP_GOP=y >> CONFIG_PAYLOAD_UBOOT=y >> CONFIG_UBOOT_MASTER=y >> >> save as .config, then make olddefconfig. >> >> CAR NEM (non-evict mode) is default, leave that. >> >> No reason to select ChromeEC RTC, it's not supported. >> >> WiFi SAR is only used by ChromeOS, only selectable when CONFIG_CHROMEOS=y >> >> secondary payloads are almost certainly not useful with u-boot as >> primary payload. >> >> I don't get any size mismatch errors when building for CASTA using the >> default FMAP. Have you modified your IFD at all? > > I have not touched it. > > Did you *actually* run ifdtool validate? Is your build, with no size mismatch, recent? > > Using your config, and following your instructions, I get still the same result: > > $ util/ifdtool/ifdtool -t build/coreboot.rom > File build/coreboot.rom is 16777216 bytes > Peculiar firmware descriptor, assuming Ibex Peak compatibility. > Region mismatch between bios and SI_BIOS > Descriptor region bios: > offset: 0x00001000 > length: 0x00f7e000 > FMAP area SI_BIOS: > offset: 0x00001000 > length: 0x00f6f000 > > I see now that I need *not* enable "Validate Intel firmware descriptor", and the compile will complete without error. > > But - I still have to wonder about that: "This config enables validating the Intel firmware descriptor against the fmap layout." > > Does that not matter? Is that another "ChromeOS only" thing?
This issue has nothing to do with ChromeOS.
> > They differ in size by 60kiB. Hmm - "SI-BIOS" is one of the read-only sections given by "cbfstool /build/coreboot.rom layout -w", as is "FMAP". "BIOS" is one of the sections given by "ifdtool -d build/coreboot.rom". They just happen to have different sizes. It looks like "FMAP" is specifically a coreboot thing? The "SI" is an abbreviation for what? > > As I understand, the IFD section was simply copied from the recovery file, and the FMAP section was generated from scratch, in the coreboot compile. Did coreboot make an error in not matching the given IFD?
the FMAP isn't generated from scratch, it's the default.fmd file in the google/octopus directory. If you look at that file (and at chromeos.fms), you can see why the layout and sizes are the way they are.
Aha! Ok, thanks for that.
src/mainboard/google/octopus/chromeos.fmd
# BIOS --> 4K to 0xf7f000> > Since the IFD BIOS region is larger in size than the FMAP SI-BIOS region, does it matter that the sizes are different? The IFD Intel ME, GbE, and Platform Data regions are all unused. There is nothing there to "mis-read", because of any potential location mistake - unless something tries to calculate a location "backward", from the end of the IFD BIOS region. Could the 60kiB size difference represent some kind of "padding"?
I'm curious about the IFD you're using. Dumping the IFD from bios-casta.ro-11297-83-3.rw-11297-83-3.bin (extracted from the octopus recovery image), the IFD layout matches that of the default.fmd used by coreboot.
Uhm - I'm confused. Using the value given in src/mainboard/google/octopus/chromeos.fmd, and reading the *comment*, which describes the BIOS region as from 0x1000 to 0xf7f000, then subtracting, gives the *size* of the - presumably - fmap "SI-BIOS" region as 0xf7e000, which exactly matches the value reported by ifdtool from the ChromeOS recovery bios file provided IFD BIOS region.
There is no discrepancy there - though, of course, this conclusion is presuming that the comment correctly interprets the meaning of the "BIOS" region, as everything between the "SI-DESC" region and the "DEVICE_EXTENSION" region, and that the chromeos.fmd file use of the term "BIOS" means exactly "SI-BIOS", as the term is expressed by cbfstool.
Incidentally, when I apply the ifdtool "validate" function to the ChromeOS recovery bios file, there is no output returned.
Is that the "correct" output when the validation is successful? If so, that's a really bad user interface design for ifdtool, since it is impossible to distinguish "no output" from "fails silently", as in "broken", especially given the otherwise "chatty" output, and the cryptic comment "Peculiar firmware descriptor", which casts doubt upon the result given. Is "Peculiar firmware descriptor" a kind of "error"?
Using the oldest recovery bios file that I have gives:
$ ifdtool -t images/bios-casta.ro-11297-193-0.rw-11297-217-0.bin File images/bios-casta.ro-11297-193-0.rw-11297-217-0.bin is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. [ That's the complete output. ]
Using the current recovery bios file gives the same truncated output:
$ ifdtool -t images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin File images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility.
To introspect further, there is the "fmap_decode" tool from the "flashmap" package, at https://chromium.googlesource.com/chromiumos/third_party/flashmap.
$ fmap_decode build/coreboot.rom fmap_signature="0x5f5f464d41505f5f" fmap_ver_major="1" fmap_ver_minor="1" fmap_base="0x0000000000000000" fmap_size="0x1000000" fmap_name="FLASH" fmap_nareas="13" area_offset="0x00000000" area_size="0x00001000" area_name="SI_DESC" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x00f6f000" area_name="SI_BIOS" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x001ff000" area_name="IFWI" area_flags_raw="0x00" area_flags="" area_offset="0x00a5f000" area_size="0x00040000" area_name="SMMSTORE" area_flags_raw="0x00" area_flags="" area_offset="0x00a9f000" area_size="0x00021000" area_name="UNIFIED_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00a9f000" area_size="0x00010000" area_name="RECOVERY_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00aaf000" area_size="0x00010000" area_name="RW_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00abf000" area_size="0x00001000" area_name="RW_VAR_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00ac0000" area_size="0x00000300" area_name="FMAP" area_flags_raw="0x00" area_flags="" area_offset="0x00ac0300" area_size="0x00460d00" area_name="COREBOOT" area_flags_raw="0x00" area_flags="" area_offset="0x00f21000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags="" area_offset="0x00f7f000" area_size="0x00080000" area_name="DEVICE_EXTENSION" area_flags_raw="0x00" area_flags="" area_offset="0x00fff000" area_size="0x00001000" area_name="UNUSED_HOLE" area_flags_raw="0x00" area_flags=""
Again, interpreting the comment in the chromeos.fmd file, everything between 0x00001000 and 0x00f7f000 does, in fact, have size 0x00f7e000, exactly matching the value as stated in the IFD. However, there is also an explicit "SI-BIOS" region given here, which does *not* correspond to the comment in the chromeos.fmd file, and which here has the size given as 0x00f6f000 != 0x00f7e000.
Similarly,
$ cbfstool build/coreboot.rom layout -w This image contains the following sections that can be accessed with this tool:
'SI_DESC' (size 4096, offset 0) 'SI_BIOS' (read-only, size 16183296, offset 4096) 'IFWI' (size 2093056, offset 4096) 'SMMSTORE' (size 262144, offset 10874880) 'UNIFIED_MRC_CACHE' (read-only, size 135168, offset 11137024) 'RECOVERY_MRC_CACHE' (size 65536, offset 11137024) 'RW_MRC_CACHE' (size 65536, offset 11202560) 'RW_VAR_MRC_CACHE' (size 4096, offset 11268096) 'FMAP' (read-only, size 768, offset 11272192) 'COREBOOT' (CBFS, size 4590848, offset 11272960) 'BIOS_UNUSABLE' (size 323584, offset 15863808) 'DEVICE_EXTENSION' (size 524288, offset 16248832) 'UNUSED_HOLE' (size 4096, offset 16773120)
...
The offset to the start of both the BIOS region and the SI_BIOS region are the same, given as 0x00001000. Taking the *size* of the SI_BIOS region, 0x00f6f000, and adding the offset, 0x00001000, then gives the offset to the beginning of the region immediately following the SI_BIOS region, 0x00f6f000 + 0x00001000 = 0x00f70000.
Compare this value to the offset to the beginning of the region immediately following the "BIOS_UNUSABLE" region, 0x00f21000 + 0x0004f000 = 0x00f70000. We shall note that they are exactly the same, 0x00f70000 = 0x00f70000.
There exists, then, an "undesignated" region, implied by the coreboot flashmap format, *between* the end of the "SI_BIOS" region, and the beginning of the "DEVICE_EXTENSION" region, from 0x00f70000 to 0x00f7f000, of size 0xf000.
(0x00f7f000 - 0x00f70000) = (0x00f7e000 - 0x00f6f000) = 0xf000
We may also note that there is a discrepancy between the definition of the "BIOS_UNUSABLE" region, as given in src/mainboard/google/octopus/chromeos.fmd, and this same region, as reported for the actual coreboot.rom file, as generated from the coreboot compile.
chromeos.fmd BIOS_UNUSABLE@0xf30000 0x4f000
fmap_decode build/coreboot.rom area_offset="0x00f21000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags=""
We may note that the region sizes given are the same, but that the entry offsets are different.
Comparing these offsets, we see this same discrepancy, 0xf000, here a result of a discrepancy in the offset location of this "BIOS_UNUSABLE" region, 0xf30000, as given in the chromeos.fmd file, when compared to the location of this region in the actually created coreboot.rom file, 0x00f21000.
0xf30000 - 0x00f21000 = 0xf000
Incidentally, we may note that there exists a similar flashmap file, src/mainboard/google/octopus/default.fmd, in which the definition of the "BIOS_UNUSABLE" regiion is not so precise, with no specific entry point offset defined:
src/mainboard/google/octopus/default.fmd
BIOS_UNUSABLE 0x4f000We may also note that the given size of the "SI_BIOS" region, 0x00f6f000, violates the rule described in these chromeos.fmd and default.fmd files:
# Currently, it is required that the BIOS region be a multiple of 8KiB.0x00f6f000 / 0x2000 -> 16183296 / 8192 = 1975.5
We then note that the difference in *size* between the "BIOS" and "SI_BIOS" regions, 0x00f7e000 - 0x00f6f000 = 0xf000, does not seem to have any clear relationship to the difference in the *end points* of these regions, 0x00f7f000 and 0xf70000, respectively. The *size* provided for the actual "BIOS" region does conform to the rule.
And finally, we may note additionally in the comment:
# ... Since the # descriptor at the beginning uses 4K and BIOS starts at an offset of # 4K, a hole of 4K is created towards the end of the flash to compensate # for the size requirement of BIOS region.and UNUSED_HOLE@0xfff000 0x1000
but, while the "undesignated" region of size of 0xf000 bytes is not an even multiple of 0x2000, being instead 7.5 multiples, it also encompasses a region with 6 multiples of 0x2000, such that the rule itself does not provide any justification for having an "undesignated" region of size 0xf000. The "undesignated" region size of precisely 0xf000 bytes does not seem to have any obvious motivation or rationale.
These results, then, raise questions:
Is the location of the "BIOS_UNUSABLE" region, as created in the coreboot.rom, in error, beginning 0xf000 bytes below where it is "suppose" to have been located, according to the chromeos.fmd specification file?
Why has this "undesgnated" 0xf000 byte region not, instead, been allocated to the "COREBOOT" region?
Are mystery "undesignated" regions in the rom layout "allowed/legal", under the rules of the coreboot fmap format?
Is this "undesignated" region a mistake?
Is there some error in the chromeos.fmd file, or in the google/octopus/default.fmd file?
Is the coreboot fmap format specification too ambiguous to provide precise results?
What is the definition of "SI_BIOS" region, precisely? What is the definition of "BIOS" region, precisely?
Why is "ifdtool --validate" comparing the size of the "BIOS" region to the size of the "SI_BIOS" region? Is this comparison a mistake? Is ifdtool "broken"? Or, was illuminating this kind of discrepancy the whole point of the validate function?
What, then, is the precise meaning of the implied state "ifdtool validated"?
Is the definition of the "SI-BIOS" region suppose to include the area to the *end* of the "BIOS_UNUSABLE" region, or instead, to the *beginning* of the "DEVICE_EXTENSION" region?
Who, or what, or where, is the "official" source of these definitions?
It may be important to note that there exists no such "SI_BIOS" region in the ChromeOS recovery bios file:
$ fmap_decode images/bios-casta.ro-11297-222-0.rw-11297-242-0.bin fmap_signature="0x5f5f464d41505f5f" fmap_ver_major="1" fmap_ver_minor="1" fmap_base="0x0000000000000000" fmap_size="0x1000000" fmap_name="FLASH" fmap_nareas="36" area_offset="0x00000000" area_size="0x00400000" area_name="WP_RO" area_flags_raw="0x00" area_flags="" area_offset="0x00000000" area_size="0x00001000" area_name="SI_DESC" area_flags_raw="0x00" area_flags="" area_offset="0x00001000" area_size="0x001ff000" area_name="IFWI" area_flags_raw="0x00" area_flags="" area_offset="0x00200000" area_size="0x00004000" area_name="RO_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x001fc000" area_name="RO_SECTION" area_flags_raw="0x00" area_flags="" area_offset="0x00204000" area_size="0x00000800" area_name="FMAP" area_flags_raw="0x00" area_flags="" area_offset="0x00204800" area_size="0x00000040" area_name="RO_FRID" area_flags_raw="0x00" area_flags="" area_offset="0x00204840" area_size="0x000007c0" area_name="RO_FRID_PAD" area_flags_raw="0x00" area_flags="" area_offset="0x00205000" area_size="0x001bb000" area_name="COREBOOT" area_flags_raw="0x00" area_flags="" area_offset="0x003c0000" area_size="0x00040000" area_name="GBB" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00030000" area_name="MISC_RW" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00021000" area_name="RW_PRESERVE" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00021000" area_name="UNIFIED_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00400000" area_size="0x00010000" area_name="RECOVERY_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00410000" area_size="0x00010000" area_name="RW_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00420000" area_size="0x00001000" area_name="RW_VAR_MRC_CACHE" area_flags_raw="0x00" area_flags="" area_offset="0x00421000" area_size="0x00003000" area_name="RW_ELOG" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00004000" area_name="RW_SHARED" area_flags_raw="0x00" area_flags="" area_offset="0x00424000" area_size="0x00002000" area_name="SHARED_DATA" area_flags_raw="0x00" area_flags="" area_offset="0x00426000" area_size="0x00002000" area_name="VBLOCK_DEV" area_flags_raw="0x00" area_flags="" area_offset="0x00428000" area_size="0x00002000" area_name="RW_VPD" area_flags_raw="0x00" area_flags="" area_offset="0x0042a000" area_size="0x00005000" area_name="RW_NVRAM" area_flags_raw="0x00" area_flags="" area_offset="0x0042f000" area_size="0x00001000" area_name="FPF_STATUS" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00480000" area_name="RW_SECTION_A" area_flags_raw="0x00" area_flags="" area_offset="0x00430000" area_size="0x00010000" area_name="VBLOCK_A" area_flags_raw="0x00" area_flags="" area_offset="0x00440000" area_size="0x0046ffc0" area_name="FW_MAIN_A" area_flags_raw="0x00" area_flags="" area_offset="0x008affc0" area_size="0x00000040" area_name="RW_FWID_A" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00480000" area_name="RW_SECTION_B" area_flags_raw="0x00" area_flags="" area_offset="0x008b0000" area_size="0x00010000" area_name="VBLOCK_B" area_flags_raw="0x00" area_flags="" area_offset="0x008c0000" area_size="0x0046ffc0" area_name="FW_MAIN_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d2ffc0" area_size="0x00000040" area_name="RW_FWID_B" area_flags_raw="0x00" area_flags="" area_offset="0x00d30000" area_size="0x00040000" area_name="SMMSTORE" area_flags_raw="0x00" area_flags="" area_offset="0x00d70000" area_size="0x001c0000" area_name="RW_LEGACY" area_flags_raw="0x00" area_flags="" area_offset="0x00f30000" area_size="0x0004f000" area_name="BIOS_UNUSABLE" area_flags_raw="0x00" area_flags="" area_offset="0x00f7f000" area_size="0x00080000" area_name="DEVICE_EXTENSION" area_flags_raw="0x00" area_flags="" area_offset="0x00fff000" area_size="0x00001000" area_name="UNUSED_HOLE" area_flags_raw="0x00" area_flags=""
Thanks James
> By the way, do I need to be concerned with the final note at the end of the compile, "Written area will abut bottom of target region: any unused space will keep its current contents"? A 16MiB file written onto a 16MiB rom doesn't leave any "unused" space. Or, is this "unused space" referring to "unused" and "unusable" regions described in the FMAP layout? > > I should be able to write this coreboot.rom file directly to the boot rom now?
I would resolve the IFD/FMAP discrepancy first. The IFD from the firmware images for all the octopus based boards I'm seeing here use the same BIOS region size as the SI_BIOS region in the FMAP.
> > > Thanks > James > >> >> On Tue, Jun 22, 2021 at 4:10 PM James Feeney james@nurealm.net wrote: >>> >>> defconfig below, but: >>> >>> $ grep -i fsp_car defconfig >>> CONFIG_USE_APOLLOLAKE_FSP_CAR=y >>> >>> $ grep -i fsp_car .config >>> CONFIG_USE_APOLLOLAKE_FSP_CAR=y >>> CONFIG_FSP_CAR=y >>> >>> >>> Hmm - I must have done that because it sounded "safe". Which of these choices is "correct"? >>> >>> src/soc/intel/apollolake/Kconfig >>> >>> >>> choice >>> prompt "Cache-as-ram implementation" >>> default CAR_CQOS if !SOC_INTEL_GEMINILAKE >>> default CAR_NEM >>> help >>> This option allows you to select how cache-as-ram (CAR) is set up. >>> >>> config CAR_NEM >>> bool "Non-evict mode" >>> select SOC_INTEL_COMMON_BLOCK_CAR >>> select INTEL_CAR_NEM >>> help >>> Traditionally, CAR is set up by using Non-Evict mode. This method >>> does not allow CAR and cache to co-exist, because cache fills are >>> block in NEM mode. >>> >>> config CAR_CQOS >>> bool "Cache Quality of Service" >>> select SOC_INTEL_COMMON_BLOCK_CAR >>> select INTEL_CAR_CQOS >>> help >>> Cache Quality of Service allows more fine-grained control of cache >>> usage. As result, it is possible to set up portion of L2 cache for >>> CAR and use remainder for actual caching. >>> >>> config USE_APOLLOLAKE_FSP_CAR >>> bool "Use FSP CAR" >>> select FSP_CAR >>> help >>> Use FSP APIs to initialize & tear down the Cache-As-Ram. >>> >>> endchoice >>> >>> >>> >>> "Cache Quality of Service" seems more functional than "Non-Evict mode", but is it "better"? >>> >>> Selecting *either* CONFIG_CAR_CQOS=y or the default CONFIG_CAR_NEM=y, the compile seems mostly successful, but then ends the same, with: >>> >>> ... >>> Platform is: glk >>> File build/coreboot.pre is 16777216 bytes >>> Region mismatch between bios and SI_BIOS >>> Descriptor region bios: >>> offset: 0x00001000 >>> length: 0x00f7e000 >>> FMAP area SI_BIOS: >>> offset: 0x00001000 >>> length: 0x00f6f000 >>> make: *** [src/southbridge/intel/common/firmware/Makefile.inc:39: add_intel_firmware] Error 1 >>> >>> >>> I need help with that. >>> >>> >>> Also, though I'm not sure what this does, coreboot does not like my enabling CONFIG_EC_GOOGLE_CHROMEEC_RTC, which then gives: >>> >>> /var/src/coreboot/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/bootblock/ec/google/chromeec/ec.o: in function `rtc_get': >>> /var/src/coreboot/coreboot/src/ec/google/chromeec/ec.c:776: multiple definition of `rtc_get'; build/bootblock/drivers/pc80/rtc/mc146818rtc.o:/var/src/coreboot/coreboot/src/drivers/pc80/rtc/mc146818rtc.c:225: first defined here >>> make: *** [src/arch/x86/Makefile.inc:92: build/cbfs/fallback/bootblock.debug] Error 1 >>> >>> >>> >>> By the way, this chromebook recovery file includes a distinct SAR file that can be extracted from the COREBOOT section, but the SAR file-path option is not present in the config menu, using the current Kconfig: >>> >>> src/drivers/wifi/generic/Kconfig >>> >>> config USE_SAR >>> bool >>> default n >>> help >>> Enable it when wifi driver uses SAR configuration feature. >>> ... >>> >>> config WIFI_SAR_CBFS_FILEPATH >>> string "The cbfs file which has WIFI SAR defaults" >>> depends on USE_SAR >>> default "" >>> >>> Adding any kind of "prompt text" after "bool" causes the option to appear, and then the SAR file-path can be added. >>> >>> Is this a mistake in the Kconfig? Or, what should be done with this SAR file? >>> >>> Coreboot does seem to properly include my SAR file, since the coreboot.pre wifi_sar_defaults.hex file exactly matches the SAR file I specified in the WIFI_SAR_CBFS_FILEPATH. >>> >>> >>> Thanks >>> James >>> >>> $ cat defconfig >>> CONFIG_ANY_TOOLCHAIN=y >>> CONFIG_VENDOR_GOOGLE=y >>> CONFIG_MAINBOARD_VENDOR="Octopus" >>> CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Coreboot" >>> # CONFIG_POST_IO is not set >>> CONFIG_PAYLOAD_CONFIGFILE="../configubootJun14-2" >>> # CONFIG_POST_DEVICE is not set >>> CONFIG_BOARD_GOOGLE_CASTA=y >>> CONFIG_INCLUDE_NHLT_BLOBS=y >>> CONFIG_USE_LEGACY_8254_TIMER=y >>> CONFIG_NEED_IFWI=y >>> CONFIG_HAVE_IFD_BIN=y >>> CONFIG_ADD_FSP_BINARIES=y >>> CONFIG_FSP_M_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fspm.bin" >>> CONFIG_FSP_S_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/fsps.bin" >>> CONFIG_CAR_CQOS=y >>> # CONFIG_PAVP is not set >>> CONFIG_X2APIC_RUNTIME=y >>> CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y >>> CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(CONFIG_MAINBOARD_DIR)/cpu_microcode_blob.bin" >>> CONFIG_VALIDATE_INTEL_DESCRIPTOR=y >>> CONFIG_ME_REGION_ALLOW_CPU_READ_ACCESS=y >>> CONFIG_RUN_FSP_GOP=y >>> CONFIG_TPM_PPI=y >>> CONFIG_USE_SAR=y >>> CONFIG_WIFI_SAR_CBFS_FILEPATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/wifi_sar-bluebird.hex" >>> CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6=y >>> CONFIG_PAYLOAD_UBOOT=y >>> CONFIG_UBOOT_MASTER=y >>> CONFIG_COREINFO_SECONDARY_PAYLOAD=y >>> CONFIG_MEMTEST_SECONDARY_PAYLOAD=y >>> >>> $ util/cbfstool/cbfstool build/coreboot.pre print >>> FMAP REGION: COREBOOT >>> Name Offset Type Size Comp >>> cbfs master header 0x0 cbfs header 32 none >>> fallback/romstage 0x80 stage 59136 none >>> cpu_microcode_blob.bin 0xe800 microcode 148480 none >>> intel_fit 0x32c40 raw 80 none >>> fallback/ramstage 0x32cc0 stage 110054 LZMA (257508 decompressed) >>> config 0x4db00 raw 1184 none >>> revision 0x4dfc0 raw 722 none >>> build_info 0x4e2c0 raw 100 none >>> fallback/dsdt.aml 0x4e380 raw 13347 none >>> pt 0x51800 raw 20480 none >>> pdpt 0x56840 raw 32 none >>> dmic-2ch-48khz-16b.bin 0x56880 raw 3048 none >>> dmic-4ch-48khz-16b.bin 0x574c0 raw 3048 none >>> max98357-render-2ch-48khz-24b.bin 0x58100 raw 116 none >>> dialog-2ch-48khz-24b.bin 0x581c0 raw 100 none >>> fspm.bin 0x58280 fsp 417792 none >>> vbt.bin 0xbe2c0 raw 1334 LZMA (5632 decompressed) >>> wifi_sar_defaults.hex 0xbe840 raw 119 none >>> (empty) 0xbe900 null 932 none >>> fsps.bin 0xbecc0 fsp 192512 none >>> fallback/postcar 0xedd00 stage 20388 none >>> img/coreinfo 0xf2d00 simple elf 54609 none >>> fallback/payload 0x100280 simple elf 249347 none >>> img/memtest 0x13d0c0 simple elf 47497 none >>> (empty) 0x148a80 null 3234276 none >>> bootblock 0x45e480 bootblock 10288 none >>> >>> >>> On 6/22/21 8:17 AM, Matt DeVillier wrote: >>>> FSP-T isn't used for APL/GLK Chromebooks. Sounds like your .config is >>>> selecting something it shouldn't. run `make savedefconfig` then post >>>> the contents of the defconfig. Possible CONFIG_USE_APOLLOLAKE_FSP_CAR >>>> is selected when it shouldn't be. >>>> >>>> On Mon, Jun 21, 2021 at 9:17 PM James Feeney james@nurealm.net wrote: >>>>> >>>>> $ cat defconfig >>>>> ... >>>>> CONFIG_ADD_FSP_BINARIES=y >>>>> ... >>>>> >>>>> There is *no* "fspt.bin" file in this chromebook recovery bios file used as source. >>>>> >>>>> >>>>> $ make >>>>> ... >>>>> src/soc/intel/apollolake/fspcar.c:3:10: fatal error: FsptUpd.h: No such file or directory >>>>> #include <FsptUpd.h> >>>>> ^~~~~~~~~~~ >>>>> compilation terminated. >>>>> make: *** [Makefile:379: build/bootblock/soc/intel/apollolake/fspcar.o] Error 1 >>>>> >>>>> >>>>> What Makefile is that? There is no such line 379. >>>>> >>>>> >>>>> $ find -name FsptUpd.h >>>>> ... >>>>> ./3rdparty/fsp/ApolloLakeFspBinPkg/Include/FsptUpd.h >>>>> ... >>>>> >>>>> >>>>> >>>>> $ less src/soc/intel/alderlake/Kconfig >>>>> ... >>>>> config FSP_HEADER_PATH >>>>> string "Location of FSP headers" >>>>> default "src/vendorcode/intel/fsp/fsp2_0/alderlake/" >>>>> >>>>> >>>>> $ less src/drivers/intel/fsp2_0/Kconfig >>>>> ... >>>>> >>>>> config FSP_T_FILE >>>>> string "Intel FSP-T (temp RAM init) binary path and filename" if !FSP_FULL_FD >>>>> depends on ADD_FSP_BINARIES >>>>> depends on FSP_CAR >>>>> default "$(obj)/Fsp_T.fd" if FSP_FULL_FD >>>>> help >>>>> The path and filename of the Intel FSP-T binary for this platform. >>>>> >>>>> >>>>> >>>>> >>>>> $ make nconfig >>>>> ... >>>>> > Generic Drivers >>>>> ... >>>>> (src/vendorcode/intel/fsp/fsp2_0/glk) Location of FSP headers >>>>> >>>>> How did that get there? Not me... >>>>> >>>>> $ ll src/vendorcode/intel/fsp/fsp2_0/glk >>>>> total 116 >>>>> drwxr-x--- 2 james james 4096 Oct 29 2020 . >>>>> drwxr-x--- 9 james james 4096 Jun 14 19:04 .. >>>>> -rw-r----- 1 james james 45977 Oct 29 2020 FspmUpd.h >>>>> -rw-r----- 1 james james 57332 Oct 29 2020 FspsUpd.h >>>>> -rw-r----- 1 james james 1967 Oct 29 2020 FspUpd.h >>>>> >>>>> >>>>> Why is src/soc/intel/apollolake/fspcar.c being built here? It seems that no fspt.bin file is needed. >>>>> >>>>> >>>>> James >>>>> _______________________________________________ >>>>> coreboot mailing list -- coreboot@coreboot.org >>>>> To unsubscribe send an email to coreboot-leave@coreboot.org >>>> _______________________________________________ >>>> coreboot mailing list -- coreboot@coreboot.org >>>> To unsubscribe send an email to coreboot-leave@coreboot.org >>>> _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 6/24/21 12:48 AM, James Feeney wrote:
On 6/23/21 8:59 PM, James Feeney wrote:
On 6/23/21 6:51 PM, Matt DeVillier wrote:
On Wed, Jun 23, 2021 at 4:36 PM James Feeney james@nurealm.net wrote:
On 6/23/21 1:40 PM, Matt DeVillier wrote:
I'm an idiot and made a stupid math error when I calculated the size of the SI_BIOS region. 0xF7F000 - 0x1000 is 0xF7E000, not 0xF6F000.
Ha! I was a little suspicious of the suggestive pattern, 0xF7F000 - 0x10000 = 0xF6F000 vs 0xF7F000 - 0x1000 = 0xF7E000. But, I missed the hard-coded "SI_BIOS@0x1000 0xf6f000".
So, I see src/mainboard/google/octopus/default.fmd, specifically, is determining here.
Still, many questions from those of us less familiar. What is the meaning of "SI"? Does "SI_BIOS" have the same usage as "BIOS"? Coreboot "BIOS" is not the same thing as original "BIOS". <rant>...</rant>
coreboot's FMAP is a more finely grained map of the firmware image than the IFD's, which is necessary for coreboot (and vboot, and other utils) to locate things in the different regions.
I'm not sure where the SI_BIOS nomenclature comes from, it's a Google thing I think so one of those folks from the old days would have to chime in. On older boards it did/does encapsulate all of the coreboot FMAP regions which reside inside the IFD's BIOS region.
Are there any "official" specifications for coreboot fmap format?
https://doc.coreboot.org/lib/flashmap.html
Wish me luck. I should have a functional bootrom image now!
well, it would have been functional before, as I've apparently been using improperly sized images for quite some time :)
https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+...
"... gaps are allowed ..."
So then, your images are actually, technically, "proper", even though some rom space was wasted.
But, this element of the specification strikes me as a waking big security problem waiting to happen.
I don't see any substantive reason for the Flashmap Descriptor specification to allow gaps, and, as we have seen, allowing gaps can also lead to inadvertant errors being introduced into the resulting flashmap descriptor files.
I believe, instead, that gaps should specifically be *prohibited* in the Flashmap Descriptor specification.
I suggest that the question of allowing gaps in the flashmap descriptor should receive wider discussion, particularly as having - I would think obvious - security implications, if not simply to avoid inadvertant errors.
James
Hmm - on second thought, I suppose that there are *always* going to be "gaps", since the rom is never "full", and the actual space taken by some random mix of files will not be known in advance.
Maybe the only alternative, simply for the sake of consistency and error checking, is to require and define certain "contiguous" regions of rom, within which gaps would not be allowed. That way, errors would be disclosed, while gaps might be "forced" into defined regions, which could be specifically "locked", if desired.
Other people have thought about this?
James
Or, a simpler idea that could be useful - cbfstool layout could just autogenerate "GAP" regions in the output, to make these more apparent.
James
I don't see the problem here TBH. There's no issue, security or otherwise, with coreboot having fmap regions within the IFD BIOS region that are not contiguous. Alignment requirements (eg, 64k) for some regions practically guarantee this.
ifdtool complained here because a manually generated flashmap had a BIOS region that wasn't top-aligned with the IFD one.
On Thu, Jun 24, 2021 at 7:37 AM James Feeney james@nurealm.net wrote:
On 6/24/21 12:48 AM, James Feeney wrote:
On 6/23/21 8:59 PM, James Feeney wrote:
On 6/23/21 6:51 PM, Matt DeVillier wrote:
On Wed, Jun 23, 2021 at 4:36 PM James Feeney james@nurealm.net wrote:
On 6/23/21 1:40 PM, Matt DeVillier wrote:
I'm an idiot and made a stupid math error when I calculated the size of the SI_BIOS region. 0xF7F000 - 0x1000 is 0xF7E000, not 0xF6F000.
Ha! I was a little suspicious of the suggestive pattern, 0xF7F000 - 0x10000 = 0xF6F000 vs 0xF7F000 - 0x1000 = 0xF7E000. But, I missed the hard-coded "SI_BIOS@0x1000 0xf6f000".
So, I see src/mainboard/google/octopus/default.fmd, specifically, is determining here.
Still, many questions from those of us less familiar. What is the meaning of "SI"? Does "SI_BIOS" have the same usage as "BIOS"? Coreboot "BIOS" is not the same thing as original "BIOS". <rant>...</rant>
coreboot's FMAP is a more finely grained map of the firmware image than the IFD's, which is necessary for coreboot (and vboot, and other utils) to locate things in the different regions.
I'm not sure where the SI_BIOS nomenclature comes from, it's a Google thing I think so one of those folks from the old days would have to chime in. On older boards it did/does encapsulate all of the coreboot FMAP regions which reside inside the IFD's BIOS region.
Are there any "official" specifications for coreboot fmap format?
https://doc.coreboot.org/lib/flashmap.html
Wish me luck. I should have a functional bootrom image now!
well, it would have been functional before, as I've apparently been using improperly sized images for quite some time :)
https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+...
"... gaps are allowed ..."
So then, your images are actually, technically, "proper", even though some rom space was wasted.
But, this element of the specification strikes me as a waking big security problem waiting to happen.
I don't see any substantive reason for the Flashmap Descriptor specification to allow gaps, and, as we have seen, allowing gaps can also lead to inadvertant errors being introduced into the resulting flashmap descriptor files.
I believe, instead, that gaps should specifically be *prohibited* in the Flashmap Descriptor specification.
I suggest that the question of allowing gaps in the flashmap descriptor should receive wider discussion, particularly as having - I would think obvious - security implications, if not simply to avoid inadvertant errors.
James
Hmm - on second thought, I suppose that there are *always* going to be "gaps", since the rom is never "full", and the actual space taken by some random mix of files will not be known in advance.
Maybe the only alternative, simply for the sake of consistency and error checking, is to require and define certain "contiguous" regions of rom, within which gaps would not be allowed. That way, errors would be disclosed, while gaps might be "forced" into defined regions, which could be specifically "locked", if desired.
Other people have thought about this?
James
Or, a simpler idea that could be useful - cbfstool layout could just autogenerate "GAP" regions in the output, to make these more apparent.
James
On 6/24/21 8:18 AM, Matt DeVillier wrote:
I don't see the problem here TBH. There's no issue, security or otherwise, with coreboot having fmap regions within the IFD BIOS region that are not contiguous. Alignment requirements (eg, 64k) for some regions practically guarantee this.
ifdtool complained here because a manually generated flashmap had a BIOS region that wasn't top-aligned with the IFD one.
On reflection, my initial comments appear a bit of a crazed rant, brought on by a lack of sleep. The flash memory content of unwritten areas of flash memory are no more or less secure than the content of those memory areas that have been specifically written. But the irony here is that "ROM" is not really "Read Only Memory" when it can be written and re-written, any more than a "BIOS" is actually a "Basic Input/Output System" when it does not actually hold Input/Output Subroutines to be called from a dependent Operating System. The colloquial use of these, and many other, misnomers promotes delusional thinking, since "ROM" is often being re-written, and the purpose of the "BIOS" is actually to reset the device hardware, and often, then also write updates to the "ROM".
Any protocol intended to validate nominally fixed areas of "ROM", then, *must* address also any undisclosed/undesignated areas of flash "ROM" expected to be in a "cleared"/"erased" state. If the coreboot FlashMap protocol fails to specifically designate these areas of flash memory, then how are they to otherwise be addressed or tracked? That appears to me to be a potential problem, since otherwise, no definite hash or CRC value can be used to "fingerprint" these memory regions, to assure that they have remained "fixed".
Regardless, it also seems reasonable and desirable that a bit more "sanity checking" should be included in, for instance, "cbfs validate -w", and especially, in the poorly documented, cryptic or silent, "ifdtool --validate", to plainly articulate specific areas of flash memory that have not otherwise been defined/designated, perhaps describing these regions as "GAP", "UN-MAPPED", or some such.
James
On Thu, Jun 24, 2021 at 7:37 AM James Feeney james@nurealm.net wrote:
On 6/24/21 12:48 AM, James Feeney wrote:
On 6/23/21 8:59 PM, James Feeney wrote:
On 6/23/21 6:51 PM, Matt DeVillier wrote:
On Wed, Jun 23, 2021 at 4:36 PM James Feeney james@nurealm.net wrote:
On 6/23/21 1:40 PM, Matt DeVillier wrote: > I'm an idiot and made a stupid math error when I calculated the size > of the SI_BIOS region. 0xF7F000 - 0x1000 is 0xF7E000, not 0xF6F000. > > https://review.coreboot.org/c/coreboot/+/55815 fixes it >
Ha! I was a little suspicious of the suggestive pattern, 0xF7F000 - 0x10000 = 0xF6F000 vs 0xF7F000 - 0x1000 = 0xF7E000. But, I missed the hard-coded "SI_BIOS@0x1000 0xf6f000".
So, I see src/mainboard/google/octopus/default.fmd, specifically, is determining here.
Still, many questions from those of us less familiar. What is the meaning of "SI"? Does "SI_BIOS" have the same usage as "BIOS"? Coreboot "BIOS" is not the same thing as original "BIOS". <rant>...</rant>
coreboot's FMAP is a more finely grained map of the firmware image than the IFD's, which is necessary for coreboot (and vboot, and other utils) to locate things in the different regions.
I'm not sure where the SI_BIOS nomenclature comes from, it's a Google thing I think so one of those folks from the old days would have to chime in. On older boards it did/does encapsulate all of the coreboot FMAP regions which reside inside the IFD's BIOS region.
Are there any "official" specifications for coreboot fmap format?
https://doc.coreboot.org/lib/flashmap.html
Wish me luck. I should have a functional bootrom image now!
well, it would have been functional before, as I've apparently been using improperly sized images for quite some time :)
https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+...
"... gaps are allowed ..."
So then, your images are actually, technically, "proper", even though some rom space was wasted.
But, this element of the specification strikes me as a waking big security problem waiting to happen.
I don't see any substantive reason for the Flashmap Descriptor specification to allow gaps, and, as we have seen, allowing gaps can also lead to inadvertant errors being introduced into the resulting flashmap descriptor files.
I believe, instead, that gaps should specifically be *prohibited* in the Flashmap Descriptor specification.
I suggest that the question of allowing gaps in the flashmap descriptor should receive wider discussion, particularly as having - I would think obvious - security implications, if not simply to avoid inadvertant errors.
James
Hmm - on second thought, I suppose that there are *always* going to be "gaps", since the rom is never "full", and the actual space taken by some random mix of files will not be known in advance.
Maybe the only alternative, simply for the sake of consistency and error checking, is to require and define certain "contiguous" regions of rom, within which gaps would not be allowed. That way, errors would be disclosed, while gaps might be "forced" into defined regions, which could be specifically "locked", if desired.
Other people have thought about this?
James
Or, a simpler idea that could be useful - cbfstool layout could just autogenerate "GAP" regions in the output, to make these more apparent.
James
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Ok, I finally flashed this coreboot.rom to the Samsung Chromebook 4, octopus/casta/bluebird, after disconnecting the battery and:
$ flashrom -p host --wp-status $ flashrom -p host --wp-disable $ flashrom -p host -l layout.txt -i BIOS -w coreboot.rom $ flashrom -p host -r cbimage.bin
with
$ cat -A layout.txt 00001000:00f7efff BIOS$
where flashrom says
FREG0: Flash Descriptor region (0x 0000 0000 - 0x 0000 0fff) is read-only. FREG5: Device Expansion region (0x 00f7 f000 - 0x 00ff ffff) is locked.
Now, pressing the power button lights the display backlight, but that is all.
There is no u-boot prompt, though I have no experience with what to expect here.
Any suggestions, please?
Thanks James
I don't see the command you used to flash -- what was that? You also didn't clear the WP range (flashrom --wp-range 0,0) which has historically been needed on small core/Atom boards, but if you didn't get an error flashing/erasing then you're probably fine.
display backlight means it's booted to ramstage, since that's where FSP-S will init the backlight. It most likely means coreboot ran successfully and the payload is the issue.
How to debug? Get yourself a Suzy-Q cable, rebuild with the serial console enabled, flash via Suzy-Q, and then monitor via the /dev/ttyUSB1 serial port (CPU UART)
see: https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/ca... https://wiki.mrchromebox.tech/Unbricking#Unbricking.2FFlashing_with_a_Suzy-Q...
if you want to try a tested/verified prebuilt image w/Tianocore payload, you can use: https://mrchromebox.tech/test/fw/coreboot_tiano-bluebird-mrchromebox_2021062... https://mrchromebox.tech/test/fw/coreboot_tiano-bluebird-mrchromebox_2021062...
On Fri, Jul 2, 2021 at 7:10 PM James Feeney james@nurealm.net wrote:
Ok, I finally flashed this coreboot.rom to the Samsung Chromebook 4, octopus/casta/bluebird, after disconnecting the battery and:
$ flashrom -p host --wp-status $ flashrom -p host --wp-disable $ flashrom -p host -l layout.txt -i BIOS -w coreboot.rom $ flashrom -p host -r cbimage.bin
with
$ cat -A layout.txt 00001000:00f7efff BIOS$
where flashrom says
FREG0: Flash Descriptor region (0x 0000 0000 - 0x 0000 0fff) is read-only. FREG5: Device Expansion region (0x 00f7 f000 - 0x 00ff ffff) is locked.
Now, pressing the power button lights the display backlight, but that is all.
There is no u-boot prompt, though I have no experience with what to expect here.
Any suggestions, please?
Thanks James
On 7/3/21 8:22 AM, Matt DeVillier wrote:
Thanks for that.
I don't see the command you used to flash -- what was that? You also didn't clear the WP range (flashrom --wp-range 0,0) which has historically been needed on small core/Atom boards, but if you didn't get an error flashing/erasing then you're probably fine.
$ flashrom -p host -l layout.txt -i BIOS -w coreboot.rom
The write-protect range was already 0,0, so I didn't bother with setting that.
display backlight means it's booted to ramstage, since that's where FSP-S will init the backlight. It most likely means coreboot ran successfully and the payload is the issue.
How to debug? Get yourself a Suzy-Q cable, rebuild with the serial console enabled, flash via Suzy-Q, and then monitor via the /dev/ttyUSB1 serial port (CPU UART)
see: https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/ca... https://wiki.mrchromebox.tech/Unbricking#Unbricking.2FFlashing_with_a_Suzy-Q...
I finally received a SuzyQable. There was a supply issue.
And, after lots of reading at
https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/ca...
and related, followed by a bit of trial and error, and then observing the AP console, the boot sequence ends with
... CBFS: Found 'fallback/payload' @0xf2d00 size 0x3ce03 Checking segment from ROM address 0xffc3402c Checking segment from ROM address 0xffc34048 Loading segment from ROM address 0xffc3402c code (compression=1) New segment dstaddr 0x01110000 memsize 0x8ccd4 srcaddr 0xffc34064 filesize 0x3cdcb Loading Segment: addr: 0x01110000 memsz: 0x000000000008ccd4 filesz: 0x000000000003cdcb using LZMA Loading segment from ROM address 0xffc34048 Entry Point 0x01110015 BS: BS_PAYLOAD_LOAD run times (exec / console): 147 / 46 ms CSE FWSTS1: 0x80000245 CSE FWSTS2: 0x30850000 CSE FWSTS3: 0x00000000 CSE FWSTS4: 0x00080000 CSE FWSTS5: 0x00000000 CSE FWSTS6: 0x40000000 ME: Manufacturing Mode : NO ME: FPF status : fused Putting xHCI port 0 into host mode. xHCI port 0 host switch over took 0 ms BS: BS_PAYLOAD_LOAD exit times (exec / console): 17 / 28 ms mp_park_aps done after 0 msecs. Jumping to boot code at 0x01110015(0x79b38000)
And then - nothing - other than that the screen backlight comes on.
So yes, as you say, seems like coreboot works, and my u-boot does not.
if you want to try a tested/verified prebuilt image w/Tianocore payload, you can use: https://mrchromebox.tech/test/fw/coreboot_tiano-bluebird-mrchromebox_2021062... https://mrchromebox.tech/test/fw/coreboot_tiano-bluebird-mrchromebox_2021062...
Compiling flashrom from from both
git clone https://chromium.googlesource.com/chromiumos/third_party/flashrom WARNERROR=no CONFIG_MEC1308=no CONFIG_ENE_LPC=no make
and
git clone https://chromium.googlesource.com/chromiumos/platform/standalone-hdctools flashrom install
which seem to act the same, and then running
sudo ./flashrom -p raiden_debug_spi:target=AP
I get "No EEPROM/flash device found". Running with -V, I see flashrom is just reading all 1's.
Hmm. Nothing I can do until this is made to work.
While waiting for the SuzyQable, I had tried reading the flash memory with the TUMPA flash programmer. No joy. I suppose it is possible that I may have burned-out something on the Chromebook board. However, this seems highly unlikely, because the AP can still boot from the flash memory, and because of the apparent circuit layout. While I do not have a schematic for this Samsung Chromebook 4, listening to
OSFC 2018 - Google Secure Microcontroller and CCD | Vadim Bendebury Oct 2, 2018 https://www.youtube.com/watch?v=gC-lbMNmIsg
and noting particularly the block diagram in slide 9, from
https://2018.osfc.io/talks/google-secure-microcontroller-and-ccd-closed-case... https://2018.osfc.io/uploads/talk/paper/7/gsc_copy.pdf
- the "AP PROG" AND "EC PROG" labels on H1 are backwards - it very much appears that both the AP and the Google H1 security chip access the AP flash through a separate multiplexer chip of some kind. As best as I can tell, there is a kind of multiplexer *internal* to the H1, as seen in slide 2, which connects the GPIO pins to the internal hardware protocol blocks, and another *external* multiplexer that separates the AP and EC SPI buses. Any overloads, applied from attaching a flash programmer to the flash memory, would seem likely to have effected access to flash memory equally, by *both* the H1 and the AP. And that is not the case here. It also seems unlikely that the SPI circuitry would have been built without any kind of circuit protection. But again, I have not seen the actual circuit schematic. Still, it would be a very odd kind of circuit failure to have damaged the opposite end of only one multiplexer port. I also note that the operation of the Cr50, AP, and EC consoles seems entirely as might be expected.
So Matt - question: Have you been able read the AP flash memory of an actual Samsung Chromebook 4, model XE350XBA-K01US, using a SuzyQable?
If you have actual experience with the Samsung Chromebook 4, then I must infer that I've broken the hardware. That would be possible if the GoldLake CPU and H1 SPI bus lines were really connected together directly, without any separate multiplexer chip. Otherwise, I am inclined to question this version of flashrom. For instance, I notice that the Cr50 console reports explicitly
[10398.332186 enable_spi_pinmux: AP]
and, after access,
[10398.445490 usb_spi_board_disable] [10399.512358 AP UART on] [10399.514036 CCD state: UARTAP+TX UARTEC+TX I2C SPI USBEC+TX]
but never explicitly says "usb_spi_board_enable" - though I have no idea if that means anything.
Still, it seems possible that Cr50 may be able to read the AP flash memory, but then "hides" the output because of some "security" mechanism, or that this version of flashrom is having some kind of Cr50 communication problem, giving all 1's. It is also remotely possible that Cr50 has an SPI software bug. SPI is a little weird in that the clock polarity and the clock phase, with respect to reading data, varies from manufacturer to manufacturer. The clock has to be exactly right for this GD25LQ128D chip.
Clearly, coreboot itself is having no trouble reading boot flash memory. I wonder if the same is true for my version of u-boot. I expect that u-boot has to have its own SPI driver for AP flash memory? Or, does coreboot just load the payload to RAM, and then that's the end of boot flash access?
Any thoughts?
Thanks James
On Thu, Jul 22, 2021 at 3:56 PM James Feeney james@nurealm.net wrote:
On 7/3/21 8:22 AM, Matt DeVillier wrote:
Thanks for that.
I don't see the command you used to flash -- what was that? You also didn't clear the WP range (flashrom --wp-range 0,0) which has historically been needed on small core/Atom boards, but if you didn't get an error flashing/erasing then you're probably fine.
$ flashrom -p host -l layout.txt -i BIOS -w coreboot.rom
The write-protect range was already 0,0, so I didn't bother with setting that.
display backlight means it's booted to ramstage, since that's where FSP-S will init the backlight. It most likely means coreboot ran successfully and the payload is the issue.
How to debug? Get yourself a Suzy-Q cable, rebuild with the serial console enabled, flash via Suzy-Q, and then monitor via the /dev/ttyUSB1 serial port (CPU UART)
see: https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/ca... https://wiki.mrchromebox.tech/Unbricking#Unbricking.2FFlashing_with_a_Suzy-Q...
I finally received a SuzyQable. There was a supply issue.
And, after lots of reading at
https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/ca...
and related, followed by a bit of trial and error, and then observing the AP console, the boot sequence ends with
... CBFS: Found 'fallback/payload' @0xf2d00 size 0x3ce03 Checking segment from ROM address 0xffc3402c Checking segment from ROM address 0xffc34048 Loading segment from ROM address 0xffc3402c code (compression=1) New segment dstaddr 0x01110000 memsize 0x8ccd4 srcaddr 0xffc34064 filesize 0x3cdcb Loading Segment: addr: 0x01110000 memsz: 0x000000000008ccd4 filesz: 0x000000000003cdcb using LZMA Loading segment from ROM address 0xffc34048 Entry Point 0x01110015 BS: BS_PAYLOAD_LOAD run times (exec / console): 147 / 46 ms CSE FWSTS1: 0x80000245 CSE FWSTS2: 0x30850000 CSE FWSTS3: 0x00000000 CSE FWSTS4: 0x00080000 CSE FWSTS5: 0x00000000 CSE FWSTS6: 0x40000000 ME: Manufacturing Mode : NO ME: FPF status : fused Putting xHCI port 0 into host mode. xHCI port 0 host switch over took 0 ms BS: BS_PAYLOAD_LOAD exit times (exec / console): 17 / 28 ms mp_park_aps done after 0 msecs. Jumping to boot code at 0x01110015(0x79b38000)
And then - nothing - other than that the screen backlight comes on.
So yes, as you say, seems like coreboot works, and my u-boot does not.
if you want to try a tested/verified prebuilt image w/Tianocore payload, you can use: https://mrchromebox.tech/test/fw/coreboot_tiano-bluebird-mrchromebox_2021062... https://mrchromebox.tech/test/fw/coreboot_tiano-bluebird-mrchromebox_2021062...
Compiling flashrom from from both
git clone https://chromium.googlesource.com/chromiumos/third_party/flashrom WARNERROR=no CONFIG_MEC1308=no CONFIG_ENE_LPC=no make
and
git clone https://chromium.googlesource.com/chromiumos/platform/standalone-hdctools flashrom install
which seem to act the same, and then running
sudo ./flashrom -p raiden_debug_spi:target=AP
I get "No EEPROM/flash device found". Running with -V, I see flashrom is just reading all 1's.
you need to open the CCD first. With the battery disconnected, from a terminal attached to /dev/ttyUSB0, run: ccd open ccd reset factory ccd
that should show the ccd state as open, with all capabilities in column 1 set to 'Y'.
then flashrom will be able to detect / read / write the flash chip
Hmm. Nothing I can do until this is made to work.
While waiting for the SuzyQable, I had tried reading the flash memory with the TUMPA flash programmer. No joy. I suppose it is possible that I may have burned-out something on the Chromebook board. However, this seems highly unlikely, because the AP can still boot from the flash memory, and because of the apparent circuit layout. While I do not have a schematic for this Samsung Chromebook 4, listening to
OSFC 2018 - Google Secure Microcontroller and CCD | Vadim Bendebury Oct 2, 2018 https://www.youtube.com/watch?v=gC-lbMNmIsg
and noting particularly the block diagram in slide 9, from
https://2018.osfc.io/talks/google-secure-microcontroller-and-ccd-closed-case... https://2018.osfc.io/uploads/talk/paper/7/gsc_copy.pdf
- the "AP PROG" AND "EC PROG" labels on H1 are backwards - it very much appears that both the AP and the Google H1 security chip access the AP flash through a separate multiplexer chip of some kind. As best as I can tell, there is a kind of multiplexer *internal* to the H1, as seen in slide 2, which connects the GPIO pins to the internal hardware protocol blocks, and another *external* multiplexer that separates the AP and EC SPI buses. Any overloads, applied from attaching a flash programmer to the flash memory, would seem likely to have effected access to flash memory equally, by *both* the H1 and the AP. And that is not the case here. It also seems unlikely that the SPI circuitry would have been built without any kind of circuit protection. But again, I have not seen the actual circuit schematic. Still, it would be a very odd kind of circuit failure to have damaged the opposite end of only one multiplexer port. I also note that the operation of the Cr50, AP, and EC consoles seems entirely as might be expected.
So Matt - question: Have you been able read the AP flash memory of an actual Samsung Chromebook 4, model XE350XBA-K01US, using a SuzyQable?
see above, the ccd being closed w/default capabilities set is preventing the flash chip from being visible/read/written.
I've used ccd to read/write many an AP flash, including APL/GLK Chromebooks.
If you have actual experience with the Samsung Chromebook 4, then I must infer that I've broken the hardware. That would be possible if the GoldLake CPU and H1 SPI bus lines were really connected together directly, without any separate multiplexer chip. Otherwise, I am inclined to question this version of flashrom. For instance, I notice that the Cr50 console reports explicitly
[10398.332186 enable_spi_pinmux: AP]
and, after access,
[10398.445490 usb_spi_board_disable] [10399.512358 AP UART on] [10399.514036 CCD state: UARTAP+TX UARTEC+TX I2C SPI USBEC+TX]
but never explicitly says "usb_spi_board_enable" - though I have no idea if that means anything.
Still, it seems possible that Cr50 may be able to read the AP flash memory, but then "hides" the output because of some "security" mechanism, or that this version of flashrom is having some kind of Cr50 communication problem, giving all 1's. It is also remotely possible that Cr50 has an SPI software bug. SPI is a little weird in that the clock polarity and the clock phase, with respect to reading data, varies from manufacturer to manufacturer. The clock has to be exactly right for this GD25LQ128D chip.
Clearly, coreboot itself is having no trouble reading boot flash memory. I wonder if the same is true for my version of u-boot. I expect that u-boot has to have its own SPI driver for AP flash memory? Or, does coreboot just load the payload to RAM, and then that's the end of boot flash access?
the latter :)
Any thoughts?
Thanks James
On 7/22/21 3:53 PM, Matt DeVillier wrote: ...
I get "No EEPROM/flash device found". Running with -V, I see flashrom is just reading all 1's.
you need to open the CCD first. With the battery disconnected, from a terminal attached to /dev/ttyUSB0, run: ccd open ccd reset factory ccd
that should show the ccd state as open, with all capabilities in column 1 set to 'Y'.
then flashrom will be able to detect / read / write the flash chip
I believe that I have already done all of that. But please, check to see if I know what I'm doing here:
ccd
State: Opened Password: none Flags: 0x400005 Capabilities: 5555555555000000 UartGscRxAPTx Y 1=Always UartGscTxAPRx Y 1=Always UartGscRxECTx Y 1=Always UartGscTxECRx Y 1=Always FlashAP Y 1=Always FlashEC Y 1=Always OverrideWP Y 1=Always RebootECAP Y 1=Always GscFullConsole Y 1=Always UnlockNoReboot Y 1=Always UnlockNoShortPP Y 1=Always OpenNoTPMWipe Y 1=Always OpenNoLongPP Y 1=Always BatteryBypassPP Y 1=Always UpdateNoTPMWipe Y 1=Always I2C Y 1=Always FlashRead Y 1=Always OpenNoDevMode Y 1=Always OpenFromUSB Y 1=Always OverrideBatt Y 1=Always read_tpm_nvmem: object at 0x100a not found [50.223548 Console unlock allowed] read_tpm_nvmem: object at 0x1007 not found TPM: Capabilities are modified. Use 'ccd help' to print subcommands
ccd testlab
CCD test lab mode enabled
see above, the ccd being closed w/default capabilities set is preventing the flash chip from being visible/read/written.
I've used ccd to read/write many an AP flash, including APL/GLK Chromebooks.
Including a Samsung octopus board? Samsung didn't "cut corners" on the design implementation?
I'm hoping very much that the problem is something simple. But still:
$ sudo ./flashrom -p raiden_debug_spi:target=AP flashrom abb3b091 on Linux 5.12.14-arch1-1 (x86_64) flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Raiden target: 2 No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically.
After running flashrom, the machine appears always to reboot. The Cr50 console says:
[631.035522 enable_spi_pinmux: AP] [631.106361 usb_spi_board_disable] [631.668071 AP UART on] [631.669563 CCD state: UARTAP+TX UARTEC+TX I2C SPI USBEC+TX] [631.884475 deferred_tpm_rst_isr] [631.885501 AP on] [631.886077 tpm_reset_request(0, 0)] [631.886932 tpm_reset_now(0)] [631.890377 tpm_init] tpm_manufactured: manufactured [631.892402 tpm_reset_now: done] [632.031471 AC: R-]
Are there any other things to try, before heating-up the soldering iron? Is there any way to cross-check what flashrom is seeing? Is there any way for Cr50 to directly access the AP boot flash memory itself and then report through the Cr50 console, without involving flashrom?
I see something called "spihash", which gives:
spihash ap
[1396.457412 enable_spi_pinmux: AP] [1396.460723 spi_hash_pp_done: AP]
Then, there is a delay, followed spontaneously by:
[1456.460903 spi_hash_disable] [1457.020969 AP UART on] [1457.022476 CCD state: UARTAP+TX UARTEC+TX I2C SPI USBEC+TX] [1457.237365 deferred_tpm_rst_isr] [1457.238426 AP on] [1457.239028 tpm_reset_request(0, 0)] [1457.239898 tpm_reset_now(0)] [1457.243381 tpm_init] tpm_manufactured: manufactured [1457.245449 tpm_reset_now: done] [1457.384220 AC: R-]
It doesn't look like "spihash ap" is returning anything. But then, from what little I've been able to find, the hash is only suppose to perform some kind of security validation. And "spihash ec" acts about the same.
As to the "broken hardware" theory, have you ever heard of anyone attaching a flash programmer to a Google octopus board and successfully reading flash memory content *in circuit*?
Thanks James
On Thu, Jul 22, 2021 at 7:29 PM James Feeney james@nurealm.net wrote:
On 7/22/21 3:53 PM, Matt DeVillier wrote: ...
I get "No EEPROM/flash device found". Running with -V, I see flashrom is just reading all 1's.
you need to open the CCD first. With the battery disconnected, from a terminal attached to /dev/ttyUSB0, run: ccd open ccd reset factory ccd
that should show the ccd state as open, with all capabilities in column 1 set to 'Y'.
then flashrom will be able to detect / read / write the flash chip
I believe that I have already done all of that. But please, check to see if I know what I'm doing here:
LGTM
ccd
State: Opened Password: none Flags: 0x400005 Capabilities: 5555555555000000 UartGscRxAPTx Y 1=Always UartGscTxAPRx Y 1=Always UartGscRxECTx Y 1=Always UartGscTxECRx Y 1=Always FlashAP Y 1=Always FlashEC Y 1=Always OverrideWP Y 1=Always RebootECAP Y 1=Always GscFullConsole Y 1=Always UnlockNoReboot Y 1=Always UnlockNoShortPP Y 1=Always OpenNoTPMWipe Y 1=Always OpenNoLongPP Y 1=Always BatteryBypassPP Y 1=Always UpdateNoTPMWipe Y 1=Always I2C Y 1=Always FlashRead Y 1=Always OpenNoDevMode Y 1=Always OpenFromUSB Y 1=Always OverrideBatt Y 1=Always read_tpm_nvmem: object at 0x100a not found [50.223548 Console unlock allowed] read_tpm_nvmem: object at 0x1007 not found TPM: Capabilities are modified. Use 'ccd help' to print subcommands
ccd testlab
CCD test lab mode enabled
I've never used testlab mode, looks like it just disables the need for physical presence so shouldn't be an issue
see above, the ccd being closed w/default capabilities set is preventing the flash chip from being visible/read/written.
I've used ccd to read/write many an AP flash, including APL/GLK Chromebooks.
Including a Samsung octopus board? Samsung didn't "cut corners" on the design implementation?
Not a Samsung one, but considering they are all built from the same reference board, it's unlikely Samsung somehow broke CR50 AP access. Then again, they did manage to screw up the HPET (among other things) on CELES. Still, I would consider that a pretty low possibility. I have an Asus octopus/AMPTON board here that I've flashed 100x via ccd.
I'm hoping very much that the problem is something simple. But still:
$ sudo ./flashrom -p raiden_debug_spi:target=AP flashrom abb3b091 on Linux 5.12.14-arch1-1 (x86_64) flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Raiden target: 2 No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically.
that's definitely the issue, I'm just not sure offhand what else could cause the AP flash to not be available.
After running flashrom, the machine appears always to reboot. The Cr50 console says:
this is expected, since the CR50 switches modes to enable flash access. It will reboot when exiting SPI mux mode regardless of the flash operation.
[631.035522 enable_spi_pinmux: AP] [631.106361 usb_spi_board_disable] [631.668071 AP UART on] [631.669563 CCD state: UARTAP+TX UARTEC+TX I2C SPI USBEC+TX] [631.884475 deferred_tpm_rst_isr] [631.885501 AP on] [631.886077 tpm_reset_request(0, 0)] [631.886932 tpm_reset_now(0)] [631.890377 tpm_init] tpm_manufactured: manufactured [631.892402 tpm_reset_now: done] [632.031471 AC: R-]
Are there any other things to try, before heating-up the soldering iron? Is there any way to cross-check what flashrom is seeing? Is there any way for Cr50 to directly access the AP boot flash memory itself and then report through the Cr50 console, without involving flashrom?
I don't believe so, someone from Google would likely be able to better answer
I see something called "spihash", which gives:
spihash ap
[1396.457412 enable_spi_pinmux: AP] [1396.460723 spi_hash_pp_done: AP]
Then, there is a delay, followed spontaneously by:
[1456.460903 spi_hash_disable] [1457.020969 AP UART on] [1457.022476 CCD state: UARTAP+TX UARTEC+TX I2C SPI USBEC+TX] [1457.237365 deferred_tpm_rst_isr] [1457.238426 AP on] [1457.239028 tpm_reset_request(0, 0)] [1457.239898 tpm_reset_now(0)] [1457.243381 tpm_init] tpm_manufactured: manufactured [1457.245449 tpm_reset_now: done] [1457.384220 AC: R-]
It doesn't look like "spihash ap" is returning anything. But then, from what little I've been able to find, the hash is only suppose to perform some kind of security validation. And "spihash ec" acts about the same.
never used those functions / not familiar, but assume they are vboot related
As to the "broken hardware" theory, have you ever heard of anyone attaching a flash programmer to a Google octopus board and successfully reading flash memory content *in circuit*?
never tried since CCD option is available, but in theory it should be possible.
Thanks James
On 7/23/21 8:07 AM, Matt DeVillier wrote:
Thanks for your review.
Are there any other things to try, before heating-up the soldering iron? Is there any way to cross-check what flashrom is seeing? Is there any way for Cr50 to directly access the AP boot flash memory itself and then report through the Cr50 console, without involving flashrom?
I don't believe so, someone from Google would likely be able to better answer
That seems like shortsightedness from Google, not providing some kind of internal test/verification function for some hardware I/O.
As to the "broken hardware" theory, have you ever heard of anyone attaching a flash programmer to a Google octopus board and successfully reading flash memory content *in circuit*?
never tried since CCD option is available, but in theory it should be possible.
Hmm - tentatively, it might be useful to other people to offer the advise "NEVER attach an in-circut flash programmer to an octopus board!" I don't know that anyone would want to actually test this conjecture with their own hardware. It looks like I may have to buy the service manual from Samsung, but they refuse to tell me whether it includes the schematics.
Ironically, the inability to attach a flash programmer in-circuit to a Chromebook having Google's H1 security chip represents a kind of security failure. Specifically, how is the boot flash content to be verified with the certainty that the true content has not been hidden by Cr50, or by, for instance, flashrom running from eMMC root, when the AP is used to read the boot flash?
It cannot be verified. The only alternative is to unsolder the flash chip, and read it externally. Of course, if Cr50 has been compromised, verifying boot flash may not matter. But then, in the end, this is Google's "Security by Obscurity - just hide it in hardware" strategy, since I don't know that there is any way to verify the Cr50 code running in the H1 chip. You'd think that, by now, people would have given-up on the "Security by Obscurity" strategy - but I suppose that marketing and management have still not caught-up, gotten the memo, whatever - "Intellectual Property Rights", "Trade Secrets", "National Security", blah, blah, blah.
Also ironically, the actual cost to provide circuit protection for in-circuit flash programming is approximately "zero" - the cost of a few resistors and maybe a diode. I found this interesting:
"Integrity Enhancements for Embedded Linux Devices", David Safford https://selinuxproject.org/~jmorris/lss2013_slides/safford_embedded_lss_slid...
It looks like the maximum current on a typical ARM SC300 GPIO, as used for the H1, is about 4mA. Compare this to the maximum current available from a typical buffer output, as from a flash programmer, of about 50mA, if these circuits were to be directly connected.
</rant>
James
On Fri, Jul 23, 2021 at 12:13 PM James Feeney james@nurealm.net wrote:
On 7/23/21 8:07 AM, Matt DeVillier wrote:
Thanks for your review.
Are there any other things to try, before heating-up the soldering iron? Is there any way to cross-check what flashrom is seeing? Is there any way for Cr50 to directly access the AP boot flash memory itself and then report through the Cr50 console, without involving flashrom?
I don't believe so, someone from Google would likely be able to better answer
That seems like shortsightedness from Google, not providing some kind of internal test/verification function for some hardware I/O.
As to the "broken hardware" theory, have you ever heard of anyone attaching a flash programmer to a Google octopus board and successfully reading flash memory content *in circuit*?
never tried since CCD option is available, but in theory it should be possible.
Hmm - tentatively, it might be useful to other people to offer the advise "NEVER attach an in-circut flash programmer to an octopus board!" I don't know that anyone would want to actually test this conjecture with their own hardware. It looks like I may have to buy the service manual from Samsung, but they refuse to tell me whether it includes the schematics.
Ironically, the inability to attach a flash programmer in-circuit to a Chromebook having Google's H1 security chip represents a kind of security failure. Specifically, how is the boot flash content to be verified with the certainty that the true content has not been hidden by Cr50, or by, for instance, flashrom running from eMMC root, when the AP is used to read the boot flash?
Inability? due to it being a WSON-8 chip or? Every Chromebook since ~2013 has supported ISP, AFAIK. And up until recently, most used a clippable SOIC-8 chip.
It cannot be verified. The only alternative is to unsolder the flash chip, and read it externally. Of course, if Cr50 has been compromised, verifying boot flash may not matter. But then, in the end, this is Google's "Security by Obscurity - just hide it in hardware" strategy, since I don't know that there is any way to verify the Cr50 code running in the H1 chip. You'd think that, by now, people would have given-up on the "Security by Obscurity" strategy - but I suppose that marketing and management have still not caught-up, gotten the memo, whatever - "Intellectual Property Rights", "Trade Secrets", "National Security", blah, blah, blah.
Also ironically, the actual cost to provide circuit protection for in-circuit flash programming is approximately "zero" - the cost of a few resistors and maybe a diode. I found this interesting:
"Integrity Enhancements for Embedded Linux Devices", David Safford https://selinuxproject.org/~jmorris/lss2013_slides/safford_embedded_lss_slid...
It looks like the maximum current on a typical ARM SC300 GPIO, as used for the H1, is about 4mA. Compare this to the maximum current available from a typical buffer output, as from a flash programmer, of about 50mA, if these circuits were to be directly connected.
</rant>
James
On 7/23/21 1:58 PM, Matt DeVillier wrote:
Ironically, the inability to attach a flash programmer in-circuit to a Chromebook having Google's H1 security chip represents a kind of security failure. Specifically, how is the boot flash content to be verified with the certainty that the true content has not been hidden by Cr50, or by, for instance, flashrom running from eMMC root, when the AP is used to read the boot flash?
Inability? due to it being a WSON-8 chip or? Every Chromebook since ~2013 has supported ISP, AFAIK. And up until recently, most used a clippable SOIC-8 chip.
Lucky for me, the Chromebook 4 still uses the SOP8 208MIL package. Or, it might be argued, unlucky for me, that I would bother the boot flash chip.
"Inability" only based upon the theory that maybe the Chromebook multiplexer was damaged when I connected the TUMPA to the flash chip.
Of course, I still don't really know what the problem is. It might be the result of the way I connected the TUMPA - operator error. It may be that this Chromebook was already defective upon receipt. Or, there may be some obscure bug in my current build of Google flashrom. Or, it might just be some unlucky unlikely random hardware glitch.
So, "inability" may be inappropriate here, and I'm in a mood, feeling frustrated. But I do appreciate your help. Something will work out - one step at a time.
James
ok! One problem identified and resolved - the "No EEPROM/flash device found."
It turns-out that no on-board circuitry was damaged in connecting the external flash programmer. Instead, this Samsung Chromebook 4, model XE310XBA-K01US, revision 1.0 motherboard, is *missing* the four series resistors connecting the H1B2C Google Security Chip to the GigaDevice 25LQ128D boot flash memory device. Consequently, the Serial-Out line always remains in the pulled-up high state, and the GSC sees all 1's. Only the Gemini Lake SOC SPI bus is connected to the boot flash device. The simplest solution is to solder-bridge the pads for these 0402 size resistors, which then allows Closed Case Debugging to function as expected.
More generally, it seems that manufacturer implementations of Google reference designs can be quite variable. Some boards do not include the separate SPI bus multiplexer chip shown in presentations on the GSC, and instead, directly connect the GSC and SOC tri-state GPIO lines and provide pull-up resistors. And, as in this case, some manufacturers do not even connect the GSC to the boot flash memory device.
As I understand, manufacturers are not suppose to leave the GSC disconnected from the SPI bus to the flash device. However, also, apparently there are no legal constraints associated with the "Chromebook" trade name requiring Closed Case Debugging to be functional. It would be useful to keep track of these "problem" Chromebooks.
I haven't discovered the cause of my difficulty with the external flash programmer. I note that the Not-Write-Protect and Not-Hold lines are not part of the basic 4-wire SPI bus, and I have not found documentation about how these lines are driven. It may be that their default state depends upon the Closed Case Debugging permissions. But now, with CCD working, the external programmer is not needed.
So, I can get back to debugging my u-boot payload.
James
-
James Feeney -
Matt DeVillier