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