[coreboot] AMD's binary-only AGESA libraries

[Stefan Reinauer]

Hi,

while this was addressed at AMD, I feel compelled to add my 2ct to some
of this.

* Peter Stuge <peter at stuge.se> [141106 16:07]:
> As these contributions started to flow into the community many years
> ago, you may remember that I guessed that such rules would exist and
> asked *literally* what those rules were. You may also remember that
> there was *NO* response whatsoever.

Please keep in mind, that, even or especially in large corporations,
coreboot is until this day still driven by motivated individuals rather
than through corporate commitment. If the motivation, or the people go
away, the communication channel breaks down. I have seen this happen
dozens of times for various reasons through out the last decade and a
half.

> Unfortunately, by not communicating with the community, AMD has
> caused a significant amount of uncertanity and confusion within the
> project. Because community projects are supposed to be about
> collaboration and communication, this has placed AMD in a worse
> position than anyone wished for.
 
> Although coreboot has received contributions from AMD over a long
> time already, it is also painfully obvious that AMD still has some
> ways to go until they can get proper returns on their investment in
> coreboot.

The problem here, in my opinion, is that firmware is only one little,
important but very limited part of the whole story. Even if an
individual inside of the organization, or the firmware team as a whole,
gets it, they will still have to argue with the same amount of energy to
the other parts of the organization as they have to with the coreboot
community.

> You may understand that I, as a volunteer, can only do *so* much to
> help AMD make the most of coreboot. I believe I have asked exactly
> the right questions but without dialogue there can not be progress.
 
That pretty much applies to all members of the community. Being on the
inside of a corporation gives you a lot more information, and somewhat
more influence, but not ultimately the power to shift focus away from
the corporate issues to the community issues. Especially not quickly.

I think we are having dialogue, and Sage is putting themselves out there
to lead this dialogue. In my opinion, the fact that these mails do not
originate from an AMD email address does not constitute that we
shouldn't be open to finding a solition right now in this discussion.
Sure, we can turn the discussion away, stating that it didn't happen on
our terms. But will this help the coreboot community, or AMD?

> > AMD accepted that the process of releasing into open-source would be a
> > very large and time-consuming task.
> 
> It is obviously backwards. I wonder, if someone in those meetings
> suggested "let's make the open-source code our HEAD so that we only
> have to scrub once and worst-case only incrementally thereafter".
 
I can tell you with a high degree of certainty that nobody outside of
the core coreboot contributors considered the coreboot repository as a
possible HEAD. None of the corporate entities in this field ever has.
This is certainly something to be discussed, but there are also
downsides to this. I remember when we (some of Google's coreboot
community) decided to move ARM development to upstream first, there was
a big concern in the community. Merging community outreach into a
corporate development process is a bigger task than it seems at first,
particularly because contributors are diverse and can't necessarily
satisfy on all fronts. Like, porting coreboot to the ARM architecture
did not allow us to open up the documentation we had access to, nor
dedicate time to educating the community. In fact, most effort might
have gone into making sure that coreboot was an option at all, rather
than staying with the status quo. And after all, there was some code to
write, too.

> Major corporations like AMD are perfectly capable of contributing to
> and even running open source projects. There are many sources of
> inspiration.

I would like to know more about what you had in mind here. Maybe we, the
community, and the corporations, can learn from some of these examples.
 
> > AMD realized that the open-sourcing process they developed was awkward
> > and required lots of developer and legal involvement.
> 
> I think you understand that the community is quite frustrated since
> many attempts were made right at the start to explain that this would
> be the case. Community members with any meaningful open source
> experience immediately recognize how resource intensive the scrubbing
> process would be for AMD.
 
Unless coreboot is running on the majority of systems out there, that is
not going to change though. If we're running on more systems than
everybody else, we can dictate how that process is going to look like.
Until then, we'll have to convince and win people over.

> > The six month delay required to implement the “scrub” prevents
> > AMD Embedded from capitalizing
> 
> But ultimately this is AMD's problem and not coreboot's.
 
That's a very matter of your position. As long as they capitalize more
on non coreboot systems, we will have to argue our point. Can coreboot
prove that it provides the better ecosystem? The better environment to
create innovation? Not all of that is about capitalizing, but blaming a
corporation for being profit oriented is certainly not getting you
closer to wide spread adoption.
 
> > Please remember that AMD’s primary goal in open-source AGESA is to
> > enable new platforms to sell more chips.
> 
> Please remember that the project's primary goal is to create an open
> source firmware.

Mu personal take on this is that I would rather see coreboot run 75%
free on a billion machines out there than 100% free on 1000 machines.
Because that will ultimately leave the project in a better place of
negociating future ports and leaves the whole ecosystem with a higher
percentage of free software total.

> > By donating AGESA as a binary instead of scrubbed open-source,
> > coreboot becomes available
> 
> That's false. coreboot is an open source project. Binary PI is not
> open source, so can not be part of coreboot. If it were, coreboot's
> GPL would make a combination of the two difficult to use.

So maybe we need to find a common ground on this. In the past we have
always accepted VGA option roms. Now we move forward to open graphics.
Are we willing to sacrifice open memory initialization in order to be
able to deploy open graphics initialization? In order to deploy an open
source resource allocator? In order to create an ecosystem in which we
can move to an open source memory initialization in the long term?
Or is this a dark alley that will only lead to giving away freedom?
We, as a community, need to find a way here. If we decide we prefer to
run on older hardware that is 100% open on the firmware side, that's
something we can run with. Maybe that's where the libreboot effort comes
in and makes sure that we can make this goal a reality, while still
having another part of the community open to enabling the latest and
greatest hardware?

> > This is good for AMD and good for companies that want to use AMD’s chips.
> 
> It is however not good for coreboot, the open source firmware project.
> 
> 
> > I would propose forking open-source AGESA within the coreboot tree.
> > What do you think … ?
> 
> Let's not be in such a hurry to make changes for once, let's try to
> think this thing through?
 
Yes, I am absolutely in favor of that.

> Industry contributors appear unable to see the forest for all the trees.
> 
> I notice a trend within governments to require more transparency from
> IT equipment suppliers. It will take a couple of years, but those
> requirements will eventually bubble up also to Intel and AMD, who
> will have to either open up or lose market share. Things will
> progressively get worse for anyone who insists on remaining opaque,
> as industry starts adopting the very same requirements as the
> government.

Let's work on opening up the industry before governments get the hang of
it. While it is a great opportunity, the one thing that, in my opinion,
moves slower than corporations, is governments. No offense to any
governments listening in on this ;)

> 
> I predict that whoever opens up first has a great advantage in
> winning contracts over the next 5 years, but what do I know.

My prediction is quite similar. But there's also the part of me that
knows that if coreboot only runs on a 6+ month old piece of silicon, it
will not be adopted, and hence not be in the position to discuss the
needs of the community.

Stefan