New subject: FSP 2.0 headers in coreboot

18 May 2018

      On 11.05.2018 21:18, Youness Alaoui wrote:
...
I feel like this discussion is getting slightly out of hand, so let's
try to regroup a bit and move the discussion back to the original
topic : how to handle the FSP headers in coreboot.
I fully understand and agree with Nico's frustration about the blobs
situation and I think that's a bigger conversation than needed right
now. I do encourage discussing it and finding a good solution to avoid
having a similar mess in the future (or now, but in a different thread
to avoid going off-topic). I think Nico's idea of setting up rules for
how/what to merge in the future is a good idea and needs to be further
discussed until everyone is happy with the rules defined.
Yep, sorry. I'll try again in another thread, I guess.
...
Now, back to the discussion about the "incompatible FSP headers", here
are the possibilities :

should we merge my patch that makes the FSP header compatible with

the public blob, and let the CrOs coreboot clone have its own commit
that reverts it,
I have to admit, I don't like your patch. While it gets the job done,
it brings `MemInfoHob.h` and `FspsUpd.h` out of sync, so the state in
coreboot as a whole would match neither version.
...

or abandon my patch (which means I can never send a working

board-status for the librems without having a dirty tree or a version
commit hash that doesn't match upstream)

or have the possibility to choose between the two (either via

#ifdefs or via a variants method).
If we can't get a new, fitting binary out of Intel, I would prefer this,
or, more bluntly, just copy the GitHub version and revert the changes
that need the additional UPD.
In other words, whatever happens, I think we should have the headers
of the latest public release in the tree.
...

or, if Intel people are reading this right now (or someone here can

poke them directly), have the public release updated so this matter
can be dropped entirely (the public update would need to be released
*very* soon though).
Even if you (Purism) poke them about it, that might help. But I would
like to see that Google does that too (IMHO, they profit most from the
mess). Any of you should have more leverage than the customer of a
customer of a customer of a potential customer of Intel has, that I
work for ;)
...
Should we put this to a vote now, or should we discuss the
possibilities/alternatives some more, if anyone has ideas on how to
tackle this specific issue ?
Well, my vote, in order of preference:
1. Poke Intel.
 2. Get a verbatim copy of the GitHub headers in (in a way of effort for
    the community). Maybe in a month from now? no matter the outcome
    from 1.
Nico

Re: [coreboot] FSP 2.0 headers in coreboot