[coreboot] Why do we have FSP-S

[David Hendricks]

Hi Kyösti,
That's a great post-mortem, thanks for writing it up!

I didn't mean to imply that binary PI is a great example of how to do
things, I just think Bruce's explanation is useful for answering
Ivan's question of why companies don't simply open their code. As you
point out binary blobs aren't a magic bullet and can end up a
bitrotting mess with no salvageable value for other potential
customers.

Intel's done a better job with FSP so far, hopefully we can convince
them that opening it up will add significant value for them by
enabling more customers and  more products. On that note, a shameless
plug: http://www.opencompute.org/projects/open-system-firmware/

On Thu, May 3, 2018 at 1:37 AM, Kyösti Mälkki <kyosti.malkki at gmail.com> wrote:
> 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