On 07.11.21 00:11, Martin Roth wrote:
Nov 6, 2021, 05:21 by nico.h@gmx.de:
On 05.11.21 18:15, Martin Roth via coreboot 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.
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?
Not at all, you can talk all you want. But what's the outcome you're looking for?
Awareness and knowledge within the community.
Do it the coreboot way, or.... or what?
Well that would be a bonus and I think talking about things early might at least give us a chance to achieve something. When new kinds of blobs are discussed last minute, their next iterations for the next chips are most likely already set in stone by other teams at the silicon vendor. If we discuss things late, we can never change a thing.
Or we won't accept code to load those blobs?
I think there are limits. For instance if a blob would be called from ramstage, never to return, and would even load the payload. Should we accept infrastructure for such a thing? I think no. But that's inde- pendent from my original proposal, because it shouldn't matter in such a case if we discuss it early or late ;)
You won't accept ANY of the code for the platform?
In an unlikely, hypothetical case as described above, yes. Would you?
Is there a different end point if they don't do what you want?
Sorry, when did I ever bring in what I want? Does talking about some- thing imply to you that always someone tries to enforce their will on somebody else?
Talking about things can bring people together. I hope even in a community that is divided such as ours. Adding new blob infrastructure in a hurry does not bring people together. All I wanted is to talk about better ways to do it.
To me, your statement below *VERY* much sounds like refusing a platform. Maybe you could explain what it actually means. I read it as "A vendor can't commit a new platform until the coreboot project is happy with the blob situation for the platform".
Oct 20, 2021, 06:24 by nico.h@gmx.de: 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.
It's not a statement, it was a proposal. And I wanted to discuss that in the other thread, but you make it very hard.
I meant it literally. A set of questions should be answered. That's all. And I actually went on and said that it should be blocked "If there's some downside that definitely outweighs the benefit [...]". That should imply that without such a heavy downside, people can go on.
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?
See your above statement. If you'd said "at the start of a new project, we'd like to get the vendor to let us know what the blob situation looks like", sure. But the way it was phrased of "Before the first commit can be merged" says to me that you don't want to allow the platform to even get started in coreboot until you (or someone) is satisfied by the blob situation for the new platform. It's not like that discussion is going to be quick either. Blobs are ALWAYS contentious, which I'm fine with. I'm just not fine with blocking the progress of people who are trying to do their best to get their work done simply because we don't like blobs.
Well, it should matter more what it says and not what it says to you. Please, please don't interpret something into it that wasn't written.
I wrote nothing about any satisfactory requirements. Beside that it shouldn't be a definite downfall.
My reason to say "before the first commit can be merged" was to make sure that it's not forgotten to answer the questions or even attempted to skip the discussion. New platforms are often added by inexperienced people who don't see the value in an early dis- cussion because they don't know what shitstorm they have to expect when they skip it.
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.
Just because it didn't happen doesn't mean it's simply hypothetical. ChromeOS pushing to not use the FSP didn't make intel reconsider it. AMD introduced the binary PI because they no longer had the resources to support open sourcing it. I'm sure what would have happened, and so is Patrick, when he said that coreboot would be gone if we had refused blobs.
You say Intel and AMD. You seem to forget that the best native implementations in coreboot were not written by them. Yes, Intel and AMD wouldn't have opened up their code, sure. But that might be better. It would imply higher code quality and better under- standing of the hardware in the community.
You make it sound like people outside of these companies don't want to write code for their chips. I've seen some tendency by companies to expect the silicon vendors to write the code. Would you say that this reflects the opinion of individuals in the community? I have witnessed the opposite.
And I think it's very presumptuous of you to assume that you know what it is that I want. "unfortunate reality that allowing these blobs is a requirement" and the part that you removed from the end of my email in your response where I talk about the work that's being done to try to get vendors to open their codebases, are *NOT* me saying that I want you to stay stuck in the corner with all the blobs, let alone being calm.
Well, even with the mail I'm responding to right now you have questioned the value to discuss blob matters early. It makes me believe that you don't want people to discuss these matters, hence my "stay [..] calm".
I'm actually working with vendors to get them to open their code, and have been doing so for a LONG time, thank you very much.
It's nice that you are doing this. And I know you mentioned earlier that you need more companies asking for it. But how is that going to happen if we don't keep discussing things in public?
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?
And I talked about ways to try to make them follow through on their promises.
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.
sorry, let me repeat this from my last email, maybe you missed it: 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.
That would be quite awesome. But it's a huge "maybe". I ignored it because I don't believe in fairy tales. Or more accurately, my ex- perience with Intel has completely disillusioned myself. Even if they signed such a contract I would only believe it the day that they actually publish something. And until that day I'd have to act as if they hadn't signed such contract. The history of Intel blobs is a history of broken promises, I will never again hope for anything in that direction.
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?
CB:55367 was pushed on June 9th. It's 5 months later. Intel hasn't been able to get it merged yet. Sure, we're not outright saying they can't get it in, but in effect, that's what's happening.
Yes, 5 months stalled, because nobody told them that we should discuss it. Hence my proposal to discuss things early. You don't like it? Please propose something better.
Do you disagree? Do you think that this is easy for the developers who are told by intel to get the patches merged? The coreboot project is difficult to work with. That's just the truth, whether you see it or not. I'm not making it any harder by having this discussion with you.
No, you are not making it harder. But you derailed my attempt to discuss to make it better.
Nico