[coreboot] AMD's binary-only AGESA libraries

[Bruce Griffith]

AMD has recently made a decision to supply AGESA as binary-only for future
AGESA releases.  This decision seems to have caused some grief and
disharmony within the coreboot community.  I would like to make a proposal
that I hope satisfies everyone moving forward.



First some history:



The initial AMD releases to coreboot were not based on either AGESA or
CIM-X.  Sometime after AMD started contributing AMD 64-bit processor
support, someone realized that core libraries were available elsewhere in
AMD to initialize the processor and chipset in a standard way (AGESA and
CIMX).   Ultimately, that turned into the AGESA and CIM-X open-source
postings in vendorcode.  AMD still develops AGESA for other (proprietary)
purposes and relicenses and forks AGESA for new processors for coreboot.



To get to an open-source AGESA, there were meetings and rules put in place
within AMD with the intent that AMD would never lose proprietary license or
ownership of the trunk AGESA or CIM-X codebases resulting from the
contribution.  The principal rules are that:



1.       No modifications derived from open-source AGESA ever go back into
AMD’s codebase.

2.       Open-source AGESA always derives from a processor-specific fork of
AGESA that is reviewed and edited to remove any proprietary code,
identifiers, or concepts.



So AMD accepted that the process of releasing into open-source would be a
very large and time-consuming task.   No matter how good the process, any
automated pruning effort will depend on authors to add tags to code to
identify what is proprietary and what is not.  Authors tend to make
mistakes and therefore require review.  So they elected to keep it a manual
process.



Jumping ahead to 2013:



AMD realized that the open-sourcing process they developed was awkward and
required lots of developer and legal involvement.  The six month delay
required to implement the “scrub” prevents AMD Embedded from capitalizing
on the advertising and press excitement following the introduction of new
parts. This delays commercial shipment of systems (and therefore chips)
until well into the design cycle of the next processor.  Anyone that
received early code was required to modify their application when the
scrubbed code was eventually released.  And they were not allowed to
release their product until after they incorporated the scrubbed code.



Please remember that AMD’s primary goal in open-source AGESA is to enable
new platforms to sell more chips.



Binary PI was conceived with the sole intent of eliminating the delay
caused by the scrub.  By donating AGESA as a binary instead of scrubbed
open-source, coreboot becomes available much sooner in the lifecycle of a
processor.  This is good for AMD and good for companies that want to use
AMD’s chips.



There are downsides:

·         The AGESA binary has to have a well-defined interface.  Normal
mechanisms to work around interface deficiencies don’t work, so you have to
work within the API.

·         Since the same BLOB is available to everyone, the API must be as
flexible as possible to accommodate varying needs.

·         Because there is no scrub, the source must remain proprietary.

·         There is less flexibility because you can’t change AGESA to
change when, where, or how initialization functions occur.

·         There may be a performance or size impact.  Binary PI currently
runs exclusively from ROM and is not split between a ROM phase and a RAM
phase.



The current binary PI implementation requires an Application Programming
Interface (API) to insulate the interface from future changes.  This is the
same AGESA API that has been open-sourced for several processor
generations.  The API uses processor-specific structures as arguments and
therefore must be compiled using header files that accompany the AGESA
library releases.  Note that this differs from an Application Binary
Interface (ABI).  I have maintained API compatibility between open-source
AGESA and binary PI.  This is for two purposes:

1.       To allow early reference platform development using an integrated
AGESA.  The code is easier to debug when it is all contained within one
binary.

2.       In the hopes that there will be future open-source AGESA
contributions from AMD late in the design cycle of a processor, well after
binary PI is released.



Proposal:



There has been a request and changelist to split the AGESA wrappers:

1.       Slowly migrating open-source AGESA away from the published AGESA
API for Llano (F12), Ontario (F14), Trinity (F15tn), Orochi (F15), and
Kabini (F16kb).

2.       Creating new wrappers for binary PI-based processors, namely Bald
Eagle (00630F01), and Steppe Eagle (00730F01).



The same wrappers, or at least wrapper structure, are shared by all of
these platforms today.  Note that the API is completely contained with the
3rdparty/pi and src/vendorcode/amd subtree.  Code in src/mainboard,
src/northbridge, src/southbridge, and src/cpu is “wrapper code” and fair
game for modification within the coreboot community.



Instead of splitting the wrappers this way, I would propose forking
open-source AGESA within the coreboot tree.  Let’s COPY the existing
vendorcode/amd/agesa into another subtree, maybe soc or devices, and rename
it OSIFA (open software interface for AMD) or something similar.  Move or
clone experimenter boards over to OSIFA.



Let’s leave commercial production boards alone (AMD, ASRock IMB-A180, some
tyan, some supermicro, some HP, maybe a few more) using the existing
src/…/agesa directories.  That leaves the interface stable for the boards
AMD needs to demonstrate, allows AMD to continue donating AGESA with their
existing interface,  yet still allows the community to improve on and
reorganize OSIFA.



What do you think … ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20141105/83c5b7b4/attachment.html>