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