Nico,
For our FSP implementation, I intend to rely on the FSP 2.0 EAS published
by Intel then document the important differences, which I hope is
extremely
minimal. Then there will also be a Picasso-specific Integration Guide, again similar to Intel's docs. This leaves us subject to many of the complaints in CB:36328, however I'm trying to do my best to avoid as much of that as possible -- I forwarded your RFC to my team, asked them to
read
it carefully to understand FSP customers' concerns, and told them I fully expect us to outshine Intel.
sounds great. But before you can outrun them you have to catch up. And I fear you might try to take shortcuts. I don't want to tell you how to do your job, but here is what I'd try to do (I guess an extreme): Do whatever needs to be done for the priority customers when writing code, but only start writing code for upstream coreboot when there is also public documentation about the chips. If you start earlier, you exclude too many people from collaboration. Just in case you don't know, there is not even a public datasheet to be found that would acknowledge that Ryzen, Picasso etc. are SoCs with FCH like components.
Nico, I completely agree that we're not there yet. The Picasso FSP is still a work in progress. Anyone with access to the v9 AGESA and historical knowledge of AGESA in coreboot would likely identify similar complaints in the design. Given what my team has learned from the FSP conversion, the intention to minimize FSP efforts for future designs (and potentially better flexibility in deploying AGESA in other ways), we're driving changes back into the AGESA trunk right now. This type of action had been requested of AMD for 6-8 (?) years and we're getting it done now.
Hopefully we'll exceed your expectations. If you suspect the solution will target only priority customers, then it shouldn't be very difficult. I've also personally dealt with shortcomings in the Intel FSP offerings, so I'm sensitive to the consumer's experience. I'll skip further descriptions of our sausage factory, but my team knows I'm adamant we're enabling coreboot and FSP for everyone and not some customer. I'm confident we'll encounter unforeseen gotchas along the way. For example, I recall years ago, our Embedded System customers tried to utilize a particular GPIO and we were all surprised it didn't work properly -- it turned out AGESA had co-opted it, but it was never documented anywhere. All non-Embedded designs were simply instructed not to use the GPIO. About a week ago, we discovered a CMOS location baked into the design. ...still a work in progress. However I recall similar experiences with the earlier Intel FSPs too. BTW I'll infer "here is what I'd try to do..." as "what I would be tempted to do".
Granted Google made modifications to their version of the Stoney Ridge binaryPI and corresponding changes in coreboot to support them. I really hope to get that code back and upstream the binaries so that we're all on the same page. I haven't asked for permission from the right people, or with adequate urgency, yet. BTW behind the scenes I'm also working to solve the problem we've discussed of single-sourced contractors owning the source and creation of AGESA blobs.
Regarding upstream code and documentation, as I mentioned on another thread, AMD's PPR for Picasso (i.e. the equivalent of BKDG on previous generations) was nearly nonexistent when we started. IIRC it was primarily architectural registers you could get from anywhere; hardly anything unique to Picasso except perhaps CPUID indicators. Google and I demanded from AMD that registers we would use had to be openly available. The best we could negotiate was that anything unique would be requested on a case-by-case basis and they would either be opened or denied (precluding their usage). Also, anything that was mostly identical to previous generations, e.g. in the FCH, I had an implied permission to push. The resulting public spec is as holey as you'd expect. I predict this will continue to be a challenge for a while. The PSP specs have always been NDA only, and not likely to change.
but only start writing code for upstream coreboot...
No, Picasso was always "upstream first". Until you mentioned it, I'd forgotten that Stoney Ridge had been developed "internal first", although it was eventually completely revamped. Two things come to mind for Picasso. (1) When AMD first put out the Picasso RFP, they wanted everything to be internal-only. I inferred this was partly because of NDA info and partly hopes of hiding any intentions. This is part of what I now call the "old thinking", and we helped them to see why that would be a huge mistake (for exactly the reasons everyone here would suggest). (2) The "fork" we've talked about was from August-ish; a snapshot of the WIP at coreboot.org. This was done only so that other scheduled effort could continue without waiting for the WIP to land -- that other work doesn't depend on the underlying x86 init sequence.
Thanks, Marshall
On Wed, Jan 29, 2020 at 3:58 AM Nico Huber nico.h@gmx.de wrote:
On 26.01.20 20:15, David Hendricks wrote:
On Sat, Jan 25, 2020 at 4:44 PM Nico Huber nico.h@gmx.de wrote:
we've recently seen the deprecation of Intel/Broadwell-DE support because it turned out to be too proprietary to be maintained in the long run.
To be fair, the FSP 1.0 platforms (Broadwell-DE, Baytrail, Rangeley) had a pretty long run in master. It was only when certain important coreboot features were introduced and plenty of warning that FSP 1.0 needed to be deprecated that those SoCs were deemed unmaintainable in master and moved to 4.11_branch.
Let me briefly explain why I think it wasn't deemed maintainable. There were fundamental problems with the FSP blob. Though, we could have main- tained it by either:
a) Fixing it in the source code (and releasing a new binary). b) Fixing it in the binary. c) Working around the issues in coreboot.
Due to the proprietary nature, a) could only have been done by Intel. b) is forbidden by Intel in the FSP license. c) didn't happen, I guess because people didn't try hard enough as they were promised a).
Heck, even after that platforms are still being released using that code such as the Librem Server. It's still used and maintained, just not in the master branch.
That's actually a good point, "not in the master branch". With the two new platforms that I mentioned initially (Intel/Skylake-SP, AMD/ Picasso), we (potentially, in the Picasso case) have even worse blob situations. By allowing that on the master branch, we're creating demons that guard parts of the source tree from collaboration.
IMO, we have just seen one of these creating a bottleneck that was way too frustrating for three important contributors. I think we should try to prevent such friction in the future, not by trying to work around, but by avoiding the cause.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org