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 <[email protected]> wrote: > > On 6/22/21 11:13 PM, Matt DeVillier wrote: > > 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. > > > > 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 <[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] > > _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
