On Fri, August 17, 2018 11:00 pm, Mike Banon wrote:
After some research I've discovered serious problems with "update_microcode" method:
That's unfortunate, but understandable. The AGESA code is convoluted. Would it be possible for someone (myself included) to copy update_microcode.c into the family15tn structure with an appropriate call to it somewhere? I'll look too.
[I have to trim your cc list to reply, sorry.]
Before borrowing update_microcode.c for our family15tn, we need to somehow figure out if its even working for that " family_10h-family_15h ". If you go to the root directory with coreboot sources, and issue ' find . -type f -print0 | xargs -0 grep "cpu_microcode_bins" ' command, you'll see that cpu_microcode_bins variable is defined ONLY for various Intel CPUs, and even one VIA CPU, but never for the AMD CPUs !
So I have no idea if this update_microcode.c for AMD has been ever tested, because there is no "cpu_microcode_bins" variable defined even for "10h/15h" family, and its essential for this update mechanism to work : if "cpu_microcode_bins" isnt defined, microcode_amd_fam15h.bin isnt included, and update_microcode.c is either never launched or gives an error
Maybe Timothy Pearson could help us with advice? Opterons belong to family15h, and Timothy is an expert when it comes to Opterons. Also, I think its' him who wrote this update_microcode.c code - src/cpu/amd/family_10h-family_15h/update_microcode.c
P.S. I just figured out how AGESA way of microcode update is working, now its' described at this change's comments - https://review.coreboot.org/c/coreboot/+/28204 [yes, my long cc list was a mistake, maybe thats why it didn't pass the mailing list moderation]
On Sat, Aug 18, 2018 at 2:49 AM, awokd awokd@danwin1210.me wrote:
On Fri, August 17, 2018 11:00 pm, Mike Banon wrote:
After some research I've discovered serious problems with "update_microcode" method:
That's unfortunate, but understandable. The AGESA code is convoluted. Would it be possible for someone (myself included) to copy update_microcode.c into the family15tn structure with an appropriate call to it somewhere? I'll look too.
[I have to trim your cc list to reply, sorry.]
On Sat, Aug 18, 2018 at 2:00 AM, Mike Banon mikebdp2@gmail.com wrote:
After some research I've discovered serious problems with "update_microcode" method:
- variable " cpu_microcode_bins " is never defined, so the code at "
./src/cpu/Makefile.inc ", recipe at line 39 - according to which " cpu_microcode_blob.bin " should be created - is not working. As result " cpu_microcode_blob.bin " is 0 bytes at CBFS :
FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none cpu_microcode_blob.bin 0x80 microcode 0 none ...
To fix it " cpu_microcode_bins " should be defined at one of the used Makefile.inc files pointing to a microcode container matching your CPU architecture, in example:
cpu_microcode_bins += 3rdparty/blobs/cpu/amd/family_15h/microcode_amd_fam15h.bin
- However, even if you would define it in such a way,
./src/cpu/amd/family_10h-family_15h/ and ./src/cpu/amd/family_10h-family_15h/agesa/family15tn/ are the separate directories, but update_microcode.c only belongs to " family_10h-family_15h " directory - no such file at " family15tn ". So, even if " microcode_amd_fam15h.bin " would be successfully added to CBFS as cpu_microcode_blob.bin, when you are compiling a coreboot ROM for Lenovo G505S (CPU of which is at family15tn) - update_microcode code will not be included and your coreboot will not know what to do with this binary file
So, currently the only working method of microcode updating for Trinity / Richland CPUs - is to edit F15TnMicrocodePatch0600110F_Enc.c in a way described earlier. As for the Equivalence Table, I've sent a new change - https://review.coreboot.org/c/coreboot/+/28204 - it adds Richland RL-A1 ( which includes our A10-5750M as well as many other Richland CPUs ) to this table
Best regards, Mike Banon
-
awokd -
Mike Banon