Sur certains PCs actuels il peut être nécessaire, ou désirable, de
charger des firmwares pour faire travailler les PC au maximum de
leurs possibilités. Le noyau contient un répertoire, /lib/firmware
, ou le noyau ou les pilotes du noyau
cherche des images de firmware.
Préparer des firmwares pour de multiples machines différente, comme les distributions le font, est en dehors du périmètre de ce livre.
Actuellement, on peut trouver la plupart des firmwares sur un dépot
git
:
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/.
Par commodité, le projet LFS a créé un miroir, mis à jour
quotidiennement, ou on peut accéder à ces fichiers de firmwares via
wget
ou un navigateur
web à http://anduin.linuxfromscratch.org/BLFS/linux-firmware/.
Pour avoir le microprogramme, vous devez soit aller sur un des dépôts
ci-dessus avec un navigateur pour télécharger le(s) fichier(s) dont
vous avez besoin, soit installer git
et cloner ce dépôt.
Pour certains autres firmwares, particulièrement pour les micro-codes d'Intel, et certains périphériques wi-fi, le firmware recherché n'est pas disponible dans le dépôt précédent. Certains d'entre eux seront ajouté ensuite, mais il est parfois nécessaire de faire une recherche sur internet pour les firmwares souhaités.
Les fichiers firmwares sont par convention référencés comme des blobs car vous ne pouvez pas déterminer ce qu'ils font. Notez que ces firmwares sont distribués sous des licences différentes et variées qui ne permettent pas le désassemblage ou la retro ingénierie.
Les firmwares pour PC tombent dans 4 catégories :
Les firmwares mettant à jour le processeur pour travailler correctement, couramment appelé micro-code.
Les microprogrammes pour les contrôleurs vidéo. Sur les machines x86 cela semble s'appliquer surtout aux périphériques ATI (les Radeons, les puces amdgpu) et aux cartes Maxwell et Pascal de Nvidia qui demandent des microprogrammes pour pouvoir utiliser le KMS (kernel modesetting — l'option préférée) ainsi que Xorg. Pour les puces radeons plus anciennes (avant R600), le microprogramme est resté dans le noyau.
Les Firmwares mettant à jour les ports réseaux câblés. Souvent ils fonctionnent sans les mises à jour, mais on peut penser qu'ils travaillent mieux avec les firmwares mis à jour.
Les Firmwares pour les autres périphériques, comme le wi-fi. Ces périphériques ne sont pas requis pour que le PC démarre, mais demande un firmware avant que ces périphériques puissent être utilisés.
Bien qu’ils soient inutiles pour charger un firmware fermé (blob), les outils suivants peuvent être utiles pour déterminer, obtenir, ou préparer le firmware à utiliser afin de le charger dans le système : cpio-2.12, git-2.18.0, pciutils-3.6.2 et Wget-1.19.5
Notes utilisateur : http://wiki.linuxfromscratch.org/blfs/wiki/aboutfirmware
En général, le micro-code peut être chargé par le BIOS ou l'UEFI, et il peut être mis à jour en passant à une nouvelle version de celui-ci. Sur Linux, vous pouvez également charger le micro-code depuis le noyau si vous utilisez au moins un AMD de la famille 10h ou un plus récent (introduit après fin 2007), ou un processeur Intel de 1998 et plus (Pentium4, Core, etc), si un micro-code mis à jour a été publié. Ces mises à jour sont actives seulement jusqu'à ce que la machine soit éteinte, il est donc nécessaire de les appliquer à chaque démarrage.
Intel fournit de fréquentes mises à jour de leur microcode. Ce n'est pas rare de trouver une nouvelle version d'un microcode pour un processeur Intel même deux ans après sa sortie. Les nouvelles versions de microprogramme d'AMD sont rares et ne s'appliquent qu'à quelques modèles, bien que les fabricants de carte mères obtiennent des mises à jour supplémentaires et peuvent mettre à jour des microcodes avec des changements pour supporter de nouveau CPU ou une mémoire plus rapide.
Il y a deux façons de charger le micro-code, décrit comme "au plus tôt" et "le plus tard". Le chargement "au plus tôt" arrive avant que l'espace utilisateur ai été démarré, le chargement "le plus tard" arrive quand l'espace utilisateur est démarré. Sans surprise, le chargement "au plus tôt" est préféré (voir par exemple un commentaire d'explication dans un commit du noyau noté x86/microcode: Early load microcode sur LWN). En effet, il est utile de contourner une erreur particulière dans les premiers processeurs Intel Haswell qui ont le TSX d'activé. (Voir Intel Disables TSX Instructions: Erratum Found in Haswell, Haswell-E/EP, Broadwell-Y). Sans cette mise à jour glibc peut produire des erreurs dans des situations particulières.
Il en résulte, que le chargement « au plus tôt » est
maintenant attendu, bien que pour le moment (noyaux 4.18) il reste
possible de manuellement forcer le chargement « au plus
tard » du microcode pour tester. Vous devrez reconfigurer
votre noyau pour chaque méthode. Les instructions ici créeront un
fichier .config
du noyau pour
satisfaire un chargement « au plus tot », avant de forcer
le chargement « au plus tard » pour voir s'il reste des
microcodes. Si tel est le cas, les instructions vous montrent
comment créer un initrd pour un chargement « au plus
tot ».
Pour confirmer quel(s) processeur(s) vous avez (si plus d'un, ils seront identiques) regardez dans /proc/cpuinfo.
La première étape est d'obtenir la version la plus récente du
micro-code d'Intel. Cela peut être fait en allant sur
https://downloadcenter.intel.com/download/28039/Linux-Processor-Microcode-Data-File
et en suivant les instructions. Au moment de l'écriture de ces
lignes la version la plus récente du micro-code est microcode-20180807.tgz
. Extrayez ce fichier
normalement pour créer un répertoire intel-ucode
qui contient les divers blobs avec
des noms de la forme XX-YY-ZZ. Cette archive ne contient pas de
répertoire de plus haut niveau. Deux fichiers (microcode.dat qui
représente l'ancienne manière de faire la mise à jour toujours
utilisée par certaines distributions Linux, et releasenote)
seront extraits dans le répertoire actuel.
L'URL précédente n'est pas forcément la dernière page. Si ça n'est pas le cas, une ligne au dessus de la liste vous dirigera vers la dernière page.
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 digits hexadécimal. Pour un Haswell i7-4790 (décrit comme un Intel(R) Core(TM) i7-4790 CPU) les bonnes valeurs sont famille de processeur 6, modèle 60, pas 3 donc dans ce cas l'identification requise est 06-3c-03. Un coup d’œil sur les blobs montrera qu'il y en a un pour ce processeur (cependant qui semble déjà appliqué 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) 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 --->
[y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
Processor type and features --->
[y] CPU microcode loading support [CONFIG_MICROCODE]
[y] 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 voir si quelque chose a été chargé :
dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'
Cet exemple du Haswell i7 qui a été publié au printemps 2014 et n'a pas été affecté par l'errata TSX montre qu'il a été mis à jour de la révision 0x19 dans le BIOS/UEFI (ce dont cette version du noyau se plaint maintenant) à la révision 0x24. Contrairement aux anciens noyaux, les CPU individuels ne sont pas signalés séparément :
[ 0.000000] Linux version 4.18.0-rc8 (root@plexi) (gcc version 8.2.0 (GCC))
#2 SMP PREEMPT Sat Aug 11 22:26:26 BST 2018
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.18.0-rc8-sda5 root=/dev/sda5 ro resume=/dev/sdb1
[ 0.000000] [Firmware Bug]: TSC_DEADLINE disabled due to Errata;
please update microcode to version: 0x22 (or later)
[ 0.482712] microcode: sig=0x306c3, pf=0x2, revision=0x19
[ 0.274963] microcode: Microcode Update Driver: v2.2.
[ 1475.941353] microcode: updated to revision 0x25, date = 2018-04-02
[ 1475.944753] x86/CPU: CPU features have changed after loading microcode, but might not take effect
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 ».
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 --->
[y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
Processor type and features --->
[y] CPU microcode loading support [CONFIG_MICROCODE]
[y] 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 ».
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.12 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 devez
spécifier en premier le microcode, en utilisant une ligne tel que
initrd /microcode.img
/other-initrd.img
(adaptez ce qu'il y a avant 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 qui fonctionne avec le démarrage "au plus tôt".
dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'
Les endroits et les moments ou le chargement précoce se passe sont très différents entre les machines AMD et Intel. En premier, un exemple d'Intel sur un noyau à jour, montrant que la première notification vient avant que la version du noyau soit indiquée :
[ 0.000000] microcode: microcode updated early to revision 0x25, date = 2018-04-02
[ 0.000000] Linux version 4.18.1-rc1 (ken@plexi) (gcc version 8.2.0 (GCC))
#2 SMP PREEMPT Tue Aug 14 20:22:35 BST 2018
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.18.1-rc1-sda5 root=/dev/sda5 ro resume=/dev/sdb1
[ 0.275864] microcode: sig=0x306c3, pf=0x2, revision=0x25
[ 0.275911] 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.
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 2Ko. Les périphériques récents ont besoin de plusieurs blobs différents, et certain d'entre eux sont 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.6.2 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 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 utilise des firmwares différents pour les noyaux 3.17 et supérieur en comparaison des kernels 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-18.0.1 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.
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/
Le noyau aime charger des firmware pour quelques pilotes réseaux, particulièrement ceux du répertoire Realtek (/lib/linux-firmware/rtl_nic/), mais il apparaît généralement que cela fonctionne sans. Cependant, vous pouvez démarrer le noyau, vérifiez dmesg pour les messages à propos de firmwares manquants, et si nécessaire télécharger les firmwares et les mettre dans un répertoire spécifique dans /lib/firmware afin qu'ils puissent être trouvés pendant la séquence de démarrage. Notez qu'avec les noyaux actuels cela fonctionne que le pilote soit compilé dedans ou construit comme un module, il n'est pas utile de construire ce firmware dans le noyau. Ici un exemple ou le pilote R8169 a été compilé dedans mais le firmware n'est pas disponible. Une fois que le firmware a été fourni, il n'y est plus fait mention dans les démarrages suivants.
dmesg | grep firmware | grep r8169
[ 7.018028] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
[ 7.018036] r8169 0000:01:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)
Pour identifier le bon firmware vous devrez normallement install
pciutils-3.6.2 puis utiliser lspci
pour identifier le
matériel. Vous devriez ensuite chercher en ligne pour vérifier le
module qu’il utilise, quel firmware et où obtenir le firmware — ils
ne sont pas tous dans linux-firmware.
Si possible, vous pouvez commencer par utiliser une connexion filaire quand vous démarrez la première fois votre système LFS. Pour utiliser une connexion sans fils vous aurez besoin d'utiliser des outils réseau tel que Wireless Tools-29 et wpa_supplicant-2.6.
Les firmwares peuvent aussi être utiles pour d'autres périphériques comme les contrôleurs SCSI, les adaptateurs Bluetooth, ou les enregistreurs TV. Les mêmes principes s'appliquent.
Last updated on 2018-08-14 23:04:34 +0200