On Sat, Mar 07, 2015 at 09:58:46AM +0100, Armin K. wrote: > On 03/07/2015 09:47 AM, Bruce Dubbs wrote: > > Armin K. wrote: > >> On 03/07/2015 05:40 AM, Bruce Dubbs wrote: > >>> Armin K. wrote: > >>> > >> > >> You don't have the ucode firmware files so it's doing nothing. If > >> the early microcode loading isn't enabled, it looks in > >> /lib/firmware/intel-ucode and it needs to be built as module. > >> If early microcode loading is enabled, it expects an initramfs > >> which contains the ucode file passed to the kernel and the driver > >> needs to be built in. Your CPU is relatively new as it seems, > >> and even if you did get the ucode firmware, I doubt it would > >> do anything. > > > > I went out to Intel and got microcode-20150121.tgz and was able to build > > the microcode.bin file from a small program I found on github. It did not > > recognize it or at least it did nothing with > > /lib/firmware/intel-ucode/microcode.bin, so I guess there are no > > corrections for it. > > > > -- Bruce > > > > > > The microcode.bin is a file that goes into the "initramfs" and is used by > early microcode loading process. > > If you want the one that goes into /lib/firmware, try an older version of > probably the same program: > > https://projects.archlinux.org/svntogit/packages.git/tree/trunk/intel-microcode2ucode.c?h=packages/intel-ucode&id=61931d62514f8426d4e267f8cd55740094eff609 > > (make sure the id stays in tact, as the latest version available in their svn > builds the microcode.bin too) >
For me, the first question is: do we need early microcode loading (for CPU microcode) ? The process looks comlicated, and I did not immediately grok everything. I'm all for keeping things simple, and I can now confirm that on intel (4.0.0-rc4) and AMD (3.18.9 - it is my server, 3.18 is now a stable tree) the microcode gets loaded when built as a module in the normal way. I take the view that these modern CPUs seem to work ok without updated firmware, so it is probably ok to load it a few seconds after booting. The following is based on http://www.linuxquestions.org/questions/linux-from-scratch-13/updating-cpu-microcode-in-lfs-4175433777/ but updated. 1. For AMD 1.1 in the kernel ensure the following settings have been made CONFIG_MICROCODE=m # CONFIG_MICROCODE_INTEL is not set CONFIG_MICROCODE_AMD=y 1.2 Take the amd-ucode firmware from linux-firmware, put it in /lib/firmware/amd-ucode/ (3 files, families 15h and 16h are separate, but hte total is only about 24K 1.3 reboot. I have three desktop AMD boxes, and one older one used as my server. For the desktops nothing changes - one is newer than the firmware, so that one is not a surprise, but the others too have nothing t gain. However, my server is an Athlon II x2 and there something is changed, dmesg | grep microcode reports: [ 4.183907] microcode: CPU0: patch_level=0x010000b6 [ 4.184271] microcode: CPU0: new patch_level=0x010000c8 [ 4.184278] microcode: CPU1: patch_level=0x010000b6 [ 4.184283] microcode: CPU1: new patch_level=0x010000c8 [ 4.184359] microcode: Microcode Update Driver: v2.00 <[email protected]>, Peter Oruba So the process is working. 2. For intel, the process is a little more complicated. The microcode_ctl package has been updated to do things the modern way, which means it will take the intel microcode and put it into a form that the kernel understands. No more, no less. Get it from: http://pkgs.fedoraproject.org/repo/pkgs/microcode_ctl When I looked a few days ago, that included 20150121 intel firmware. make && make [ DESTDIR=/some/path ] install That puts about 752K firmware into /lib/firmware/intel-ucode and if any of it gets used you can then copy the intel-ucode contents for use on any other LFS systems running on that machine (or, if you have multiple intel machines you can copy it all and apply it to all of them) - you do not need to build the program on each machine/system. On my i3 SandyBridge, dmesg | grep microcode reports: [ 0.059906] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode [ 2.603083] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x23 [ 2.669378] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x23 [ 2.669994] microcode: CPU0 updated to revision 0x29, date = 2013-06-12 [ 2.670069] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x23 [ 2.670139] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x23 [ 2.670501] microcode: CPU1 updated to revision 0x29, date = 2013-06-12 [ 2.670509] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x23 [ 2.670540] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x23 [ 2.670917] microcode: CPU2 updated to revision 0x29, date = 2013-06-12 [ 2.670955] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x23 [ 2.670988] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x23 [ 2.671348] microcode: CPU3 updated to revision 0x29, date = 2013-06-12 [ 2.671356] perf_event_intel: PEBS enabled due to microcode update [ 2.671412] microcode: Microcode Update Driver: v2.00 <[email protected]>, Peter Oruba I'm sure that I tried to load microcode in late 2013, but without success, so I guess this is an improvement. On a more general note, I'll raise a ticket for putting some notes on firmware into *LFS* as Bruce suggested, and think about how best to tackle it. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
