Re: [coreboot] FSP 2.0 headers in coreboot

[Aaron Durbin]

On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui
 wrote:
> Hi,
>
> I've just pushed a commit for review on gerrit
> (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to
> open the discussion here on whether the public coreboot code should
> have the FSP headers that match the public FSP headers or if they
> should match the 'google fsp' headers.
>
> My understanding of the situation is that chromebooks ship with a
> google-modified FSP image and the fsp headers in coreboot have been
> added by google employees even before the FSP was officially made
> public by Intel. I also somewhat understood that the fsp headers in
> coreboot would not be updated to match the public release because it
> would break everyone building coreboot for their chromebooks or
> something like that.

They aren't modified necessarily. It's more of different views on the
same timeline of a development. Granted, the releases are definitely
not coordinated. I'm not even sure how/who releases the github
blobs/headers on Intel's side.
> I'm a bit tired of always having that commit that fixes the header
> applied locally in all my branches, and I think that it makes much
> more sense for coreboot to have the fsp headers that match the public
> release and for the google/chromebook coreboot repository to have the
> "non-standard header" committed to it instead.
> Worst case scenario, we could add #ifdefs to determine what the
> structure contents should be depending on the target platform.
>
> Maybe everyone will say "of course, that makes sense" or maybe
> everyone will say "nope, I disagree", but hopefully we can have the
> discussion here (or on gerrit) and decide how to handle this use case.
> Note: I only pushed for skylake/kabylake, but apollolake/canonlake are
> probably also affected by this mismatch of headers.

I think we should have both that can be selected through a Kconfig
such that we can bind to the headers correctly. We already had to do
that for edk2 issues as well. I can't think of better alternative at
the moment that supports both.
> Thanks,
> Youness.