SliTaz Forum
You are not logged in.
Pages: 1
Pascal, I have seen, that you compiled microcode into the kernel, but I am not sure, if this works.
http://hg.slitaz.org/wok/rev/8861cc63f78e
what I have been reading, that this is the old method - gentoo calls it microcode-ctl and the new method they call "Early microcode" and this needs to compile the Intel Mirocode as package and then microcode initrd must be started before the kernel????
https://wiki.gentoo.org/wiki/Intel_microcode
https://www.cyberciti.biz/faq/install-update-intel-microcode-firmware-linux/
Offline
Hi there,
Downloading the Intel microcode update tarball: https://downloadmirror.intel.com/27431/eng/microcode-20180108.tgz
Extracting it.
Reading the file releasenote:
[c]Intel Processor Microcode Package for Linux
20180108 Release
-- Updates upon 20171117 release --
IVT C0 (06-3e-04:ed) 428->42a
SKL-U/Y D0 (06-4e-03:c0) ba->c2
BDW-U/Y E/F (06-3d-04:c0) 25->28
HSW-ULT Cx/Dx (06-45-01:72) 20->21
Crystalwell Cx (06-46-01:32) 17->18
BDW-H E/G (06-47-01:22) 17->1b
HSX-EX E0 (06-3f-04:80) 0f->10
SKL-H/S R0 (06-5e-03:36) ba->c2
HSW Cx/Dx (06-3c-03:32) 22->23
HSX C0 (06-3f-02:6f) 3a->3b
BDX-DE V0/V1 (06-56-02:10) 0f->14
BDX-DE V2 (06-56-03:10) 700000d->7000011
KBL-U/Y H0 (06-8e-09:c0) 62->80
KBL Y0 / CFL D0 (06-8e-0a:c0) 70->80
KBL-H/S B0 (06-9e-09:2a) 5e->80
CFL U0 (06-9e-0a:22) 70->80
CFL B0 (06-9e-0b:02) 72->80
SKX H0 (06-55-04:b7) 2000035->200003c
GLK B0 (06-7a-01:01) 1e->22
-- Microcode update instructions --
This package contains Intel microcode files in two formats:
* microcode.dat
* intel-ucode directory
microcode.dat is in a traditional text format. It is still used in some
Linux distributions. It can be updated to the system through the old microcode
update interface which is avaialble in the kernel with
CONFIG_MICROCODE_OLD_INTERFACE=y.
To update the microcode.dat to the system, one need:
1. Ensure the existence of /dev/cpu/microcode
2. Write microcode.dat to the file, e.g.
dd if=microcode.dat of=/dev/cpu/microcode bs=1M
intel-ucode dirctory contains binary microcode files named in
family-model-stepping pattern. The file is supported in most modern Linux
distributions. It's generally located in the /lib/firmware directory,
and can be updated throught the microcode reload interface.
To update the intel-ucode package to the system, one need:
1. Ensure the existence of /sys/devices/system/cpu/microcode/reload
2. Copy intel-ucode directory to /lib/firmware, overwrite the files in
/lib/firmware/intel-ucode/
3. Write the reload interface to 1 to reload the microcode files, e.g.
echo 1 > /sys/devices/system/cpu/microcode/reload[/c]
Offline
I don't know why the Archlinux and Gentoo maintainers are putting these firmware into the additional initrd.
In the order to update this one separately from the main initrd?
Why not just to follow the last method described in the release notes?
As far as I can understand:
[*]The Linux Kernel will load this firmware automatically (as well as other firmware, for example the firmware for Wi-Fi card).
[*]The last command (with "echo 1") we need only to reload the microcode firmware (when the firmware files was updated since that was loaded on the previous step).
Correct me please if I was wrong.
I'll try to make new ISO including the package with "/lib/firmware/intel-ucode/*" files and will read "dmesg" and, of course, will post there the results.
Offline
I was partially right.
TL;DR:
[*]Method with [c]/lib/firmware/intel-ucode/*[/c] works.
[*]It required "echo 1 > ..." both for load and reload the microcode.
I used the latest SliTaz Next image I have without microcode files. Kernel in the SliTaz Next is already configured in the same way like Pascal was commited here (and Pascal's commit isn't wrong). Results from the commandline:
[c]$ dmesg | grep microcode
[ 23.680263] microcode: sig=0x6fd, pf=0x80, revision=0xa1
[ 23.680423] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba[/c]
Then I added the microcode files to [c]/lib/firmware/intel-ucode/[/c] and recreated the ISO. Results from the commandline:
[c]$ dmesg | grep microcode
[ 23.814499] microcode: sig=0x6fd, pf=0x80, revision=0xa1
[ 23.814639] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba[/c]
Looks pretty the same. No microcode was updated automatically during the booting.
I checked the system have the file [c]/sys/devices/system/cpu/microcode/reload[/c] and then run the command from the root commanline:
[c]# echo 1 > /sys/devices/system/cpu/microcode/reload[/c]
Try again:
[c]$ dmesg | grep microcode
[ 23.814499] microcode: sig=0x6fd, pf=0x80, revision=0xa1
[ 23.814639] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ 142.448548] microcode: updated to revision 0xa4, date = 2010-10-02[/c]
Now the CPU has updated the microcode.
And there also the beginning of the [c]cpuinfo[/c]:
[c]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T5670 @ 1.80GHz
stepping : 13
microcode : 0xa4[/c]
So, Kernel used the file [c]/lib/firmware/intel-ucode/06-0f-0d[/c] for my CPU (based on [c]<cpu family>-<model>-<stepping>[/c] numbers in the hex format).
What's next?
I think I should add the command "echo 1 > ..." to the [c]/etc/init.d/system.sh[/c].
It should check existence of the control file [c]/sys/devices/system/cpu/microcode/reload[/c].
And I think it is better to provide Kernel commandine option like "nomc" or "nomicrocode" or even "no-microcode-update" to disable this command (echo 1 ...) execution because the system may become unstable with the latest versions of the Intel CPUs like they say here and there over the internet...
Offline
With "Early microcode" method, we could make a seperate intel iso, without commandline option ....
I dont find answers on this - I try to ask experts.....
Offline
Thomas, the kernel commandline option I plan to add - is exclusively for Intel processors.
And it is for situations when "something is goes wrong" - to disabling default behavior (while microcode is updates).
[*]An "old" microcode is in the Kernel sources tree, and then it compiled into Kernel file (because we choose "CONFIG_MICROCODE=y" option). It is loaded in the boot time by the Kernel itself, as I can understand. According to this microcode for AMD processors is the part of the linux-firmware package; we have separate updates only for Intel processors.
[*]When we activate the [c]/sys/devices/system/cpu/microcode/reload[/c] control file, Kernel checks current [c]cpuinfo[/c] and all the files in the [c]/lib/firmware/intel-ucode/[/c] folder and, if it found newer microcode for the current CPU - it will load it, as I can understand too.
The "problem" is that SliTaz don't use initrd in the "classical" way (i.e. as small place for all device drivers required at the early boot - as first example is the filesystem drivers to be able to load the rest from the HDD partitions with the different FS). SliTaz use initrd as the only container for all the files comes with the distribution.
I don't know how it work for "early boot" microcode updates as well as I don't know advantages for this method. While method I propose is good both for Live CD and installed systems: for Live CD we don't need to add yet another initrd layer (and to rewrite tazlito - who will do it?); for installed systems we don't need to add initrd, as we have no initrd at all for them.
At the same time, microcode update is executed "near" to the "early boot": in the [c]/etc/init.d/system.sh[/c].
Offline
found something
https://lwn.net/Articles/530346/
http://linuxfromscratch.org/blfs/view/svn/postlfs/firmware.html
https://www.mjmwired.net/kernel/Documentation/x86/early-microcode.txt
Offline
Pages: 1
[ Generated in 0.017 seconds, 7 queries executed - Memory usage: 1.56 MiB (Peak: 1.77 MiB) ]