[coreboot] FSP 2.0 headers in coreboot

[Timothy Pearson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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?

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.

On 05/10/2018 06:32 PM, Aaron Durbin via coreboot wrote:
> On Thu, May 10, 2018 at 5:10 PM, Nico Huber <nico.h at gmx.de> wrote:
>> Ok, I'll try to break this loop here. You are repeating the great bene-
>> fits for a user (that I agree to) even if a blob is involved. And I keep
>> asking why it should happen on our master branch (I don't see how we
>> would take something away by not maintaining everything. Also, I never
>> tried to exclude all blobs). It seems somehow we talk past each other.
> 
> I've been meaning to respond to your original response, but I haven't
> had a lot of time to articulate things. You've brought this up
> numerous times; it sounds like you care what is in the master branch.
> But maybe not any other branches? And what is the threshold for being
> in master branch? And what audience is the master branch for? I'm
> trying to envision what the development and eventual result will be.
> 
> You have been focusing on FSP talking about maintaining it, etc, but I
> don't think that maintainership is falling on people
> disproportionately any more than other parts of the tree. I do find it
> a bit ironic that you were te one using FSP for some of your work.
> 
> As for the github fsp proper, the license in the headers is weird, as
> Youness pointed out. But in addition to that, it says IOTG Kabylake H
> as a release. It doesn't say anything beyond that from a support
> standpoint. Empirically it may work, but so does the FSP generated by
> Chrome OS. As I'm sure you know assets can be extracted from recovery
> images for those FSPs. What's the bar for picking one over the other?
> I don't believe either can be submitted into coreboot.org blobs repo?
> Or did I miss where that was concluded?
> 
> Anyway, just lots of questions -- not many statements. I'm trying to
> understand the distinction when I don't see many differences of a
> situation I think most people would agree is unfortunate.
> 
>> On 10.05.2018 23:26, Julius Werner wrote:
>>>> You really seem to miss the point of free software.
>>>
>>> Okay, now this is starting to get personal again, let's please not go
>>> there. You too have been among those who spoke out against that in that
>>> derailment thread recently. It's insulting to insinuate that some of us
>>> don't understand or don't care about free software just because we're
>>> working for a big company. You also don't need to educate me about the
>>> spirit of the GPL or the fundamental travesty of jumping back and forth
>>> between blobs and GPL code a dozen times during a single boot and calling
>>> it okay because it's "technically not linking". I am aware of these things
>>> and I'm not happy about them either. But there have been blobs in most
>>> boards that were added to this project since before I started working on it
>>> and there will keep being blobs for the foreseeable future. You are not
>>> going to convince Intel to open-source their FSP by yelling at fellow
>>> coreboot developers about it. It's the reality we live in. This discussion
>>> started (as I understood it) about how we can make the blob situation we
>>> *are* living with a little better, so let's keep it focused on that.
>>>
>>>> As long as everybody
>>>> adheres to the copyleft, you can do things on your own. If a blob ends
>>>> up being only useful for a single board, ok. Should somebody be able to
>>>> sell his product with it, sure. But why should the community maintain
>>>> that shit (partially on the shoulders of volunteers) if it doesn't pro-
>>>> vide what free software provides?
>>>
>>> "That shit" allows people to build custom firmware for the hardware that
>>> they bought, which I think is a very important and worthwhile benefit on
>>> its own. For Chromebooks, a whole little ecosystem of custom ROMs and build
>>> instructions has developed around this. Do you want to take that away from
>>> everyone just because some of the blobs may be mainboard specific? (And
>>> again, as far as I am aware most blobs aren't really tied to a specific
>>> mainboard, they're just SoC support which may or may not have been written
>>> to include whatever peripheral support a particular mainboard needs. You
>>> are really just complaining that peripheral support which the existing
>>> mainboards didn't need is not implemented yet, which is a situation that
>>> can happen just as well on a fully blob-free board.)
>>>
>>> It's not just free software when you can port it to a completely new
>>> mainboard, in the same way that the coreboot core code is still free
>>> software even though you can't automatically port it to any new chipset.
>>> You can still add features or make changes to customize behavior for an
>>> existing board. You can make it boot your own operating system with custom
>>> calling convention, add some code signing or measuring framework, or make
>>> it play the Jeopardy melody on the speaker while it's booting. That, too,
>>> is a benefit of free software.
>>>
> 


- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJa9Ng5AAoJEK+E3vEXDOFb7dsIAI50Zb77V97IPaspCSUJsAvm
eG/yAwrdutPUVrXptGVfq3sshO2ZnyKeWNbeQPCWC2P+NsZZqCxMEo1Ozer+drPM
3euUWqv/CUIOkyjncEjcmEwvlskkGLNygTSa/NCpOHGhRaYR8RjVpD7GI5Y8E5NI
+OKfZ06R4WL2tEBL6f8fr0CPA3W7jbscvwsQfV173QCrKbMX/KelkKof7gvT9JGh
OJY6KqnGGtrtuRtNB0bFC0gTz1/UYGwlVhy3iW30OcXTbnvA4kiR6qv3w7k/Y95D
68wI0OdTo9Jy6lvm3BjiZwLImKiZqJmDb0nCZOPU8tqPnnc9F5zd9FMMl61UeQU=
=fEKP
-----END PGP SIGNATURE-----