À propos des Firmwares

Micro-code Intel pour le processeur

La première étape est d'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 récente du micro-code est microcode-20210216. 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étail sur les blobs qui changeaient de version, mais maintenant les notes de versions contiennent ces détails.

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.

Maintenant vous devez déterminer l'identité de votre processeur, pour voir s'il y a un micro-code pour lui. Déterminez les valeurs décimales de la famille du processeur, le modèle, et le pas en lançant la commande suivante (elle rapportera aussi la vesrion actuelle du micro-code) :

head -n7 /proc/cpuinfo

Convertissez la famille du CPU, le modèle et le pas en paire de chiffres hexadécimaux. Pour un Skylake i3 6100 (décrit comme un Intel(R) Core(TM) i3-6100 CPU) les bonnes valeurs sont famille de processeur 6, modèle 94, pas 3 donc dans ce cas l'identification requise est 06-5e-03. Un coup d’œil sur les blobs montrera qu'il y en a un pour ce processeur (mais les versions plus anciennes peuvent déjà être appliquées par le BIOS). S'il y a un blob pour votre système alors testez s'il peut être appliqué en le copiant (remplacez <XX-YY-ZZ> par l'identifiant de votre machine) là où le noyau pourra le trouver :

mkdir -pv /lib/firmware/intel-ucode
cp -v intel-ucode/<XX-YY-ZZ> /lib/firmware/intel-ucode

Maintenant que le micro-code Intel a été préparé, utilisez les options suivantes quand vous configurez le noyau pour charger le microcode Intel :

General Setup --->
  [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
Processor type and features  --->
  [*] CPU microcode loading support  [CONFIG_MICROCODE]
  [*]      Intel microcode loading support [CONFIG_MICROCODE_INTEL]

Après avoir démarré avec succès votre nouveau système, forcez le chargement "au plus tard" en utilisant la commande :

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

Ensuite utilisez la commande suivante pour vérifier que tout est bien chargé (N.B. les dates de création du microcode peuvent être des mois plus tôt par rapport à leur diffusion).

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

Cet exemple reformaté pour une machine avec un ancien microcode dans son BIOS a été créé en démarrant temporairement sans les microcodes, pour montrer le message actuel de Bogue Firmware, puis le chargement au plus tard montre la révision mise à jour vers la 0xec.

[    0.000000] Linux version 5.9.8 (ken@leshp) (gcc (GCC) 10.2.0,
               GNU ld (GNU Binutils) 2.35)
               #1 SMP PREEMPT Mon Nov 16 20:42:42 GMT 2020
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.9.8-sda11 root=/dev/sda11 ro
[    0.028715] [Firmware Bug]: TSC_DEADLINE disabled due to Errata;
               please update microcode to version: 0xb2 (or later)
[    0.111874] SRBDS: Vulnerable: No microcode
[    0.111984] MDS: Vulnerable: Clear CPU buffers attempted, no microcode

Si le micro-code n'a pas été mis à jour, il n'y a pas de nouveau micro-code pour ce processeur. S'il a été mis à jour, vous pouvez maintenant faire la section intitulée la section intitulée « Chargement "tôt" du micro-code ».

Micro-code AMD pour le processeur

Commencez par télécharger un paquet de firmware pour votre famille de CPU sur http://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 et 17h ont leur propre paquet. Créez le répertoire requis et placez le firmware télécharger dedans en tant qu'utilisateur root :

mkdir -pv /lib/firmware/amd-ucode
cp -v microcode_amd* /lib/firmware/amd-ucode

Quand vous configurez le noyau, utilisez les options suivantes pour charger le micro-code AMD :

General Setup --->
  [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
Processor type and features  --->
  [*] CPU microcode loading support  [CONFIG_MICROCODE]
  [*]      AMD microcode loading support [CONFIG_MICROCODE_AMD]

Après avoir démarré avec succès votre nouveau système, forcez le chargement "au plus tard" en utilisant la commande :

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

Ensuite utilisez la commande suivante pour voir si quelque chose a été chargé :

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

Cet exemple historique d'un ancien Athlon(tm) II X2 montre qu'il a été mis à jour. Actuellement, tous les CPU sont encore signalés dans les détails du microcode sur les machines AMD (la position actuelle d'AMD pour les machines où un nouveau microcode est disponible est inconnue) :

[    0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
               #1 SMP Sun Feb 18 02:08:12 GMT 2018
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.3-sda5 root=/dev/sda5 ro
[    0.307619] microcode: CPU0: patch_level=0x010000b6
[    0.307671] microcode: CPU1: patch_level=0x010000b6
[    0.307743] microcode: Microcode Update Driver: v2.2.
[  187.928891] microcode: CPU0: new patch_level=0x010000c8
[  187.928899] microcode: CPU1: new patch_level=0x010000c8

Si le micro-code n'a pas été mis à jour, il n'y a pas de nouveau micro-code pour ce processeur. S'il a été mis à jour, vous pouvez maintenant faire la section intitulée la section intitulée « Chargement "tôt" du micro-code ».

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.13 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 /lib/firmware/amd-ucode/<MYCONTAINER> kernel/x86/microcode/AuthenticAMD.bin

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

cp -v /lib/firmware/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 comme expliqué ci-dessus. 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 ajouté, et ensuite 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 dans /sys/devices/system/cpu/vulnerabilities/ 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 (Skylake) avec le chargement au plus tôt :

[    0.000000] microcode: microcode updated early to revision 0xe2, date = 2020-07-14
[    0.000000] Linux version 5.9.8 (ken@leshp) (gcc (GCC) 10.2.0,
               GNU ld (GNU Binutils) 2.35)
               #1 SMP PREEMPT Mon Nov 16 20:42:42 GMT 2020
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.9.8-sda11 root=/dev/sda11 ro
[    0.378287] microcode: sig=0x506e3, pf=0x2, revision=0xe2
[    0.378315] 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.7.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

Il y a en fait deux façons d'installer ces firmwares. BLFS, dans le sous-chapitre 'Configuration du noyau pour les firmwares supplémentaires' du chapitre Xorg ATI Driver-19.1.0 donne un exemple de compilation des firmwares dans le noyau - c'est légèrement plus rapide à charger, mais utilises plus de mémoire pour le noyau. Ici nous utiliserons la méthode alternative en faisant un module du pilote radeon. Dans votre configuration du noyau initialisez la suite :

Device Drivers --->
  Graphics support --->
      Direct Rendering Manager --->
        [*] Direct Rendering Manager (XFree86 ... support)  [CONFIG_DRM]
      [M] ATI Radeon                                        [CONFIG_DRM_RADEON]

Le chargement de plusieurs blobs volumineux dans /lib/firmware prend un temps notable, pendant lequel l'écran est blanc. Si vous n'avez pas activé le logo framebuffer du pingouin, ou changé la taille de la console en utilisant une police plus grosse, cela n'a probablement pas d'importance. Si vous le souhaitez, vous pouvez légèrement réduire le temps si vous suivez la méthode alternative en spécifiant 'y' pour CONFIG_DRM_RADEON couvert dans BLFS au lien précédent — vous devez spécifier chaque blob radeon utile si vous faite cela.

Firmware pour les puces vidéo Nvidia

Certaines puces graphiques Nvidia requièrent une mise à jour de leur firmware pour tirer parti de toutes les capacités de la carte. Ce sont généralement les puces des séries GeForce 8, 9, 9300 et 200-900. Pour de plus amples informations, visitez https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware.

Tout d'abord, le pilote Nvidia doit être activé dans le noyau :

Device Drivers --->
  Graphics support --->
      Direct Rendering Manager --->
        <*> Direct Rendering Manager (XFree86 ... support)  [CONFIG_DRM]
      <*/M> Nouveau (NVIDIA) cards                          [CONFIG_DRM_NOUVEAU]

Les étapes pour installer le firmware Nvidia sont :

wget https://raw.github.com/imirkin/re-vp2/master/extract_firmware.py
wget http://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86-325.15.run
sh NVIDIA-Linux-x86-325.15.run --extract-only
python extract_firmware.py 
mkdir -p /lib/firmware/nouveau
cp -d nv* vuc-* /lib/firmware/nouveau/