[coreboot] [AMD/fam15h] coreboots update_microcode is NOT working, and I know why

[Mike Banon]

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 at 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 at gmail.com> 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
>