On Tue, Jun 22, 2021 at 10:59 PM James Feeney <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 -- [email protected] > >>>> To unsubscribe send an email to [email protected] > >>> _______________________________________________ > >>> coreboot mailing list -- [email protected] > >>> To unsubscribe send an email to [email protected] > >>> _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
