Firmware: loading CPU microcode is now less verbose.

[ken@…]

Over time, everything changes. In this case, the examples I originally produced were circa the 4.0 kernel and for early loading gave details for each core. By 4.9 the details are less verbose.

Noted on intel early loading, but I'm sure the examples for AMD, and for late loading, have also changed.

Note to self - do this on 4.9, 4.10 has a later version of the kernel driver (v2.2 instead of v2.01), which doesn't report the authorship.

[ken@…]

Boy, this is fun :-(

I've been using early-loading for, by the look of it, three years -and, at least on intel, I couldn't replicate the late loading - couldn't persuade it that the blob was usable if I added it to the config. I've now managed that, using

echo 1 >/sys/devices/system/cpu/microcode/reload

Which produced the following in dmesg on my haswell, last line from the update:

[    0.918307] microcode: sig=0x306c3, pf=0x2, revision=0x19
[    0.918573] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[  299.984356] microcode: updated to revision 0x20, date = 2016-03-16

Need to look at my AMD machines

[bdubbs@…]

Interesting. I did th eecho and only got one line:

microcode: updated to revision 0x39, date = 2016-10-07

My system is a Haswell also: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz

[ken@…]

Replying to bdubbs@…:

Interesting. I did th eecho and only got one line:

microcode: updated to revision 0x39, date = 2016-10-07

My system is a Haswell also: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz

Yes, only one line from the update. Maybe the message from booting had already rolled out of your dmesg buffer.

[ken@…]

For AMD I'm having to use the same approach, but there it does still report both CPUs! I think the late-loading approach is pretty-much deprecated. Also, I noticed that intel update microcode fairly frequently for (some) recent CPUs, AMD much less often.

I now think we should mention that microcode updates for AMD machines are not common.

But more to the point: since we have to rebuild the kernel anyway, even for late loading, I think we should use the early-loading config even for initial late loading to test if there is an update. For late loading, put the firmware in the specified place in /lib/firmware.

After booting, do the echo and grep dmesg to see if anything changed. If so, goto early-loading.

[bdubbs@…]

From the messages I've seen, this seems like the right way to go.

I guess the way commercial distros do it is to put all the firmware blobs in the initrd.

I notice that CONFIG_MICROCODE_EARLY does not exist any more.

[ken@…]

Provisionally done at r18488 - it looks good to me, but that doesn't mean I've avoided all inconsistencies in it.

In the future, I would like to think about putting ALL the firmware into the initrd and dropping the late loading - I suspect that option will disappear. But for the moment I think this matches what happens in 4.9 kernels.

[bdubbs@…]

One typo (fixed) but it looks good to me. One thing we might mention is that there can be more than one entry on the initrd line of the grub entry.

initrd /microcode.img /other-initrd.img

[ken@…]

Replying to bdubbs@…:

One typo (fixed) but it looks good to me. One thing we might mention is that there can be more than one entry on the initrd line of the grub entry.

initrd /microcode.img /other-initrd.img

I've added that at r18496. The examples in initramfs have "rather old" names, so I kept your name of /other-initrd.img.

[bdubbs@…]

Milestone renamed

[bdubbs@…]

Milestone renamed