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> 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 <[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] > _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
