Re: geminilake fsp on Google Chromebook?

On Sun, Dec 10, 2023 at 7:04 PM James Feeney <[email protected]> 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 <
> [email protected]> 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/Kconfig#L38
> >
>
> 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 -- [email protected]
> > > To unsubscribe send an email to [email protected]
>
>

_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]