[Sorry for the double post; messed up threading on my first attempt. Also added offer to help test.]
Could someone familiar with the AGESA codebase please take over or rework and resubmit what I attempted to do in https://review.coreboot.org/22843? There are two problems with my version:
A) Microcode blob should go in 3rdparty/blobs and CBFS- completely agree and understand the reasoning. I found some code in AGESA that appeared to search for microcode_amd_fam15h in CBFS but when I added the module manually it still didn't seem to find it. Attempted to debug but my coding-fu was too weak. If I spent more time on it I could probably figure it out, but:
B) Real name policy- I didn't realize these were required but see now it's called out in https://www.coreboot.org/Development_Guidelines#How_to_contribute. It's my fault for missing that, but I'm unwilling to compromise my anonymity after seeing what they did to Appelbaum. Not looking to start a debate either way. I plan to continue contributing to Coreboot through email.
The key part of my proposed commit is the addition of those two lines to F15TnEquivalenceTable.c. This permits AGESA's logic to match CPU models when searching for applicable microcode updates. From there, there should be a way to fix the code so microcode_amd_fam15h is properly added and searched in CBFS, which would remove the need to update F15TnMicrocodePatch0600110F_Enc.c.
On a related note, my next commit was going to be to update 3rdparty/blobs/.../microcode_amd_fam15h.bin. Looks like the microcode in there for the 6020 processors is outdated (07/23/2014 vs. Debian distro's 01/25/2016). The updated microcode addresses a Piledriver virtualization vulnerability ( https://www.theregister.co.uk/2016/03/06/amd_microcode_6000836_fix/?page=2).
Please let me know here or via direct email if you have any questions or if I can help test!