À propos des Firmwares

head -n7 /proc/cpuinfo

Micro-code Intel pour le processeur

La première étape consiste à obtenir la version la plus récente du microcode d'Intel. Vous devez pour cela aller sur https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/ et télécharger le fichier le plus récent. Au moment de l'écriture de ces lignes la version la plus sure du micro-code est microcode-20230808. Extrayez ce fichier normalement, le microcode se trouve dans le répertoire intel-ucode qui contient les divers blobs avec des noms de la forme XX-YY-ZZ. Il y a aussi d'autres fichiers divers et un fichier releasenote.

Par le passé, Intel ne fournissait aucun détails sur les blobs dont la version changeait, mais maintenant les releasenote en parlent. Vous pouvez comparer la version du microcode dans /proc/cpuinfo avec la version pour votre modèle de CPU dans les releasenote pour savoir s'il y a une mise à jour.

Le firmware récent pour les processeurs les plus anciens est fournit pour traiter des vulnérabilités qui ont été rendue publiques, et pour certains d'entre eux comme le Microarchitectural Data Sampling (MDS) vous pourriez vouloir augmenter la protection en désactivant l'hyperthreading ou en désactivant les contournements par défaut du noyau à cause de son impact sur les temps de compilation. Lisez bien la documentation en ligne sur https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html.

Pour un mobile Tigerlake (décrit comme Intel(R) Core(TM) i5-1300H CPU) les valeurs utiles sont famille CPU 6, modèle 140, pas 1, donc dans ce cas l'identifiant requis est 06-8c-01. Les releasenote disent que le dernier microcode pour ce CPU est la version 0xac. Si la valeur du champ « microcode » dans /proc/cpuinfo est 0xac ou plus, cela signifie que la mise à jour du microcode est déjà appliquée par le BIOS. Sinon, configurez le noyau pour prendre en charge le chargement du microcode Intel puis consultez la section intitulée « Chargement "tôt" du micro-code ».

General setup --->
  [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support
                                                           ...  [BLK_DEV_INITRD]

Processor type and features --->
  [*] CPU microcode loading support                                  [MICROCODE]
  [*]   Intel microcode loading support                        [MICROCODE_INTEL]

Micro-code AMD pour le processeur

Commencez par télécharger un paquet de firmware pour votre famille de CPU sur https://anduin.linuxfromscratch.org/BLFS/linux-firmware/amd-ucode/. La famille est toujours spécifiée en hexadécimal. Les familles 10h à 14h (16 à 20) sont dans microcode_amd.bin. Les familles 15h, 16h, 17h (Zen, Zen+, Zen2) et 19h (Zen3) ont leur propre conteneur. Seules quelques machines sont susceptibles de recevoir une mise à jour du microcode. Au lieu de cela, AMD fournit un AGESA à jour aux constructeurs de cartes mères qui peuvent l'utiliser pour proposer une mise à jour du BIOS. Il y a un script Python3 sur https://github.com/AMDESE/amd_ucode_info/blob/master/amd_ucode_info.py. Téléchargez ce script et lancez-le avec le fichier binaire pour vérifier si vos processeurs ont une mise à jour.

Pour le très vieil Athlon(tm) II X2 de ces exemples, les valeurs étaient famille CPU 16, modèle 5, pas 3, ce qui donne un identifiant Family=0x10 Model=0x05 Stepping=0x03. Une ligne de la sortie du script amd_ucode_info.py décrit la version du microcode pour ce CPU :

Family=0x10 Model=0x05 Stepping=0x03: Patch=0x010000c8 Length=960 bytes

Si la valeur du champ « microcode » dans /proc/cpuinfo est 0x10000c8 ou plus, cela signifie que le BIOS a déjà appliqué la mise à jour du microcode. Sinon, configurez le noyau pour prendre en charge le chargement du microcode AMD puis consultez la section intitulée « Chargement "tôt" du micro-code » :

General setup --->
  [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support
                                                           ...  [BLK_DEV_INITRD]

Processor type and features --->
  [*] CPU microcode loading support                                  [MICROCODE]
  [*]   AMD microcode loading support                            [MICROCODE_AMD]

Chargement "tôt" du micro-code

Si vous avez établi qu'un micro-code mis à jour est disponible pour votre système, il est temps de le préparer pour un chargement "tôt". Cela demande un paquet supplémentaire, cpio-2.14 et la création d'un initrd qui devra être ajouté à grub.cfg.

L'endroit ou vous préparez l'initrd n'est pas important, et une fois fonctionnel vous pouvez appliquer le même initrd aux versions futures de LFS ou aux nouveaux noyaux sur cette même machine, au moins jusqu'à ce qu'une nouvelle version du micro-code soit publiée. Utiliser la suite :

mkdir -p initrd/kernel/x86/microcode
cd initrd

Pour une machine AMD, utilisez la commande suivante (remplacez <MYCONTAINER> par le nom du paquet de votre famille de CPU) :

cp -v ../<MYCONTAINER> kernel/x86/microcode/AuthenticAMD.bin

Ou pour une machine Intel copiez le blob approprié en utilisant cette commande :

cp -v ../intel-ucode/<XX-YY-ZZ> kernel/x86/microcode/GenuineIntel.bin

Maintenant préparez l'initrd :

find . | cpio -o -H newc > /boot/microcode.img

Vous devrez également ajouter une nouvelle entrée à /boot/grub/grub.cfg et vous devrez ajouter une ligne après la ligne linux entre les apostrophes. Si /boot est dans une partition séparée :

initrd /microcode.img

ou sinon :

initrd /boot/microcode.img

Si vous avez déjà démarré avec un initrd (voir la section intitulée « À propos de initramfs ») vous deviez de nouveau lancer mkinitramfs après avoir placé le blob ou le conteneur approprié dans /lib/firmware. Plus précisément, placez le blob Intel dans le répertoire /lib/firmware/intel-ucode ou le conteneur AMD dans /lib/firmware/amd-ucode avant d'exécuter mkinitramfs. Autrement, vous pouvez avoir les deux initrd sur la même ligne, comme dans initrd /microcode.img /other-initrd.img (adaptez comme ci-dessus si /boot n'est pas dans une partition séparée).

Vous pouvez maintenant redémarrer avec l'initrd supplémentaire, puis utiliser la même commande pour vérifier que le chargement « au plus tôt » a fonctionné.

dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'

Si vous avez mis à jour pour corriger des vulnérabilités, vous pouvez regarder la sortie de la commande lscpu pour voir ce qu'il rapporte maintenant.

Les endroits et les moments où le chargement au plus tôt se passent sont très différents entre les machines AMD et Intel. En premier, un exemple d'Intel (mobile Tigerlake) avec le chargement au plus tôt :

[    0.000000] microcode: microcode updated early: 0x86 -> 0xac, date = 2023-02-27
[    0.000000] Linux version 6.4.7 (root@stargazer) (gcc (GCC) 13.2.0, GNU ld (GNU Binutils) 2.41) #1 SMP PREEMPT_DYNAMIC Wed Aug  2 19:08:46 CST 2023
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.4.7 root=PARTUUID=<CLASSIFIED> ro
[    0.424002] microcode: Microcode Update Driver: v2.2.

Un exemple historique pour AMD :

[    0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
               #2 SMP Sun Feb 18 02:32:03 GMT 2018
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.3-sda5 root=/dev/sda5 ro
[    0.307619] microcode: microcode updated early to new patch_level=0x010000c8
[    0.307678] microcode: CPU0: patch_level=0x010000c8
[    0.307723] microcode: CPU1: patch_level=0x010000c8
[    0.307795] microcode: Microcode Update Driver: v2.2.

Firmware pour les puces vidéo ATI (R600 et plus)

Ces instructions NE s'appliquent PAS aux anciennes radeons avant la famille R600. Pour elles, le firmware est dans le répertoire du noyau /lib/firmware/. Appliquez-les seulement si vous prévoyez d'éviter une configuration graphique tels que Xorg et que vous voulez vous contenter d'utiliser l'affichage 80x25 par défaut plutôt qu'un framebuffer.

Les périphériques radeon plus anciens demandaient seulement un simple blob de 2 Ko. Les périphériques récents ont besoin de plusieurs blobs différents, et certains d'entre eux sont bien plus gros. La taille totale du répertoire des firmwares radeon est de plus de 500 Ko — sur un gros système moderne vous pouvez probablement utiliser cet espace, mais cela reste redondant d'installer tous les fichiers inutiles chaque fois que vous construisez un système.

Une meilleure approche est d'installerpciutils-3.10.0 et ensuite utiliser lspci pour identifier quel controleur VGA est installé.

Avec cette information, vérifiez la page RadeonFeature du wiki Xorg Decoder ring for engineering vs marketing names pour identifier la famille (vous aurez besoin de savoir cela pour identifier le pilote Xorg dans BLFS — Southern Islands et Sea Islands utilise le pilote radeonsi) et le modèle spécifique.

Maintenant que vous savez quel contrôleur vous allez utiliser, consultez la page Radeon du wiki de Gentoo qui a un tableau listant les blobs de firmware requis pour les différentes puces. Notez que les puces Southern Islands et Sea Islands utilisent des firmwares différents pour les noyaux 3.17 et supérieur par rapport aux noyaux antérieurs. Identifiez et téléchargez les blobs requis et ensuite installez les :

mkdir -pv /lib/firmware/radeon
cp -v <YOUR_BLOBS> /lib/firmware/radeon

Construire le pilote amdgpu du noyau en tant que module est recommandé car les fichiers du micrologiciel doivent être accessibles au moment du chargement. Si vous le construisez dans l'image du noyau pour quelque raison que ce soit, vous devez inclure les fichiers du micrologiciel dans l'initramfs (consultez la section intitulée « À propos de initramfs » pour les détails) ou les inclure dans l'image du noyau directement (consultez la section intitulée « Inclure les blobs des micrologiciels dans l'image du noyau » pour les détails).

Firmware pour les puces vidéo amdgp AMD/ATI

Tous les controlleurs vidéo qui utilisent le pilote amdgpu du noyau ont besoin d'un firmware, que vous utilisiez le pilote amdgpu de xorg, le pilote modesetting de xserver, ou juste de modesetting du noyau pour avoir un framebuffer de console plus grand que 80x25.

Installez pciutils-3.10.0 et utilisez-le pour vérifier le nom du modèle (cherchez « VGA compatible controller: »). Si vous ave un APU (unité de traitement accélérée, c'est-à-dire le CPU et la carte vidéo sur la même puce), cela vous en dira sans doute le nom. Si vous avez une carte vidéo amdgpu séparée vous devrez chercher pour déterminer le nom qu'elle utilise (p. ex. une carte décrite comme Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] a besoin du pilote Polaris11). Il y a une table de correspondance « Famille, nom de puce, nom de produit et firmware » à la fin des sections du noyau sur la page AMDGPU du wiki de Gentoo.

Une fois que vous avez identifié le nom du firmware, installez tous les fichiers utiles. Par exemple, la carte Baffin mentionnée plus tôt a 21 fichiers polaris11* différents, les APU comme renoir et picasso ont au moins 12 fichiers et pourront en avoir plus dans les mises à jour futures (p. ex. l'APU raven a maintenant un 13ème fichier, raven_ta.bin).

mkdir -pv /lib/firmware/amdgpu
cp -v <YOUR_BLOBS> /lib/firmware/amdgpu

Si l'espace disque n'est pas un problème, vous pouvez installer tous les fichiers de firmware actuel sans vous soucier de savoir quelle puce est installée.

Construire le pilote amdgpu du noyau en tant que module est recommandé car les fichiers du micrologiciel doivent être accessibles au moment du chargement. Si vous le construisez dans l'image du noyau pour quelque raison que ce soit, vous devez inclure les fichiers du micrologiciel dans l'initramfs (consultez la section intitulée « À propos de initramfs » pour les détails) ou les inclure dans l'image du noyau directement (consultez la section intitulée « Inclure les blobs des micrologiciels dans l'image du noyau » pour les détails).

Firmware pour les puces vidéo Nvidia

Nvidia a publié des firmware de base signés pour les puces graphiques récentes, mais bien après que les puces et ses propres pilotes binaires ne soient disponibles. Pour les autres puces il était nécessaire d'extraire le firmware du pilote binaire.

Pour des informations précises sur les puces qui ont besoin d'un firmware extrait, voir https://nouveau.freedesktop.org/VideoAcceleration.html.

Si le firmware requis est disponible dans le répertoire nvidia/ de linux-firmware, copiez-le dans /lib/firmware/nouveau.

Si le firmware n'a pas été mis à disposition dans linux-firmware, pour les anciennes puces mentionnées dans le lien vers le wiki de nouveau ci-dessus, exécutez les commandes suivantes :

wget https://anduin.linuxfromscratch.org/BLFS/nvidia-firmware/extract_firmware.py
wget https://us.download.nvidia.com/XFree86/Linux-x86/340.32/NVIDIA-Linux-x86-340.32.run
sh NVIDIA-Linux-x86-340.32.run --extract-only
python3 extract_firmware.py
mkdir -p /lib/firmware/nouveau
cp -d nv* vuc-* /lib/firmware/nouveau/