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 <[email protected]> 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 <[email protected]> wrote: > After some research I've discovered serious problems with > "update_microcode" method: > > 1) 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 > > 2) 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 > -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
