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

Mike Banon mikebdp2 at gmail.com
Wed Aug 8 17:03:42 CEST 2018

It seems that now the microcode loading for AMD fam15h CPUs, including
for A10-5750M fam15h Richland CPU found at coreboot-supported Lenovo
G505S, is supposed to be done in two steps:

1) First of all it is initializing with this microcode hardcoded as
the hex values - version 0600110F [2012-01-11] :

( https://review.coreboot.org/cgit/coreboot.git/tree/src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnMicrocodePatch0600110F_Enc.c

2) Then it is being updated with a slightly newer microcode binary,
stored inside this container originally obtained from
linux-firmware.git (
) - version 6001119 [2012-07-13] :

./3rdparty/blobs/cpu/amd/family_15h/microcode_amd_fam15h.bin (

<<< although it is FAR from being the latest, the latest available is
version 600111F [2018-03-05] from platomav repository -
https://github.com/platomav/CPUMicrocodes ,
cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin - which greedy AMD did
not share with Linux users at linux-firmware.git , but was happy to
share with companies such as Lenovo and ASUS for their proprietary
UEFI/BIOS updates...)

However , all these microcode update operations are happening ONLY if
the equivalence tables are including the relevant CPU ID equivalence
lines ! For G505S's A10-5750M fam15h Richland CPU :

"1)" step is not done because this important part of awokd's change
has not been accepted (marked with >>>) :


STATIC CONST UINT16 ROMDATA CpuF15TnMicrocodeEquivalenceTable[] =
>>>  0x6131, 0x6101,
  0x6101, 0x6101,
  0x6100, 0x6100

// Unencrypted equivalent
STATIC CONST UINT16 ROMDATA CpuF15TnUnEncryptedMicrocodeEquivalenceTable[] =
>>>  0x6131, 0x6901,
  0x6101, 0x6901,
  0x6100, 0x6900

"2)" step is not done because for it to work, at
file there should be these lines at the equivalence table, lines 48-49

/* Family 15h */
{ 0x600f12, 0x6012 }, /* OR-B2 */
{ 0x600f20, 0x6020 }, /* OR-C0 */
>>> { 0x610f01, 0x6101 }, /* TN-A1 */
>>> { 0x610f31, 0x6101 }, /* RL-A1 */

( there is no typo, Trinity 0x610f01 and Richland 0x610f31 are sharing
the same microcodes )

I am planning to submit a small patch which is addressing those
problems, but before I do that I would like to hear your thoughts

Best regards,
Mike Banon

More information about the coreboot mailing list