On Fri, Dec 15, 2023 at 11:29 AM James Feeney james@nurealm.net wrote:
… I expect that that refers to an even newer "release 9" versus a
"release 8". And, this "-r9" should also work with the setting: CONFIG_FSP_HEADER_PATH= "src/vendorcode/intel/fsp/fsp2 _0/geminilake/ 2.2.3.1 " Is that correct?
NO! those strings are simply build paths, they have no correlation to
the version of headers which need to be used with a given binary/binaries. Google binaries use Google's headers. Intel's binaries use Intel's headers.
Then, how do I find whether a particular fspm/fsps set is using the coreboot 2.2.0.0 headers or the 2.2.3.1 headers? Those headers are very similar.
you can't, without knowing the exact build they came from. If they are Google built firmware images, they are using the Google FSP binaries/headers. For anything else, you'd need to know the tree/hash it was built from and which header values were selected by the build.
Also, the binaries in my repo would not have anything resembling that
build path as it's specific to a Google ChromeOS build system, and my binaries are not from a ChromeOS device.
Oops! I was looking at your binaries in 3rdparty/blobs/mainboard/google/octopus/casta/ instead of your binaries from the site-local/Kconfig, 3rdparty/blobs/soc/intel/glk/fsp/release/.
$ strings 3rdparty/blobs/soc/intel/glk/fsp/release/Fsp_M.fd |grep -i gemini|head -1
c:\tcwork\bxt_ap7829\Build\GeminilakeFspPkg\RELEASE_VS2013x86\IA32\GeminilakeSiliconPkg\NorthCluster\MemoryInitGlk\MemoryInitFsp\DEBUG\AutoGen.c
Where your config is for the edk2 payload, is there any reason that these same edk2 FSP files would not also work with the LinuxBoot payload?
I have no idea what you are asking here - edk2 FSP files? That phrase does not make sense to me. I'm also not familiar with the LinuxBoot payload or how it would relate to edk2