On 05.11.21 18:15, Martin Roth via coreboot wrote: > Nov 4, 2021, 05:24 by pmen...@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.
Not sure what you are trying to say. Do you mean we shouldn't talk about the way blobs are added because they are needed anyway? Blobs are needed anyway so we won't review code around them any more? > I don't think we're going to refuse a platform right now simply because it > has blobs. Nobody brought that up. What are you referring to? > 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. That's a very hypothetical, IMO wrong statement. "definitely" is a very strong word there. Also, what's a "required blob" anyway? Most of the blobs in coreboot are not required but politically desired. As an ex- perienced coreboot developer who has written fully open-source platform support in the past, I would expect this to have happened: We'd have less ARM platforms in the tree because those were added for Chromebooks with little interest from other folks. On the x86 end, we'd be behind about a year compared to the support we have today, as other companies who rely less on the silicon vendor's blessing might have done the job. The community would look much different. Instead of many developers struggling to bring blobs up, we'd have less but much better experienced developers who still understand the hardware. Of course we'll never know which scenario would have been more likely. But it's been almost ten years, a lot could have happened. Imagine coreboot would have been FSP free, maybe even AMD would have been more open to a free software solution. FWIW, FSP encourages a lot of people to put more and more code into blobs. IMO we are stuck in a corner, and you want us to stay there as calm as possible. > > 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. You know that the PSE is an Intel thing and still talk about credibility? Do you have any idea what is going on around their blobs? There are even claims in our documentation today that can't be explained and look like very weak excuses for the simple fact: The blob interface was done like this because Intel wanted it and all promises were only made to get the patch in. That Intel lost its credibility on the matter is one reason why it is hard to get things like the PSE support added. I think we need a better process so the developers tasked with such things don't suffer. And they should never be in a position that needs them to make promises. Individuals can't make promises on behalf of a huge company, that would be gambling, IMO, and we would never get an official, written promise anyway. So please forget about promises. > 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 not sure why you bring that up? I started a thread to make things easier. Why do you want to make it harder? Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
