[coreboot] FSP 2.0 headers in coreboot

[Nico Huber]

On 11.05.2018 01:32, Aaron Durbin 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.

As I tried to explain in my other (just sent) mail, I care most about
other developers being able to pick up coreboot and use it for their
boards. And this is something where we can improve a lot regarding the
blob situation, IMO. I just hope, if we had rules that recommend redis-
tributable blobs and push into this direction, one day, somebody new to
the game (i.e. without prior contact to a silicon vendor) could again
just use coreboot.

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

Well, it wasn't my choice. And after many months struggling to get a
single board working, I wouldn't do it again for a new platform. Now
that I know the Sky-/Kaby Lake code another board port would work out.
But if things don't get better, I'd rather start reverse engineering
right away for a new platform. I'm sure that would save us some time on
average if somebody else would use the code, too.

> 
> 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?

Can I use the CrOS FSP for a product? I'm convinced that I can use the
one from GitHub.

> I don't believe either can be submitted into coreboot.org blobs repo?
> Or did I miss where that was concluded?

If it was, I missed that too. AFAIR, I checked that once for the License
on GitHub (and did not see a way).

Nico

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