Missing signature at end. Does this mail reflect the opinions of You as an individual developer, SAGE or the unanimous voice of SAGE and AMD Advanced Embedded Solutions division?
I speak only for myself. I will make it plain that I am speaking for AMD if that ever happens.
The community needs to evaluate if infrastructure of said binaryPI brings any added value for coreboot, when there is no promise or a schedule for scrubbed AGESA sources.
There is no promise from AMD that there will ever be another source code release of AGESA. In fact, they have stated that there will not be one. I personally believe that there is a business case to be made to AMD for future source code releases but that has to come from AMD customers that buy AMD products in large quantities. However, I do believe that how easy the community makes it to integrate AMD's source directly impacts the ability to build a business case for future source releases.
We should drop any discussion of future source code releases since AMD is not participating in the discussion.
You have verified binaryPI uses (almost) exactly the same API as open-source AGESA so far. This complex API between AGESA component and coreboot does not fall under the mere aggregation terms of GPL, it is a form of runtime linking. In other words the distribution of binaryPI violates rights of every copyright holder in the coreboot sourcebase. I am not fond of Google's MRC binary or Intel's FSP either, but their implementation appears to be a single entry/exit with an array of platform configuration data.
For binary PI there is an open-source library file that converts from the AGESA calls that have been used by wrappers into a single entry call into binary PI. This dispatch interface has been part of AGESA since before AGESA was used by coreboot. I pushed a patch that contains the definition of the AGESA API. The spec documents how the dispatch mechanism works.
I am not a lawyer and therefore my opinion on whether binary PI meets the conditions that allow binary aggregation within GPL is not relevant. AMD believes that the binary PI mechanism meets the requirements of GPLv2.
I don't know enough about Google's implementation or Intel's implementation to compare MRC vs. FSP vs. AGESA. Most of the structures that are referenced by the AGESA API could be made opaque and the agesa/Proc headers completely eliminated. The changes in headers from version-to-version of AGESA are mostly about computing sizes for memory allocations. Based on this, I suspect that the AGESA API is actually much LESS complex than MRC or FSP.
Existing code in the tree suggests even AMD AES and SAGE were not able to implement ACPI S3 within the AGESA API for fam15tn and fam16kb, but chose to bypass the API and link directly with a couple functions in AGESA vendorcode proper.
Trinity S3 was developed immediately after CIM-X was integrated into AGESA, when the FCH additions to the API were immature. Kabini S3 is a copy of Trinity S3. I do not know of any attempts to develop coreboot S3 code through the API so I don't think you can say that it is impossible to do so. Other (non- coreboot) users of AGESA have S3 working so I am pretty sure it can be done. Don't equate a bad implementation with bad design.
Can You explain SAGE's role in all of this?
I implemented binary PI on AMD's behalf. They have asked me to push reference implementations for Steppe Eagle and Bald Eagle into the community.
Would an early release of AGESA sources affect negatively on SAGE's consultation revenue?
I have no dog in that hunt (meaning "No"). I also don't see how the question is relevant.
I assume here binaryPI is virtually impossible to debug for board bring-up. I assume binaryPI is built with all debugging output to console (aka IDS) disabled with no possibility to enable at runtime?
I debugged the initial binary PI for Steppe Eagle largely without any tools except coreboot debug spew. From what I have heard, this is pretty much the same as the story for F2A85-M development. It is difficult but not impossible. There is no possibility of enabling IDS from the public release of binary PI.
In my opinion maintaining an API involves a single set of header files ... I can see that even within the two binaryPI releases pushed to coreboot blobs.git, the header files are not the same.
You just described the difference between an API and an ABI. AGESA uses an API not an ABI. AGESA uses structures that vary between releases. The code must be recompiled to update to a newer version. An Application Binary Interface does not have that restriction.
In the spirit of AGESA API, platform specifics would belong to BiosCallOuts and no board-specific agesawrapper.c file should have ever existed. But since board-specific agesawrapper.c files did exists, someone though it was okay to modify those nevertheless.
The wrappers in agesawrapper.c are EXACTLY where mainboard specific customizations belong. Read the AGESA API spec. It is how runtime variation between platforms was designed to be implemented.
However, there is a lot of boiler-plate code in agesawrapper.c. I would like to see new callouts created for each of the approx 9 AGESA stages and the boiler-plate code made the same for ALL AGESA-based code. In other words, move agesawrapper.c somewhere like src/northbridge. Split agesawrapper.c into a romstage component, a ramstage component, and an S3 component. Expand processor and platform specific OEM customization routines to each of the AGESA stages. This would accommodate platform-to- platform variation by customizing the OEM routine (i.e. this would allow change from SATA combined mode to pure AHCI or RAID, disable USB ports, etc.).
You are effectively saying that you do not want any of the improvements that coreboot has gained from Chromebook development, to be available on AMD reference designs? Is this the opinion of You as an individual, the opinion of SAGE or that of the AMD Advanced Embedded Solutions division?
I am speaking for me, but I very much believe that I am accurately reflecting what AMD would want.
I am not in any way saying I don't want the contributions that you are implying you intend to make. I want them very much. But you are specifically excluding these improvements for binary PI based designs. I am stating that all of AMD's stuff should stay on one side of this fence that you are proposing. Since you are excluding binary PI from getting the "Chromebook development" changes, I guess that means the rest of AMD's platforms are excluded, too.
To think further, understand that a requirement to use a common agesawrapper.c file across fam12-fam16kb is for the vendorcode to actually expose a common API. A common API does not involve forking the header files for each family separately. The community has the possibility to unify the function prototypes within the different families of open- source AGESA API, should we find any.
I don't know of any relevant function prototypes that have changed in the AGESA API since 2008. Any change in the function prototypes used by coreboot would have broken the dispatcher and that's not permissible under the Arch 2008 spec. If you are referring to callbacks, those also have a single fixed function signature. The usage of the signature may have changed from version to version but that was poor implementation (i.e. bugs).
The AMD library is still completely open-sourced with binary PI.
There are no AGESA header file changes that are relevant to coreboot in general. coreboot needs them to compile but it uses very few fields defined by them. You could replace most of the structs with an array of bytes of known length. The code would not function differently. The downside is that coreboot would lose some of its ability to control runtime option selection within AGESA (that largely is not used by current coreboot code).
What is the issue that we are trying to solve by harmonizing and #ifdef'ing the *actual* AGESA header files currently located in src/vendorcode and 3rdparty/pi/amd?
------------------------
AMD is trying to run a business. They are contributing code to coreboot to enable their next-gen processors. Aside from the fact that you do not like that AMD has stopped open-sourcing AGESA, what problem are we trying to solve in this discussion?
My objective is to get Steppe Eagle and Bald Eagle processors released, as quickly as possible, into coreboot. I really do not have much of a personal agenda beyond that.
Respectfully, Bruce Griffith
-
Bruce Griffith