[coreboot] Why do we have FSP-S

[Kyösti Mälkki]

Hi David,

I tried to stay away from commenting, but now that you pulled this red
binaryPI card from your pocket :)

On Wed, May 2, 2018 at 9:49 PM, David Hendricks
<david.hendricks at gmail.com> wrote:
>
> Bruce Griffith's e-mail about AMD's binary PI provides some great
> insights into these issues:
> https://mail.coreboot.org/pipermail/coreboot/2014-November/078892.html
>

I did not revisit that entire thread, judging by the date it was
possibly prior to binaryPI code drops. From my perspective the only
intention with binaryPI was for SAGE to gain a monopoly consulting
position on AMD based coreboot board ports, leaving them the only ones
capable of building and debugging with the blob.  I don't think any of
the advertised benefits realized and the problems with time-to-market
were not solved. I believe SAGE got the final nail on their coffin
after AMD started to lock x86 JTAG debug (aka HDT) on their new SoC's
and made SAGE EDK tool unusable.

When referring to binaryPI below, I am ruling out ongoing development
around StoneyRidge SoC. Somewhat different team, more strict quality
goals as set by ChromeOS and much more resources and review talent put
on the task now. Or so I have been told at least.

The aftermath of binaryPI (say, version 0.1) :

1. Nobody *1 can reproduce the binaryPI blob builds that were pushed
to coreboot 3rdparty repo. For most of these, I bet the source tree
revision could not be traced back either. Source repositories are
somewhere in the ruins of AMD AES and SAGE ex-personnel.

2. The needed binaryPI source is somewhat heavily patched version of a
package, which a commercial partner is (or was) able to get through
his AMD representative under an NDA and longish negotiations and
promises of significant purchase volumes. In other words, your AMD
reps cannot provide you with the source or the binary you need for use
with coreboot.

3. After the binaryPI contractor SAGE shut down and AMD AES bailed out
on coreboot (late 2015?), AMD has not granted permission to
redistribute new builds of these binaryPI blobs even if we had the
sources. And we do have the source for x86 AGESA parts, but not for
PSP.

4. Commits of updated blob builds mostly just referenced AMD internal
bugtracker ID numbers. For some cases, you cannot use the latest build
of these blobs as they break elsewhere. In other words, for best user
experience, you build the blob from the source you do not legally
have.

5. Features partially or completely known broken in pre-built blobs
(depending of SoC): ECC, HSA, IOMMU, S3 suspend, C6 boost, SPI
dual/quad, fastboot (aka MRC cache).

6. AMD ignored or refused requests to provide debug builds of said
blobs to create meaningful bootlogs on console, comparable to
open-source AGESA. Also built-in error backlog feature in non-debug
builds was initially broken, and once fixed, you still needed the
source to decipher the error.

7. Some of the PSP (aka Security Processor) firmware in 3rdparty was
modified for coreboot use. Commit message refers to which version was
submitted, but file hash does not match with one you obtained from AMD
reps. Someone with access to PSP's private key has approved the
modifications, but none of this was mentioned with the commit.

Needless to say, with all the issues above, it's hard to attract new
industrial users on coreboot when product longevity is at risk due to
uncertanities of having no firmware evaluation. After this first
attempt of going closed-source with AGESA, there is one actively
shipping product (5 board variants) from 2015. Not counting reference
designs, there are less than five other commercially ported boards in
this group from 2015-2017. AFAICS these board boot with coreboot only
inside the companies R&D, some use custom builds of binaryPI blob
while others link original (but modified) proprietary AMD source
together with coreboot proper. I understand some would rather not ship
with proprietary UEFI, but the legalities...

I feel disheartened to read similar issues arising with Intel FSP.
Uncertainity with matching header files with the blobs, lack of
distribution rights, vendor support channel providing somewhat
different FSP blob versions from what existing coreboot board ports
(Chromebooks, mostly) have been tested with. Furthermore, commits to
coreboot proper nowadays often refer to tickets in bugtracker that
require some corporate account. Even for those who do approve using
closed-sources blobs in their products, appears the entire x86
coreboot ecosystem is becoming unproductive for everyone else expect
those who do have access to FSP or AGESA sources.


As for the request on keeping conversations civil; What to do when the
vendor/contractor *just does not get it* when review comes from the
community side? Sure, they have all the pressure of shipping their
product, but phrase "We'll fix it later" is something I really learned
to hate on these corporate reviews. For open-source parts this was
often accompanied with my offer to fix it there-and-now, but I
discovered it would just mess up their workflow and cause further
rebase havoc.


*1 I am using the term nobody in the meaning of  "Not anybody you know
who answers your mails, an individual or company, who could and would
act upon an urgent need to patch said blob within a reasonable
timeframe and under a contract".

Regards,
Kyösti Mälkki