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 <[email protected]> wrote: > > 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. > > > > 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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
