Comparing the git trees for the current stock coreboot and for your MrChromebox-4.21, I'm wondering about the .config differences generated by nconfig at CONFIG_FSP_HEADER_PATH=.
./src/soc/intel/apollolake/Kconfig has:
config FSP_HEADER_PATH default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.0.0" if VENDOR_GOOGLE && SOC_INTEL_GEMINILAKE default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1" if SOC_INTEL_GEMINILAKE default "3rdparty/fsp/ApolloLakeFspBinPkg/Include/"
But, "make nconfig" in the MrChromebox tree, nonetheless, produces 'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1"' in the .config, somehow, despite the above, while the stock coreboot "make nconfig" instead produces 'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.0.0"', as might be expected.
Can someone explain why there is the "if VENDOR_GOOGLE && SOC_INTEL_GEMINILAKE" consraint for the fsp?
Is fsp 2.2.3.1 actually still the correct configuration when using the fsp.bin files extracted from the stock Google ChromeOS?
Thanks James
On Fri, Dec 8, 2023 at 10:53 PM James Feeney via coreboot < coreboot@coreboot.org> wrote:
Comparing the git trees for the current stock coreboot and for your MrChromebox-4.21, I'm wondering about the .config differences generated by nconfig at CONFIG_FSP_HEADER_PATH=.
./src/soc/intel/apollolake/Kconfig has:
config FSP_HEADER_PATH default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.0.0" if VENDOR_GOOGLE && SOC_INTEL_GEMINILAKE default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1" if SOC_INTEL_GEMINILAKE default "3rdparty/fsp/ApolloLakeFspBinPkg/Include/"
But, "make nconfig" in the MrChromebox tree, nonetheless, produces 'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/ 2.2.3.1"' in the .config, somehow, despite the above, while the stock coreboot "make nconfig" instead produces 'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/ 2.2.0.0"', as might be expected.
I override it in my site-local/Kconfig:
https://github.com/MrChromebox/coreboot/blob/MrChromebox-4.21/site-local/Kco...
Can someone explain why there is the "if VENDOR_GOOGLE && SOC_INTEL_GEMINILAKE" consraint for the fsp?
Is fsp 2.2.3.1 actually still the correct configuration when using the fsp.bin files extracted from the stock Google ChromeOS?
it's not, but I don't use the fsp*.bin files extracted from the stock ChromeOS firmware images for GLK boards.
Thanks James
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Fri, 2023-12-08 at 23:26 -0600, Matt DeVillier wrote:
On Fri, Dec 8, 2023 at 10:53 PM James Feeney via coreboot coreboot@coreboot.org wrote:
Comparing the git trees for the current stock coreboot and for your MrChromebox-4.21, I'm wondering about the .config differences generated by nconfig at CONFIG_FSP_HEADER_PATH=.
./src/soc/intel/apollolake/Kconfig has:
config FSP_HEADER_PATH default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.0.0" if VENDOR_GOOGLE && SOC_INTEL_GEMINILAKE default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1" if SOC_INTEL_GEMINILAKE default "3rdparty/fsp/ApolloLakeFspBinPkg/Include/"
But, "make nconfig" in the MrChromebox tree, nonetheless, produces 'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1"' in the .config, somehow, despite the above, while the stock coreboot "make nconfig" instead produces 'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.0.0"', as might be expected.
I override it in my site-local/Kconfig:
https://github.com/MrChromebox/coreboot/blob/MrChromebox-4.21/site-local/Kco...
Yes, I did copy-over site-local/Kconfig, but this initially had no effect on FSP_HEADER_PATH in the resulting .config. Hmm - apparently, the site-local/Kconfig does not override an existing .config setting, except for variables that have not already been set. So some settings change after copying-over site-local/Kconfig, and some do not change. It's not obvious what to expect at first, though it seems obvious in retrospect.
Aha - it turns-out that the display is also a little confusing, at least with nconfig, and probably not what was intended.
There is a line under the Generic Drivers menu, effectively by itself, under a completely unrelated selection:
[ ] Enable AMP MAX98396 (src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1) Location of FSP headers
But the "F2/SymInfo" still works there, and describes FSP_HEADER_PATH.
Below that, there is a selection:
[ ] Add Intel FSP 2.0 binaries to CBFS (fsps.bin) Name of FSP-S in CBFS (fspm.bin) Name of FSP-M in CBFS
this is ADD_FSP_BINARIES, only displayed because of soc/intel/apollolake/Kconfig with PLATFORM_USES_FSP2_0 [=y], but, it is not automatically selected, and this despite CONFIG_FSP_HEADER_PATH already having been set automatically from site-local/Kconfig, as above. The resulting .config will have FSP_HEADER_PATH set, whether or not ADD_FSP_BINARIES itself is set.
And yet, unless ADD_FSP_BINARIES is selected *manually*, the menu for FSP_FULL_FD, and, as if directly related to that, FSP_M_FILE and FSP_S_FILE, are not even visible, and again, despite these file paths already having been selected and set from site-local/Kconfig.
Does setting or not setting ADD_FSP_BINARIES have any effect on the resulting compiled coreboot ROM?
This seeming ambiguity with ADD_FSP_BINARIES raises uncertainty and doubt for the user and makes FSP_M_FILE and FSP_S_FILE potentially undiscoverable. Should ADD_FSP_BINARIES be automatically selected when FSP_HEADER_PATH has been set? Or the converse, having FSP_HEADER_PATH visible, selected, and set only when ADD_FSP_BINARIES has been selected?
Can someone explain why there is the "if VENDOR_GOOGLE && SOC_INTEL_GEMINILAKE" consraint for the fsp?
Is fsp 2.2.3.1 actually still the correct configuration when using the fsp.bin files extracted from the stock Google ChromeOS?
it's not, but I don't use the fsp*.bin files extracted from the stock ChromeOS firmware images for GLK boards.
Hmm - so, if the blob files referenced in site-local/Kconfig are not extracted from the stock ChromeOS firmware images for GLK boards, and they are not built from source by coreboot, then where are they from?
How are these blobs actually acquired "from scratch"? Do *any* blobs actually need to be extracted from the stock ChromeOS firmware images? Or, can they all be built through coreboot, somehow?
Thanks James
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Sun, Dec 10, 2023 at 7:04 PM James Feeney james@nurealm.net wrote:
On Fri, 2023-12-08 at 23:26 -0600, Matt DeVillier wrote:
On Fri, Dec 8, 2023 at 10:53 PM James Feeney via coreboot <
coreboot@coreboot.org> wrote:
Comparing the git trees for the current stock coreboot and for your
MrChromebox-4.21, I'm wondering about the .config differences generated by nconfig at CONFIG_FSP_HEADER_PATH=.
./src/soc/intel/apollolake/Kconfig has:
config FSP_HEADER_PATH default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.0.0"
if VENDOR_GOOGLE && SOC_INTEL_GEMINILAKE
default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1"if SOC_INTEL_GEMINILAKE
default "3rdparty/fsp/ApolloLakeFspBinPkg/Include/"But, "make nconfig" in the MrChromebox tree, nonetheless, produces
'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/ 2.2.3.1"' in the .config, somehow, despite the above, while the stock coreboot "make nconfig" instead produces 'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/ 2.2.0.0"', as might be expected.
I override it in my site-local/Kconfig:
https://github.com/MrChromebox/coreboot/blob/MrChromebox-4.21/site-local/Kco...
Yes, I did copy-over site-local/Kconfig, but this initially had no effect on FSP_HEADER_PATH in the resulting .config. Hmm - apparently, the site-local/Kconfig does not override an existing .config setting, except for variables that have not already been set. So some settings change after copying-over site-local/Kconfig, and some do not change. It's not obvious what to expect at first, though it seems obvious in retrospect.
nothing overrides an existing config except selections in menuconfig/nconfig
Aha - it turns-out that the display is also a little confusing, at least with nconfig, and probably not what was intended.
There is a line under the Generic Drivers menu, effectively by itself, under a completely unrelated selection:
[ ] Enable AMP MAX98396 (src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1) Location of FSP headers
But the "F2/SymInfo" still works there, and describes FSP_HEADER_PATH.
Below that, there is a selection:
[ ] Add Intel FSP 2.0 binaries to CBFS (fsps.bin) Name of FSP-S in CBFS (fspm.bin) Name of FSP-M in CBFS
this is ADD_FSP_BINARIES, only displayed because of soc/intel/apollolake/Kconfig with PLATFORM_USES_FSP2_0 [=y], but, it is not automatically selected, and this despite CONFIG_FSP_HEADER_PATH already having been set automatically from site-local/Kconfig, as above. The resulting .config will have FSP_HEADER_PATH set, whether or not ADD_FSP_BINARIES itself is set.
And yet, unless ADD_FSP_BINARIES is selected *manually*, the menu for FSP_FULL_FD, and, as if directly related to that, FSP_M_FILE and FSP_S_FILE, are not even visible, and again, despite these file paths already having been selected and set from site-local/Kconfig.
Does setting or not setting ADD_FSP_BINARIES have any effect on the resulting compiled coreboot ROM?
all this mess is because you're trying to use an existing config rather than start from my defconfig, which is designed to work with my repo. The selections are currently guarded appropriately. ADD_FSP_BINARIES only needs to be selected if not using the 3rdparty/fsp repo (as it's selected by default there).
This seeming ambiguity with ADD_FSP_BINARIES raises uncertainty and doubt for the user and makes FSP_M_FILE and FSP_S_FILE potentially undiscoverable. Should ADD_FSP_BINARIES be automatically selected when FSP_HEADER_PATH has been set? Or the converse, having FSP_HEADER_PATH visible, selected, and set only when ADD_FSP_BINARIES has been selected?
no, it should not. One might want to compile coreboot without FSP binaries for whatever reason, which cannot be done without the headers for platforms using FSP. FSP_HEADER_PATH is only visible when USE_FSP_REPO is not selected (otherwise it is automatically set).
Can someone explain why there is the "if VENDOR_GOOGLE &&
SOC_INTEL_GEMINILAKE" consraint for the fsp?
Is fsp 2.2.3.1 actually still the correct configuration when using the
fsp.bin files extracted from the stock Google ChromeOS?
it's not, but I don't use the fsp*.bin files extracted from the stock
ChromeOS firmware images for GLK boards.
Hmm - so, if the blob files referenced in site-local/Kconfig are not extracted from the stock ChromeOS firmware images for GLK boards, and they are not built from source by coreboot, then where are they from?
they're extracted from another coreboot device which uses newer FSP blobs than the Google ones. Which is why I use the newer headers.
How are these blobs actually acquired "from scratch"? Do *any* blobs actually need to be extracted from the stock ChromeOS firmware images? Or, can they all be built through coreboot, somehow?
from scratch? with an Intel NDA agreement I suppose. You absolutely need the other blobs like the IFWI, DSP firmware, etc. No blobs are built via coreboot, that's why they are blobs.
Thanks James
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Yes, I did copy-over site-local/Kconfig, but this initially had no effect on FSP_HEADER_PATH in the resulting .config. Hmm - apparently, the site-local/Kconfig does not override an existing .config setting, except for variables that have not already been set. So some settings change after copying-over site-local/Kconfig, and some do not change. It's not obvious what to expect at first, though it seems obvious in retrospect.
Right, Kconfig never changes a setting in an existing .config based on a different default value. To get it to update values to new default settings, run:
make savedefconfig && make defconfig KBUILD_DEFCONFIG=${PWD}/defconfig
The Kconfig in coreboot document is written with developers writing Kconfig files in mind, but it's got a lot of useful information about how Kconfig works.
https://doc.coreboot.org/getting_started/kconfig.html
Martin
-
James Feeney -
Martin Roth -
Matt DeVillier