[coreboot] FSP 2.0 headers in coreboot

[Youness Alaoui]

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.

I would personally say "if the FSP headers in coreboot are for FSP
2.5.0 which is newer, then why isn't that 2.5.0 file made public?". If
we were to have a rule, then maybe forcing blobs to be available
publicly before having coreboot use/integrate them is a good step, so
if you plan on pushing a commit that adds FSP 3.0 to coreboot, then
that commit won't be merged until the associated blob becomes publicly
available (even if it's on intel's github and is non redistributable),
because merging commits that adds headers/support for some blob that
nobody has access to makes no sense if we think of coreboot as a
project that any enthusiast can clone and build for any machine if
they want to.

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,
- 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).
- 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).

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 ?

Thanks,
Youness.



On Thu, May 10, 2018 at 9:34 PM, Nico Huber <nico.h at gmx.de> wrote:
> On 11.05.2018 01:39, Timothy Pearson wrote:
>> Not to jump too far into the fray, but couldn't this be handled by
>> simply not blocking coreboot development on proprietary blobs?  For
>> instance, if someone wants to implement a feature that requires
>> repository-wide changes (e.g. the timestamp stuff that went in a couple
>> of years back) that happens to break only some blobby boards, that the
>> feature should be implemented anyway and the broken blobby boards added
>> back in as the vendor has time / inclination to fix?
>
> If we maintain the code for end users and not for vendors, vendors won't
> do anything. And the end users can't, I would call them developers
> otherwise.
>
>>
>> Basically, this seems to be what Linux already does for kernel work.
>> The benefit of upstreaming open code is that other people will maintain
>> it for you, but if you really need to publish a binary only driver
>> (NVIDIA) then you have the full burden of maintenance on yourself as the
>> vendor.  This encourages contribution back without putting an arbitrary
>> administrative limit on what kind of blob level is acceptable.
>
> The difference here is that Linux made it. It's not only accepted by
> vendors but actively employed. I fear for coreboot, currently, it's
> mostly the silicon vendor's customers that want (or maybe even only
> accept) it. Plus coreboot is firmware, nobody is used to maintain firm-
> ware.
>
> IMHO, we should make coreboot most easy to port to the widest range of
> boards possible. To extend the community. If that's only feasible
> through blobs (atm?), I can take it. But if a blob only helps that
> one company who built it, I don't see much value in it.
>
> Nico
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot