> $ dmesg | grep -i micro
> [ 0.622441] [drm] Loading ARUBA Microcode
> [ 5.763242] [drm] Loading hainan Microcode
> [ 6.653025] microcode: CPU0: patch_level=0x06001119
> [ 6.657962] microcode: CPU1: patch_level=0x06001119
> [ 6.658890] microcode: CPU2: patch_level=0x06001119
> [ 6.659881] microcode: CPU3: patch_level=0x06001119
> [ 6.661136] microcode: Microcode Update Driver: v2.2.
I have a similar experience:
[ 0.659996] microcode: CPU0: patch_level=0x010000c8
[ 0.660001] microcode: CPU1: patch_level=0x010000c8
[ 0.660006] microcode: CPU2: patch_level=0x010000c8
[ 0.660011] microcode: CPU3: patch_level=0x010000c8
[ 0.660029] microcode: Microcode Update Driver: v2.2.
[ 7.853509] [drm] Loading RS780 Microcode
I have a 10h generation processor, and I also build in microcode_amd.bin
with the kernel.
Piledriver gets the early message barcelona/fam10h doesnt;
# dmesg | grep microc
[ 1.663099] microcode: microcode updated early to new patch_level=0x06000852
[ 1.664161] microcode: CPU0: patch_level=0x06000852
[ 1.665147] microcode: CPU1: patch_level=0x06000852
[ 1.666135] microcode: CPU2: patch_level=0x06000852
[ 1.667119] microcode: CPU3: patch_level=0x06000852
[ 1.668034] microcode: CPU4: patch_level=0x06000852
[ 1.668955] microcode: CPU5: patch_level=0x06000852
[ 1.670060] microcode: CPU6: patch_level=0x06000852
[ 1.670985] microcode: CPU7: patch_level=0x06000852
[ 1.672012] microcode: Microcode Update Driver: v2.2.
# dmesg | grep microc
[ 1.700378] microcode: CPU0: patch_level=0x010000c8
[ 1.700435] microcode: CPU1: patch_level=0x010000c8
[ 1.700488] microcode: CPU2: patch_level=0x010000c8
[ 1.700543] microcode: CPU3: patch_level=0x010000c8
[ 1.700684] microcode: Microcode Update Driver: v2.2.
microcode_amd.bin hasn't changed since at least January 2018, so maybe there hasnt been any updates for the recent CPU vulnerabilities.
Assuming the numbering is sequential its odd that the APU is at 0x06001119 but the latest from linux-firmware is only 0x010000c8. Are you sure the APU is not fam16h ?