Am 05.11.21 um 18:15 schrieb Martin Roth:
Nov 4, 2021, 05:24 by firstname.lastname@example.org:
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  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 . 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.
: https://www.zephyrproject.org/ : https://cfp.osfc.io/osfc2020/talk/TNTFYV/ "Introducing open firmware development model for the Programmable Service Engine's in Intel Atom x6000E Series"