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 … ?