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@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