Hi Marshall,
On 28.01.20 02:12, Marshall Dawson wrote:
That's why I always encourage people to ask for documentation instead of code. Opening code that was developed in private is a pain for both sides. However, I guess it could be taken as a good omen; that a silicon vendor won't forbid open implementations.
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.
By the way, picasso now faces some of the same challenges with AGESA that stoneyridge did. The traditional AMD mindset is/was to keep as much as possible in AGESA and there's inertia to keep that in place. For stoneyridge, we wanted as much as possible in coreboot instead, and moving some of it to coreboot was an absolute requirement. Gaining permission to port closed AGESA code to open source was not very difficult in those cases.
Thanks. Makes me hope again :)
Nico