Here comes a post that is half an announcement and half a request for help to improve a situation, so please read on.
Yesterday I was finally putting the almost-finishing touches onto the new frontend system for my office (after the Italian Post screwup I was able to get the system from Alternate in a single week); one of these touches was setting up the microcode update support, which for Intel processors involves installing the
sys-apps/microcode-data packages and adding a service to the boot runlevel.
At that point my thought went to Yamato and the fact that it sounded impossible that AMD had no way to update the microcode of their CPus on Linux, especially since I know for a fact that Microsoft users get,via Windows Update, an AMD-provided CPU support update for their systems — I still do a lot of support on Windows and a number of friends and customers run AMD boxes.
Lo and behold, AMD publishes microcode updates for some of their CPUs (Family 10h and later, so starting from Barcelona, which is just what Yamato has), so I went to look into that; the results are now in
sys-kernel/amd-ucode (I wanted to use
sys-apps like the Intel microcode, but I found, late, that there was already an ebuild for it in Sunrise, and I didn’t want to have to deal with pkgmoves or blockers for out-of-tree packages). This package only installs the microcode though, so the question was to find how to load the microcode.
The documentation provided by AMD suggests to build the microcode driver as a module in the Linux kernel; when the module is loaded into the kernel, it fetches the microcode via the standard firmware loading interface of the kernel, like it’s done to wireless cards and Radeon video cards. This is pretty nifty for many reasons. Interestingly enough, it also works fine if you build the driver statically, and built the firmware blob into the kernel. Unfortunately I wasn’t able to trigger a firmware reload from the filesystem via the
/sys interface that is supposed to allow that.
And again this comes back to Intel; if the Linux kernel nowadays has a way to request the ucode file itself, why do the Intel CPUs still require us to install a binary (and a script) to load it? A quick check shows that while we do install it in
microcode.dat file is not used by the kernel at all; the reason is also easy to find if you call
less on that file: it is a text file! The microcode-ctl parses it and converts it to binary form each time the machine boots up — why at all? wouldn’t it be easier if the tool compiled it into binary form and then the init script, shipped with the data, would just output it on the device?
More interesting, the kernel does have support for requesting the microcode via the usual firmware-loading interface; but instead of looking for the generic microcode, like the AMD variant does, it looks for the specific firmware of a given CPU signature (combined family, model and stepping); the driver also has the ability to parse the generic microcode compiled from
microcode.dat, and then find the right version for the right processor.
But this means that you have to pass through a number of hoops right now at each boot, rather than doing it once at install time. Am I missing some obvious application to do the Intel microcode processing? Ideally, microcode-data would then just install the already-cut firmware, and the kernel would request the single file it needs. No need for userspace programs to process firmware further.
> it also works fine if you build the driver statically, and built the firmware blob into the kernel.No need to build the firmware blob into the kernel, it will find and load the firmware at boot-time from /lib/firmware/amd-ucode/microcode_amd.bin just fine.
That means that you can hack your microcode in the intel case and compile&run it?
My former comment is wrong.You have to build the firmware into your kernel:CONFIG_EXTRA_FIRMWARE should point to amd-ucode/microcode_amd.binand CONFIG_EXTRA_FIRMWARE_DIR to /lib/firmware
Possibly stupid question.I’ve got an Agena-core AMD part. What’s the benefit of enabling microcode updates?
Octoploid: if you feel like trying, there should be a way to force a reload of the microcode for non-module microcode support by using@echo -n 1 > /sys/devices/system/cpu/cpu0/microcode/reload@for each CPU device in that list; on the other hand I’m not sure if it works.As for the Intel counterpart; it seems like even the Intel guys don’t seem to know about the new format, split microcode, so that’s going to be funny to look at.
Hi,just a question :there are just three patches in that container. What processors are touched by those patches.10h – which is mine – Phenom 940 BE – seems not to be involved. While booting there is no message coming up. Even not that the firmware is up-to-date.Radeon firmware-update is doing so.Can i count on that and remove the update-file ?thanks for some hintskarl
I’m afraid I don’t have a changelog to propose to show what was fixed; this is all AMD seems to release, and that’s not far from what Intel does.Family 10h, 11h, and 12h are those that are provided by AMD, but I’m pretty sure previous families also had some kind of updates (as I’ve seen on previous CPUs with Microsoft Update), but they don’t seem to provide drivers or firmware files for those.
whau .. my ebuild from sunrise .. thx Flameeyes for move to main tree
@mimi.vx I’m sorry I didn’t find it on sunrise but after the fact. If there is anything that I missed, please let me know via bugzilla!
@Flameeyes see bug 329307 🙂