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.
Actuellement, on peut trouver la plupart des firmwares sur un dépôt
git
qui peut être
visualisé dans le navigateur avec l'URL
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain.
Par commodité, le projet LFS a créé un miroir, mis à jour
quotidiennement, où on peut accéder à ces fichiers de firmwares via
wget
ou un navigateur
web sur https://anduin.linuxfromscratch.org/BLFS/linux-firmware/.
Pour récupérer le micrologiciel, pointez votre navigateur vers l'un
des dépôts ci-dessus et télécharger les éléments souhaités. Si vous
voulez tous les fichiers de micrologiciel (par exemple si vous
distribuez le système sur plusieurs systèmes matériels), installez
git-2.46.0 et clonez
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
ou bien ouvrez cette URL dans un navigateur et télécharger la
dernière image listée dans l'onglet Tag
.
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.
Microprogramme pour les contrôleurs vidéo. Sur les machines x86 ils sont requis pour les périphériques ATI (puces Radeon et AMDGPU) et peuvent être utiles pour les GPU Intel (Skylake et ultérieur) et Nvidia (Kepler et ultérieurs).
Les périphériques ATI Radeom et AMDGPU demandent des microprogrammes pour pouvoir utiliser le KMS (kernel modesetting — l'option préférée) ainsi que Xorg. Pour les anciennes puces radeon (avant R600), le microprogramme est toujours dans les sources du noyau.
Les GPU intégrés d'Intel de Skylake et supérieur peuvent utiliser le microprogramme pour GuC (the microcontrôleur graphique), et le HuC (le microcontrôleur HEVC/H265 qui décharge vers le GPU) et DMC (microcontrôleur pour l'affichage) pour fournir des états à basse consommation supplémentaires. Le GuC et HuC ont un historique mouvementé dans le noyau et les microprogrammes à jour peuvent être désactivés par défaut, en fonction de la version de votre noyau. Des détails supplémentaires se trouvent sur 01.org et Arch linux.
Les GPU Nvidia à partir de Kepler ont besoin d'un microprogramme signé, sinon le pilote nouveau est incapable de fournir l'accélération matérielle. Nvidia a maintenant fourni des microprogrammes jusqu'à Ampere (la séie GeForce30) dans linux-firmware. Remarquez que les horloges plus rapides que par défaut ne sont pas activées dans le microprogramme publié.
Mises à jour des firmware pour les interfaces réseaux filaires. La plupart fonctionnent sans mise à jour, mais elles fonctionneront sans doute mieux avec un firmware à jour. Pour certains ordinateurs portables récentes, les firmware pour le port ethernet (p. ex. rtl_nic) mais aussi pour les périphériques bluetooth (p. ex. qca) sont requis avant de pouvoir utiliser les réseau filaire.
Les Firmwares pour les autres périphériques, comme le réseau sans fil. 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.15, git-2.46.0, pciutils-3.13.0 et Wget-1.24.5
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 des mises à jour de leur microcode pour les versions Skylake et ultérieures de leurs processeurs quand de nouvelles vulnérabilités sont découvertes, et l'ont fait pour les processeurs SandyBridge et ultérieurs par le passé, bien qu'ils ne soient plus pris en charge pour les nouvelles corrections. 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 AGESA (AMD Generic Encapsulated Software Architecture) pour changer les valeurs du BIOS, par exemple pour prendre en charge plus de variantes de mémoire, de nouvelles vulnérabilités ou de nouveaux CPU.
Il y avait deux façons de charger le microcode, décrites comme « au plus tôt » et « au plus tard ». Le chargement « au plus tôt » arrive avant que l'espace utilisateur ne démarre, le chargement « au plus tard » arrive quand l'espace utilisateur est démarré. Cependant, le chargement au plus tard est problématique et n'est plus pris en charge (voir l commit du noyau noté x86/microcode: Taint and warn on late loading). En effet, il est nécessaire 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.
Dans les versions précédentes de ce livre, nous recommandions le chargement au plus tard pour voir s'il était appliqué, suivi par l'utilisation d'un initrd pour forcer le chargement au plus tôt. Mais maintenant que le contenu de l'archive de microcode Intel est documenté, et que le microcode AMD peut être lu par un script Python pour déterminer les machines qu'il couvre, il n'y a plus de raison d'utiliser le chargement au plus tard.
Il reste peut-être possible de manuellement forcer le chargement « au plus tard » du microcode, mais cela pourrait occasionner une malfonction du noyau et vous devez être conscient·e du risque. Vous devrez reconfigurer votre noyau pour le chargement « au plus tard », mais le chargement « au plus tôt » est toujours pris en charge par le noyau Linux version 6.6 et supérieur pour les systèmes x86 (peu importe qu'ils soient en 32 ou en 64 bits). Les instructions ici montrent comment créer un initrd pour un chargement « au plus tôt ». Il est aussi possible d'intégrer le même fichier binaire de microcode dans le noyau, ce qui permet le chargement au plus tôt mais nécessite de recompiler le noyau pour mettre à jour le microcode.
Pour déterminer l'identité de votre processeur (s'il y en a plus d'un, ils seront identiques) regardez dans /proc/cpuinfo. Déterminez les valeurs décimales de la famille du processeur, le modèle, et le pas en exécutant la commande suivante (elle rapportera aussi la version actuelle du micro-code) :
head -n7 /proc/cpuinfo
Convertissez la famille, le modèle et le pas du processeur en paires de nombre hexadécimaux et rappelez-vous la valeur du champ « microcode ». Vous pouvez maintenant vérifier si un microcode est disponible.
Si vous créez un initrd pour mettre à jour le microcode de différentes machines, comme le ferait une distro, regardez « Chargement du microcode au plus tôt » et concaténez tous les blobs Intel dans GenuineIntel.bin ou tous ceux de AMD dans AUthenticAMD.bin. Cela crée un initrd plus gros — pour toutes les machines Intel dans la mise à jour 20200609 la taille est de 3,0 Mo par rapport à 24 Ko pour une seule machine.
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-20240813. 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 notes de version
en parlent. Vous pouvez comparer la version du microcode dans
/proc/cpuinfo
avec la version pour
votre modèle de CPU dans les notes de version 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 0xb8. Si la valeur du champ « microcode »
dans /proc/cpuinfo
est 0xb8 ou
plus, cela signifie que la mise à jour du microcode est déjà
appliquée par le BIOS. Sinon, consultez 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 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, consultez 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.15 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] Linux version 6.10.4 (xry111@stargazer) (gcc (GCC) 14.2.0, GNU ld (GNU Binutils) 2.43) #4 SMP PREEMPT_DYNAMIC Tue Aug 15 18:04:11 CST 2024
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.10.0 root=PARTUUID=<CLASSIFIED>
ro
[ 0.585605] microcode: Current revision: 0x000000b8
[ 0.585611] microcode: Updated early from: 0x00000086
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 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.13.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).
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.13.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).
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/
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érifier si dmesg contient des 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
lors des prochains démarrages. 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)
Plusieurs pays ont des réglementations différentes sur
l'utilisation du spectre radio des appareils sans-fil. Vous pouvez
installer un microprogramme pour qu'un appareil sans-fil obéisse
aux réglementations sur les émissions, pour ne pas être inquiété
par les autorités ou découvrir que votre wifi brouille les
fréquences d'autres appareils (par exemple des télécommandes). Le
microprogramme qui contient la base de régulations se trouve sur
https://kernel.org/pub/software/network/wireless-regdb/.
Pour l'installer, extrayez simplement regulatory.db
et regulatory.db.p7s
de l'archive vers /lib/firmware
. Remarquez que vous devez soit
sélectionner le pilote cfg80211
en tant
que module pour que les fichiers regulatory.*
soient chargés, soit inclure ces
fichiers directement comme un micrologiciel dans le noyau, comme
expliqué plus haut dans la section intitulée
« Firmware pour les cartes vidéo ».
Le point d'accès (AP) enverrait un code de pays à votre carte sans
fil, et wpa_supplicant-2.11 dirait au noyau
de charger les règles pour ce pays à partir de regulatory.db
et de les utiliser. Remarquez que
de nombreux points d'accès n'envoient pas de code de pays, donc
vous pourriez être bloqué dans une utilisation restreinte (surtout
si vous voulez utiliser votre interface comme point d'accès).
Certains systèmes (surtout les portables pas chers) utilisent un
DSP fournit avec le CPU pour se connecter au codec audio. Le
micrologiciel libre pour l'audio (Open Sound Firmware) doit être
chargé sur le DSP pour le rendre fonctionnel. Ces fichiers de
micrologiciel peuvent être téléchargés sur https://github.com/thesofproject/sof-bin/releases.
Extrayez l'archive et rendez-vous dans le répertoire extrait, puis
en tant qu'utilisateur root
installez le micrologiciel :
install -vdm755 /usr/lib/firmware/intel && cp -av -T --no-preserve=ownership sof \ /usr/lib/firmware/intel/sof && cp -av -T --no-preserve=ownership sof-tplg \ /usr/lib/firmware/intel/sof-tplg
alsa-lib-1.2.12 nécessite les fichiers de configuration du gestionnaire de cas d'utilisation pour que le système utilise également les micrologiciels libres pour l'audio. Consultez le page alsa-lib-1.2.12 pour trouver les instructions sur leur installation. Une fois le micrologiciel chargé (vous devrez peut-être redémarrer pour que le noyau les charge) et les fichiers de configuration UCM installés, suivez la section intitulée « Configuration de ALSA Utilities » pour configurer votre carte son avec ALSA correctement.
Pour identifier le bon firmware vous devrez normallement install
pciutils-3.13.0 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 tels que iw-6.9, Wireless Tools-29 ou wpa_supplicant-2.11.
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.
Certains pilotes, surtout les pilotes pour les GPU ATI ou AMD, ont
besoin que des fichiers de micrologiciel soient accessibles au
chargement. La méthode la plus facile de gérer ces pilotes est de
les construire en tant que module du noyau. Une autre méthode
consiste à créer un initramfs (consultez la section intitulée
« À propos de initramfs » pour les détails) qui
contiendrait les fichiers du micrologiciel. Si vous ne voulez pas
utiliser ces méthodes, vous pouvez inclure directement les fichiers
du micrologiciel dans l'image du noyau. Installez d'abord les
fichiers de micrologiciel requis dans /lib/firmware
, puis configurez le noyau et
reconstruisez-le :
Device Drivers ---> Generic Driver Options ---> Firmware loader ---> <*> Firmware loading facility [FW_LOADER] (xx/aa.bin xx/bb.bin) Build named firmware blobs into the kernel binary ... [EXTRA_FIRMWARE] (/lib/firmware) Firmware blobs root directory ... [EXTRA_FIRMWARE_DIR]
Remplacez xx/aa.bin
xx/bb.bin
par une liste de chemins séparés par des
espaces vers les fichiers requis, relativement à /lib/firmware
. Une méthode plus simple que de
taper la liste complète à la main (ça peut être long) consiste à
exécuter la commande suivante :
echo CONFIG_EXTRA_FIRMWARE='"'$({ cd /lib/firmware; echo amdgpu/*
})'"' >> .config
make oldconfig
Remplacez amdgpu/*
par un
motif shell correspondant aux fichiers de micrologiciel requis.
Ne distribuez pas une image du noyau contenant les micrologiciels à d'autres personnes ou vous pourriez violer la licence GPL.