Should we add stub mainboards for new chipsets that build the code as a
way to make sure nobody else inadvertently breaks things (at least not
That's an interesting idea. A benefit that I see is that it's then demonstrable how changes and additions affect the mainboard. For example, one of the patches in my stack adds FSP support into the soc, which places requirements on the mainboard. Currently the very top mb/amd/mandolin patch simply looks like it's dropped into the directory as a rather large change, and will someday expect a reviewer to understand what the soc is doing.
Would it help to document these somewhere, e.g. as issues on ticket.coreboot.org
Both for helping you keep track of things and to state publicly what
you've postponed (so you don't have to argue every time somebody else
gets the same idea that there's something that could be deduplicated).
for a WIP SoC, seems like comments in the code/header files indicating
WIP status or need to revisit would be a consistent, visible reminder
that the code isn't "finalized"
Another good idea. My plan was to simply audit the work once Mandolin lands, i.e. do a file-file comparison with stoneyridge as that was the intended starting point. All changes should be recognizable.
For "WIP", I've been using that prior to patches landing, i.e. once I remove "WIP" I feel good about its ability to withstand review, etc. While I've not considered tying to land patches with that string present, I've definitely added some "TODO" items. But that's for something that is a "need to" vs. "would be better to". I'm not sure I have a good string in mind for the "would be better to", although occasionally I'll stick in the commit message that "future work may consider".
> Finally a word about blobs. Not that I think it belongs in the context of
> this discussion, but it seems to have been a source of bias against
Actually, that's why I started _this_ thread :)
Oh, sorry for making it all about me, then. I read Picasso in the original post, and misinterpreted the intention as purely a continuation of the CB:38221 discussion.
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. 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.
On the PSP, if forced to make a prediction, I'd bet the code would be rewritten for the purpose of open sourcing it. Regarding documenting it, however, I've been somewhat careful for several years to not move much into the public domain, as the information was coming from an NDA publication. To date, I've been trying to walk a fine line of the code/utill serving as documentation (I haven't studied the reverse-engineered info carefully, nor lately, but it's likely just as complete.) Recently our PSP team forwarded a text file for the purposes of publishing. I cleaned that up and augmented it with additional information already now publicly known. It's not been a priority to get it reviewed and landed however. That work can be found at CB:37847.
Assuming one day source becomes available for the PSP, the challenge for free software still remains of signing the blobs. It's hard to imagine that ever going away.