Michał Żygowski has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/29272 )
Change subject: src/cpu/amd/pi/00730F01: Add microcode update infrastructure for fam16h PI ......................................................................
Patch Set 2:
Patch Set 2:
Michal, please read my comment here about the shortcomings of this "microcode update infrastructure" - https://review.coreboot.org/c/coreboot/+/28273/6#message-cbbdcce72362a39ad3e... (and why I didn't want to port it for some other AMD boards). Is your implementation affected by these shortcomings as well?
1) The older microcode is embedded into AGESA. I have researched the possibilities to tell AGESA to load custom microcode, but haven't found any ways to do so. Basically there is a blob with old microcode we have to use within the AGESA and a microcode blob we can add as CBFS file to have newer version patched (about 3.5KB large container). 2) As mentioned before, cannot load the microcode in romstage because AGESA does not expose anything that would let us patch the microcode. I did so in my previous patches, however, I have faced another wall - AGESA is forcefully patching microcode regardless of the current patch level. That said, AGESA will overwrite the microcode despite the current patch level is higher.
AFAIK the microcode container for fam 16h does not have 3 microcode blobs inside, it doesn't make it that huge as in mentioned in the link above. 3.5KB is a very small patch comparing to Intel I guess. IMO it is better to patch it a little bit later in BIOS than force users to patch it on OS level. I understand the shortcomings and Your reasoning.
There are still some things to consider: 1. Is it better to just abandon the patch? Or should we have it in the tree? Advantages are that the infrastructure is ready and anyone can patch the microcode freely; and secondly we have documentation/source code explaining how the microcode patches/containers look like (there are differences between fam16h and previous families). 2. Leverage the newest AGESA blob for fam16h. The reason I have prepared this patch is that PC Engines apu2 cannot use the newest AGESA 1.0.0.A blobs, due too reset loop it causes. These platforms are tied to used older 1.0.0.4 blob which is the last known good binary. Unfortunately, 1.0.0.4 has older microcode whereas 1.0.0.A has the newest one which I would like to have in coreboot as a separate patch. We may treat it as a temporary solution until I find a way/workaround to get the recent AGESA blob working.