Au-delà de Linux® From Scratch - Version 7.8;

Chapitre 3. Questions de configuration après LFS

A propos des Firmwares

Sur certains PCs actuels il peut être nécéssaire, 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 mirroir, mis à jour quotidiennement, ou on peut accéder à ces fichiers de firmwares via wget ou un navigateur web à http://anduin.linuxfromscratch.org/sources/linux-firmware/.

Pour avoir le firmware il faut soit aller avec un navigateur sur le dépôt et ensuite télécharger les fichiers dont vous avez besoin, ou installer git et cloner ce dépot.

Pour certains autres firmwares, particulièrement pour les microcode d'Intel, et certains périphériques wifi, 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écéssaire 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:

[Note]

Note

Comme il n'est pas utile de charger un firmware fermé (blob), les outils suivant peuvent être utile pour déterminer, obtenir, ou préparer le firwmare à utiliser afin de le charger dans le système. cpio-2.11, git-2.5.0, PCI Utils-3.4.0, et Wget-1.16.3

Notes utilisateur : http://wiki.linuxfromscratch.org/blfs/wiki/aboutfirmware

Mise à jour de microcodes pour les CPUs

En général, le microcode peut être chargé par le BIOS ou l'UEFI, et il peut être mis à jour en passant à une nouvelle version de celui-çi. Sur linux, vous pouvez également charger le microcode depuis le noyau si vous utilisez au moins un AMD de la famille 10h ou un plus récent (introduit après 2007), ou un processeur intel de 1980 et plus (Pentium4, Core, etc), si un microcode 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.

Il y a deux façons de charger le microcode, 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 un commentaire d'explication dans un commit du noyau noté e x86/microcode: Early load microcode sur LWN.) En effet, il est utile de contourner une erreur particulière dans les premièrs 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 faire des erreurs dans des situations particulières.

Il est beaucoup plus simple de commencer par construire un noyau qui démarre sur votre matériel, essayer de charger le microcode "le plus tard" pour voir s'il y a une mise à jour (dans la plupart des cas le BIOS ou l'UEFI aura déja appliqué toutes les mises à jours), et ensuite faire les étapes supplémentaires dans la configuration du noyau pour un chargement "au plus tôt".

Cela signifie que vous devrez reconfigurer votre noyau si vous utilisez le chargement "au plus tôt", aussi laissez les sources construites afin de minimiser ce qui aura besoin d'être reconstruit, et si vous êtes incertain, ajoutez votre propre identifiant (A, B, à la fin de l'EXTRAVERSION dans la configuration du noyau, soit "EXTRAVERSION -A" si rien est initialisé.

Pour confirmer quel(s) processeur(s) vous avez (si plus d'un, ils seront identiques) regardez dans /proc/cpuinfo.

Microcode Intel pour le CPU

Paquet requis

http://fedorahosted.org/released/microcode_ctl/

Pour les CPU intel, un paquet supplémentaire, microcode_ctl, est requis. Le paquet choisi est la version hébergé sur Fedora — il y a une version alternative sur github du même empaqueteur, mais qui laisse une ancienne version redondante d'un container de microcode AMD, et aussi requiert le paquet unzip.

Téléchargement de la dernière version depuis le lien précédent; à la dernière vérification, il était en version 2.1-7 et est mis à jour quand intel publie de nouveaux microcodes.

Ce paquet reformate le microcode fourni par intel dans un format que le noyau peut appliquer. Le programme intel-microcode2ucode est construit et invoqué par le Makefile pour créer des blobs individuels de firmwares, donc il n'y a pas de raison de les installer.

Commencez par extraire l'archive et allez dans le répertoire créé. Ensuite allez dans le répertoire des sources et lancez: 

make

Cela crée de nombreux blobs avec des noms de la forme XX-YY-ZZ. Maintenant vous devez déterminer l'identité de votre processeur, pour vois s'il y a un microcode pour lui. Déterminez les valeurs décimales de la famille du cpu, le modèle, et le pas en lançant: 

head -n7 /proc/cpuinfo

Maintenant convertissez la famille du cpu, le modèle et le pas en paire de digits héxadécimal. Pour un SandyBridge i3-2120 (décrit comme un Intel(R) Core(TM) i3-2120 CPU) les bonnes valeurs sont famille de cpu 6, modèle 42, pas 7 donc dans ce cas l'identification requise est 06-2a-07. Un coup d'oeil sur les blobs montrera qu'il y en a un pour ce CPU (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) ou le noyau pourra le trouver. 

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

Maintenant que le microcode intel a été préparé, utilisez les options suivantes quand vous configurez le noyau pour essayer le chargement "tard" du microcode intel: 

Processor type and features  --->
  <M> CPU microcode loading support  [CONFIG_MICROCODE]
  [*]      Intel microcode loading support [CONFIG_MICROCODE_INTEL]

Après que vous ayez démarré le nouveau système avec succès, utilisez la commande dmesg | grep microcode et étudiez les résultats pour voir si le message patch_level apparait. Voici un exemple pour le SandyBridge i3: 

[    0.059906] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode
[    2.603083] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x23
[    2.669378] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x23
[    2.669994] microcode: CPU0 updated to revision 0x29, date = 2013-06-12
[    2.670069] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x23
[    2.670139] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x23
[    2.670501] microcode: CPU1 updated to revision 0x29, date = 2013-06-12
[    2.670509] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x23
[    2.670540] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x23
[    2.670917] microcode: CPU2 updated to revision 0x29, date = 2013-06-12
[    2.670955] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x23
[    2.670988] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x23
[    2.671348] microcode: CPU3 updated to revision 0x29, date = 2013-06-12
[    2.671356] perf_event_intel: PEBS enabled due to microcode update
[    2.671412] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

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

Microcode AMD pour le CPU

Commencez par télécharger un paquet de firmware pour votre famille de CPU sur http://anduin.linuxfromscratch.org/sources/linux-firmware/amd-ucode/. La famille est toujours spécifiées en héxa. Les familles 10h à 14h (16 à 20) sont dans microcode_amd.bin. Les familles 15h et 16h 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 essayer un chargement "tard" du microcode AMD: 

Processor type and features  --->
  <M> CPU microcode loading support   [CONFIG_MICROCODE]
  [*]   AMD microcode loading support [CONFIG_MICROCODE_AMD]

After you have successfully booted the new system, use the command dmesg | grep microcode et study the results to see if the message new patch_level appears, as in this example from an old Athlon(tm) II X2: 

[    4.183907] microcode: CPU0: patch_level=0x010000b6
[    4.184271] microcode: CPU0: new patch_level=0x010000c8
[    4.184278] microcode: CPU1: patch_level=0x010000b6
[    4.184283] microcode: CPU1: new patch_level=0x010000c8
[    4.184359] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

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

Chargement "tôt" du microcode

Si vous avez établi d'un microcode 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.11, ainsi que des modifications à la configuration du noyau 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 microcode 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 devez maintenant reconfigurer et reconstruire votre noyau. Il est prudent pour chaque d'ajouter/changer l'EXTRAVERSION dans la configuration du noyau et d'installer le nouveau noyau avec un nouveau nom, ou alors (à moins que vous ayez une machine qui requiert une mise à jour du firmware "tôt") attendre la prochaine publication SUBLEVEL du noyau de sorte que vous puissiez revenir au noyau existant dans le cas où quelque chose irait mal.

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

initrd /microcode.img

ou sinon : 

initrd /boot/microcode.img

Vous devez également modifier la config du noyau: 

General Setup --->
  [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
  [y] CPU microcode loading support                                  [CONFIG_MICROCODE]

Retenez l'initialisation pour le microcode INTEL ou AMD. Quand vous avez sauvegardé le fichier .config, soit CONFIG_MICROCODE_INTEL_EARLY=y ou CONFIG_MICROCODE_AMD_EARLY=y doit être initialisé, avec CONFIG_MICROCODE_EARLY=y.

Quand vous avez installé et démarré ce noyau, vous pouvez vérifier la sortie de dmesg pour confirmer que le chargement "tôt" fonctionne. Les endroits et les temps ou cela se passent sont très différents sur les machines AMD et Intel. En premier, un exemple d'Intel ou un noyau de développment est testé, regardez que la première notification vient avant que la version du noyau soit indiquée: 

[    0.000000] CPU0 microcode updated early to revision 0x29, date = 2013-06-12
[    0.000000] Linux version 4.0.0-rc6 (ken@jtm1) (gcc version 4.9.2 (GCC) ) 
               #3 SMP PREEMPT Mon Mar 30 21:26:02 BST 2015
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.0.0-rc6-sda13 root=/dev/sda13 ro
...
[    0.103091] CPU1 microcode updated early to revision 0x29, date = 2013-06-12
[    0.113241]  #2
[    0.134631]  #3
[    0.147821] x86: Booted up 1 node, 4 CPUs
[    0.147936] smpboot: Total of 4 processors activated (26338.66 BogoMIPS)
...
[    0.272643] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x29
[    0.272709] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x29
[    0.272775] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x29
[    0.272842] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x29
[    0.272941] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Un deuxième exemple AMD ou la machine lance un noyau stable sur une ancienne version de LFS. Notez que ici, il n'est pas indiqué la version du microcode précédent — comparez cette sortie aux messages de chargement "tard" (plus haut) de la même machine: 

[    0.000000] Linux version 3.18.11 (ken@milliways) (gcc version 4.9.1 (GCC) ) 
               #4 SMP Thu Apr 9 21:51:05 BST 2015
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.18.11-sda5 root=/dev/sda5 video=800x600 ro
...
[    0.584009] Trying to unpack rootfs image as initramfs...
[    0.584092] microcode: updated early to new patch_level=0x010000c8
...
[    0.586733] microcode: CPU0: patch_level=0x010000c8
[    0.586778] microcode: CPU1: patch_level=0x010000c8
[    0.586866] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Firmware pour les puces video ATI (R600 et plus)

Ces instructions NE s'applique pas aux anciennes radaeons 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 radéon plus récent demande seulement un simple blod 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 radéon 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'installer PCI Utils-3.4.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 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 actuellement 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-7.5.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 vuivez 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 radéon utile si vous faite cela.

Firmware pour les interfaces réseaux

Le noyau aime charger des firmware pour quelques pilotes réseau, particulièrement ceux du répertoire Realtek (/lib/linux-firmware/rtl_nic/), mais il apparait 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'avez 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)

Firmware pour les autres périphériques

L'identification du bon firmware requiera typiquement l'installation de PCI Utils-3.4.0, et ensuite l'utilisation de lspci pour identifier le périphérique. Vous pouvez ensuite chercher en ligne pour vérifier quel module il utilise. quel firmware, et ou obtenir le firmware — aucun de ceux la est dans linux-firmware.

Si possible, vous pouvez commencer par utiliser une connexion cablé 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.5.

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 2012-03-13 13:19:34 -0500