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