Dear Martin,
Am 05.11.21 um 18:15 schrieb Martin Roth:
Nov 4, 2021, 05:24 by [email protected]:
On 20.10.21 14:24, Nico Huber wrote:
My proposal: How about we set up some guidelines how to proceed
when adding support for a new platform that requires any blobs?
My vague idea is as follows: Before the very first commit for
such a new platform can be merged, a set of predefined, blob
related questions (to be discussed) should be answered. This
should also apply if a new platform just brings the same kind of
blobs with it as its predecessor (e.g. next gen FSP). Situations
may change and blobs do too. Speaking of FSP, it's actually a set
of many blobs. I think questions should be answered for each part
of it individually.
[…]
What do you think?
Thank you for bringing this up, and I totally agree. Reaching out
to the coreboot community and including it in the planing phase is
currently lacking quite a lot. The coreboot mailing list is the
perfect forum for that, but unfortunately not used a lot.
The current reality is that binary blobs are needed for almost every
platform in coreboot. I believe the coreboot leadership is united
behind the unfortunate reality that allowing these blobs is a
requirement for the platform. I don't think we're going to refuse a
platform right now simply because it has blobs. I'm not sure what
coreboot would look like right now if we'd started refusing blobs
when the required blobs started appearing, but it definitely wouldn't
have many modern platforms.
As already answered by Nico, the proposal was never about prohibiting blobs.
We all agree that we don't like adding more proprietary binaries, but
there are times when a binary needs to be closed for a time until the
platform is released such as with the PSE.
In this case it even turned out, that the PSE firmware uses Zephyr [1]
is used, and that even for the contributor it wasn’t clear yet, how the
release plans regarding the sources are.
This should be acceptable, so long as the promise is actually
followed through upon. If not, the company making that promise loses
credibility. Unfortunately, that's not always a great motivator.
Maybe the coreboot organization & SFC can enter into a contract that
specified a rough timeframe that the firmware would be open sourced.
Hopefully that would be enough of a guarantee.
It would be really great, if that could be accomplished. Though it would
be even better, if it were to happen without involving any lawyers.
Every company is in business to make money in some way. If there's
no profit to be made doing something, they're going to have a hard
time keeping their doors open. So long as they don't see a financial
benefit to being open-source, they're simply not going to do it. To
make this happen, we need more companies requesting that the chip
vendors open their proprietary blobs.
Werner also brought up the make-money argument argument later, but I
think it’s not very useful as it can be brought forward by both sides.
The Google Chromebook market is huge, and companies are going to loose
money, if they are not in it. Also companies spent a lot of resources on
integrating blobs, which does not make them any money per se.
Being more involved in the planning phase would be great, and
obviously there are companies contributing to coreboot who ARE
involved in these discussions. Expecting companies to discuss their
plans for future chips in the open probably isn't going to happen.
Sorry, this is the second misunderstanding in the discussion. After
finding the PSE change-set, people in #coreboot discovered that it was
presented at OSFC last year [1]. So it was publicly presented already.
With Nico’s proposal in place, the PSE plans would also have been
announced on the mailing list so feedback could have been gotten over a
year ago from the community. The mailing list is not perfect, but the
best option from all alternatives (conferences (not everybody there,
nothing written), Gerrit change-set (overlooked if not added as
reviewer/to Cc) or community meetings (not everybody there)).
Simply refusing to accept the binaries *only hurts us*, most
companies will be probably happy using Slimboot or TianoCore. Making
things difficult to work with coreboot only makes it easier to show
why something shouldn't be open and why the chip vendors shouldn't
work with coreboot. I cant tell you how many times I've heard that
the reason coreboot wasn't used or wasn't upstreamed was that it
takes too long to get changes into coreboot.
Again, it was never about rejecting blobs. But I also believe it
shouldn’t be made too easy. FLOSS is a give an take, and, for example
looking at time spent on reviewing also other contributions, a lot of
companies are lacking.
These things said, I think we can come up with solutions to make
things easier. Ron suggested several years ago that we could enable
Kconfig to only show the platforms with the amount of binaries that
people are comfortable with. Maybe we need to look into that more.
We can require that the soc/cpu/chipset Kconfig screens display what
blobs are required. We can push to get anything we can moved from
the blobs into coreboot. We can, and we are, pushing the vendors to
be more open-source friendly, and we're finally starting to see some
more and more people at these companies buying into this.
In my opinion, this wouldn’t help with the problem at hand. It would be
nice to have, but the benefit is small. Getting all parties involved on
the mailing list, would be much better. Again, it’s not perfect, as the
thread at hand shows, but still an improvement.
Kind regards,
Paul
[1]: https://www.zephyrproject.org/
[2]: https://cfp.osfc.io/osfc2020/talk/TNTFYV/
"Introducing open firmware development model for the Programmable
Service Engine's in Intel Atom x6000E Series"
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
