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]
