Patrick,
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 too bad)?
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".
Nico,
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 picasso.
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.
Thanks, Marshall
On Mon, Jan 27, 2020 at 4:25 PM Nico Huber nico.h@gmx.de wrote:
Hi Marshall,
thank you very much for your huge elaboration. I had already given up all hope to see public communication from AMD. That's really great to see things change.
It's a lot to digest, I'll try to just briefly comment on my main concern, why I called it controversial: the unclear blob situation.
On 27.01.20 21:12, Marshall Dawson wrote:
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 picasso.
Actually, that's why I started _this_ thread :)
This is a long-standing complaint, and for legitimate reasons. I also get a strong sense that the industry (and I’m thinking of OCP in particular) is coming to accept blobs as a necessary downside to using modern x86 processors, but that blobs must be redistributable (and Nico,
no
ideas either on Intel’s redistribution policies or expectations). I have no knowledge on how discussions within AMD stack up against discussions within Intel, of course. I realize many of you are aware of past broken promises to reopen AGESA, the reverse engineering research done on the
PSP,
and many other things. However, there are very powerful and influential people in AMD who want both AGESA and PSP open sourced sooner vs. later. If we see the day come when this begins to happen, an inherently slow process will ensue. I think too many people assume source can simply be dumped onto github, but they don’t understand the extensive legal and
other
processes required leading up to that point.
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.
Anyway, it's clear to me that we have to accept blobs for Picasso for the time being. The question is more if these blobs will
a) be public, and b) if public, generally usable for new boards (or rather product specific).
For me (maybe for others too) this is the turning point if a platform is worth my time. If small companies and individuals can't make use of the supposedly free software, it obviously doesn't get much support from them... and neither does it before this question is answered.
Nico