[coreboot] coreboot Digest, Vol 117, Issue 12

[Bruce Griffith]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20141105/d7ab6222/attachment-0001.html>