I'd like to get back to a rating system. There's a really simple measure that I've never seen improved upon, namely, for a given firmware image, what fraction of the bits in that image come from open source code?
e.g., the KGPE-D16 would get a 100%, and a typical laptop would get 0%.
This is a really easy number to compute, automatically, and might even be an option to cbfstool or a ROM tool.
Marketing types are sensitive to numbers like this: we could prominently display these numbers on coreboot.org
ron
On Fri, Nov 5, 2021 at 10:16 AM Martin Roth via coreboot coreboot@coreboot.org wrote:
Nov 4, 2021, 05:24 by pmenzel@molgen.mpg.de:
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.
Kind regards, Paul
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.
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. 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.
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.
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.
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.
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.
Martin
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org