Beyond Linux® From Scratch (Edição System V) - Versão 12.3

Capítulo 3. Problemas Depois da Configuração do LFS

Acerca de Firmware

Em alguns PCs recentes, pode ser necessário, ou desejável, carregar firmware para fazê-los funcionar da melhor forma possível. O núcleo ou os controladores de núcleo procuram imagens de firmware em /lib/firmware. Mas no LFS /lib é um link simbólico para usr/lib, de forma que o diretório que contém os arquivos de firmware é, na verdade, /usr/lib/firmware.

Atualmente, a maioria do firmware pode ser encontrada em um repositório git, o qual pode ser visualizado no navegador com a URL https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain. Por conveniência, o Projeto LFS criou um espelho, atualizado diariamente, onde esses arquivos de firmware podem ser acessados via wget ou via um navegador da web em https://anduin.linuxfromscratch.org/BLFS/linux-firmware/.

Para obter o firmware, aponte um navegador para um dos repositórios acima e, então, baixe o(s) item(s) que você precisar. Se você quiser todos esses arquivos de firmware (por exemplo, você estiver distribuindo o sistema em vários sistemas de hardware), ou instale git-2.48.1 e clone https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git, ou abra essa URL em um navegador e baixe o instantâneo mais recente listado na tabela Tag.

[Importante]

Importante

Observe que alguns arquivos de firmware exigidos (e diretórios) são, na verdade, links simbólicos para outros arquivos (ou diretórios). Esses links simbólicos não são armazenados no repositório Git; em vez disso, eles estão documentados no arquivo WHENCE. Cada linha começando com Link: descreve um link simbólico. Se você estiver baixando um item que precisa e ele for um link simbólico (ou em um diretório que seja um link simbólico), você precisa criar o link simbólico manualmente e baixar o alvo. Por outro lado, se você quiser todos os arquivos de firmware, use o comando ./copy-firmware.sh /usr/lib/firmware que copiará os arquivos de firmware e criará todos os links simbólicos no arquivo WHENCE, em vez de um comando de cópia simples como cp -r * /usr/lib/firmware/.

Para algum outro firmware, particularmente para microcódigo da Intel e certos dispositivos wifi, o firmware necessário não está disponível no repositório acima. Algo disso será endereçado abaixo, porém uma busca da Internet pelo firmware necessário de vez em quando é necessária.

Os arquivos de firmware convencionalmente são referenciados como blobs, pois você não consegue determinar o que eles farão. Observe que o firmware é distribuído sob diferentes licenças que não permitem desmontagem ou engenharia reversa.

Firmware para PCs caem em quatro categorias:

[Nota]

Nota

Apesar de não necessárias para carregar um blob de firmware, as seguintes ferramentas possivelmente sejam úteis para determinar, obter ou preparar o firmware necessário para a finalidade de carregá-lo no sistema: cpio-2.15; git-2.48.1; pciutils-3.13.0; e Wget-1.25.0

Atualizações de microcódigo para CPUs

Em geral, microcódigo pode ser carregado pelo BIOS ou pela UEFI e poderia ser atualizado atualizando-se para uma versão mais recente daqueles. No Linux, você também pode carregar o microcódigo a partir do núcleo se estiver usando um processador AMD família 10h ou posterior (introduzido primeiramente no final de 2007); ou um processador Intel a partir de 1998 e posterior (Pentium4, Core, etc), se microcódigo atualizado tiver sido lançado. Essas atualizações duram somente até que a máquina seja desligada, de forma que elas precisam ser aplicadas a cada inicialização.

[Nota]

Nota

Em alguns casos raros, uma atualização de microcódigo oriunda do núcleo pode ser inefetiva. Por exemplo, apesar de intel-microcode-20241029 conter a revisão de microcódigo Raptor Lake 0x12b, que visa a corrigir um problema notório de voltagem excessiva que causa problemas de estabilidade e até mesmo danos permanentes para a CPU, quando o núcleo inicializa, já é tarde demais para o microcódigo corrigir o problema. A única maneira de corrigir esse problema é a de atualizar o BIOS.

A "Intel" fornece atualizações do microcódigo dela para os processadores "Skylake" e posteriores conforme vulnerabilidades novas surjam e forneceu no passado atualizações para processadores a partir do "SandyBridge" em diante, apesar daqueles não mais serem suportados para correções novas. Versões novas do "firmware" "AMD" são raras e geralmente somente se aplicam a uns poucos modelos, apesar dos(as) fabricantes de placas mãe obterem atualizações "AMD Generic Encapsulated Software Architecture" ("AGESA") para mudar os valores do "BIOS", por exemplo, para suportar mais variantes de memória, correções novas de vulnerabilidades ou "CPUs" mais recentes.

Existiam duas maneiras de carregar o microcódigo, descritas como "antecipada" e "atrasada". O carregamento antecipado ocorre antes que o espaço de usuário(a) tenha sido iniciado; o carregamento atrasado ocorre depois que o espaço de usuário(a) iniciou. No entanto, o carregamento atrasado é conhecido por ser problemático e não mais é suportado (veja-se o "commit" do núcleo x86/microcode: Taint and warn on late loading). Na verdade, o carregamento antecipado é necessário para contornar uma errata específica nos primeiros processadores "Intel" "Haswell" que tinham "TSX" habilitado. (Veja-se Intel Disables TSX Instructions: Erratum Found in Haswell, Haswell-E/EP, Broadwell-Y). Sem essa atualização, a "glibc" pode fazer a coisa errada em situações incomuns.

Nas versões anteriores deste livro, era recomendado o carregamento atrasado do microcódigo para verificar se ele seria aplicado, seguido pelo uso de um "initrd" para forçar o carregamento antecipado. Mas agora que o conteúdo do "tarball" do microcódigo "Intel" está documentado e o microcódigo "AMD" pode ser lido por um script "Python" para determinar quais máquinas ele cobre, não existe razão real para usar o carregamento atrasado.

Ainda pode ser possível forçar manualmente o carregamento atrasado do microcódigo. Mas isso possivelmente cause mau funcionamento do núcleo e você mesmo(a) deveria correr o risco. Você precisará reconfigurar teu núcleo para carregamento atrasado, mas carregamento antecipado sempre é suportado pelo núcleo Linux versão 6.6 ou posterior em um sistema x86 (não importa se 32 bits ou 64 bits). As instruções aqui te mostrarão como criar um initrd para carregamento antecipado. Também é possível construir o mesmo arquivo binário de microcódigo interno ao núcleo, o que permite carregamento antecipado, mas exige que o núcleo seja recompilado para atualizar o microcódigo.

Para confirmar qual(is) processador(es) você tem (se mais que um, eles serão idênticos) olhe em "/proc/cpuinfo". Determine os valores decimais da família da "CPU"; do modelo; e da revisão executando o seguinte comando (também informará a versão atual do microcódigo): 

head -n7 /proc/cpuinfo

Converta a família da "CPU", o modelo e a revisão em pares de dígitos hexadecimais e lembre-se do valor do campo “microcode”. Agora você pode verificar se existe algum microcódigo disponível.

Se você estiver criando um "initrd" para atualizar "firmware" para máquinas diferentes, como uma distribuição faria, [então] vá para baixo até 'Carregamento antecipado do microcódigo' e concatene todos os "blobs" "Intel" para "GenuineIntel.bin"; ou concatene todos os "blobs" "AMD" para "AuthenticAMD.bin". Isso cria um "initrd" mais largo - para todas as máquinas "Intel" na atualização 20200609, o tamanho era de três (3,0) MB comparado a tipicamente vinte e quatro (24) KB para uma máquina.

Microcódigo Intel para a CPU

O primeiro passo é o de obter a versão mais recente do microcódigo da Intel. Isso precisa ser feito navegando-se até https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/ e baixando-se o arquivo mais recente lá. Ao tempo da escrita deste texto, a versão mais segura do microcódigo era microcode-20250211. Extraia esse arquivo da maneira normal; o microcódigo estará no diretório intel-ucode, contendo vários blobs com nomes na forma XX-YY-ZZ. Também existem vários outros arquivos e uma observação de lançamento.

No passado, a Intel não fornecia quaisquer detalhes relativos a quais blobs tinham versões mudadas, mas agora a nota de lançamento detalha isso. Você consegue comparar a versão do microcódigo em /proc/cpuinfo com a versão para teu modelo de CPU na nota de lançamento para saber se existe uma atualização.

O firmware recente para processadores mais antigos é fornecido para lidar com vulnerabilidades que agora tenham sido tornadas públicas e, para algumas dessas, tais como Microarchitectural Data Sampling (MDS), você poderia desejar aumentar a proteção desabilitando hyperthreading; ou, alternativamente, desabilitar a mitigação padrão do núcleo, por causa do impacto dela sobre os tempos de compilação. Por favor, leia a documentação online em https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html.

Para um dispositivo móvel Tigerlake (descrito como CPU Intel(R) Core(TM) i5-11300H), os valores relevantes são cpu family 6, model 140, stepping 1, de modo que, nesse caso, a identificação exigida é 06-8c-01. A observação de lançamento diz que o microcódigo mais recente para ele está versionado 0xb8. Se o valor do campo “microcode” em /proc/cpuinfo for 0xb8 ou superior, isso indica que a atualização do microcódigo já foi aplicada pelo BIOS. Caso contrário, prossiga para “Carregamento antecipado do microcódigo”.

Microcódigo AMD para a CPU

Comece baixando um contêiner do "firmware" para a família da sua "CPU" a partir de https://anduin.linuxfromscratch.org/BLFS/linux-firmware/amd-ucode/. A família sempre é especificada em hexadecimal. As famílias "10h" até "14h" (16 até 20) estão no "microcode_amd.bin". As famílias "15h", "16h", "17h" ("Zen", "Zen+", "Zen2") e "19h" ("Zen3") tem os contêineres próprios delas, mas pouquíssimas máquinas provavelmente receberão microcódigo atualizado. Em vez disso, a "AMD" fornece um "AGESA" atualizado para os(as) fabricantes de placas-mãe, que possivelmente forneçam um "BIOS" atualizado usando-o. Existe um script "Python3" em https://github.com/AMDESE/amd_ucode_info/blob/master/amd_ucode_info.py. Baixe esse script e execute-o em relação ao arquivo "bin" para verificar quais processadores tem atualizações.

Para o muito antigo "Athlon(tm) II X2" nesses exemplos os valores eram "cpu family 16", "model 5", "stepping 3", dando uma identificação de Família=0x10 Modelo=0x05 Passo=0x03. Uma linha da saída gerada do script amd_ucode_info.py descreve a versão do microcódigo para ele: 

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

Se o valor do campo “microcode” em /proc/cpuinfo for 0x10000c8 ou superior, isso indica que o BIOS já aplicou a atualização do microcódigo. Caso contrário, prossiga para “Carregamento antecipado do microcódigo”.

Carregamento antecipado do microcódigo

Se você tiver estabelecido que o microcódigo atualizado está disponível para o seu sistema, [então] é hora de prepará-lo para o carregamento antecipado. Isso exige um pacote adicional, o cpio-2.15 e a criação de um initrd que precisará ser adicionado ao grub.cfg.

Não importa onde você prepara o initrd e, tão logo ele esteja funcionando, você pode aplicar o mesmo initrd a sistemas LFS posteriores ou a núcleos mais recentes na mesma máquina, ao menos até que algum microcódigo mais recente seja liberado. Use os seguintes comandos: 

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

Para uma máquina AMD, use o seguinte comando (substitua <MEUCONTEINER> pelo nome do contêiner para a família da sua CPU): 

cp -v ../<MEU_CONTẼINER> kernel/x86/microcode/AuthenticAMD.bin

Ou, para uma máquina Intel, copie o blob apropriado usando este comando: 

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

Agora, prepare o initrd: 

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

Agora você precisa adicionar uma entrada nova a /boot/grub/grub.cfg e aqui você deveria adicionar uma linha nova depois da linha linux dentro da estância. Se /boot for um ponto de montagem separado: 

initrd /microcode.img

ou isto, se ele não for: 

initrd /boot/microcode.img

Se já estiver inicializando com um initrd (veja-se “A respeito do initramfs”), você deveria executar mkinitramfs novamente depois de colocar o blob ou contêiner apropriado em /usr/lib/firmware. Mais precisamente, coloque um blob da Intel em um diretório /usr/lib/firmware/intel-ucode ou um contêiner da AMD em um diretório /usr/lib/firmware/amd-ucode antes de executar mkinitramfs. Alternativamente, você pode ter ambos os initrd na mesma linha, como initrd /microcode.img /other-initrd.img (adapte isso como acima se /boot não for um ponto de montagem separado).

Você agora pode reinicializar com o "initrd" adicionado e, então, usar o seguinte comando para verificar se o carregamento antecipado funcionou: 

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

Se atualizou para endereçar vulnerabilidades, [então] você pode olhar a saída gerada do comando lscpu para ver o que é informado agora.

Os locais e horários onde o carregamento antecipado acontece são muito diferentes em máquinas AMD e Intel. Primeiro, um exemplo de uma Intel (dispositivo móvel Tigerlake) com carregamento antecipado: 

[    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

Um exemplo histórico 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 para Placas de Vídeo

Firmware para chips de vídeo ATI Radeon

Os dispositivos iniciais Radeon precisavam somente de um blob de firmware de 2K. Os dispositivos recentes precisam de vários blobs e alguns deles são muito maiores. O tamanho total do diretório do firmware Radeon é de mais que 500K — em um sistema largo moderno você provavelmente pode poupar o espaço, porém ainda é redundante instalar todos os arquivos não usados a cada vez que construir um sistema.

Uma abordagem melhor é a de instalar o pciutils-3.13.0 e, então, usar o lspci para identificar qual controlador VGA está instalado.

Com essa informação, verifique a página "RadeonFeature" da "wiki" do "Xorg" para Decoder ring for engineering vs marketing names para identificar a família (você possivelmente precise saber disso para o controlador "Xorg" no BLFS — Ilhas do Sul e Ilhas do Mar usam o controlador "radeonsi") e o modelo específico.

Agora que você sabe qual controlador está usando, consulte a página Radeon da wiki do Gentoo a qual tem uma tabela listando os blobs de firmware exigidos para os vários chipsets. Observe que os chips das Ilhas do Sul e os das Ilhas do Mar usam firmware diferente para o núcleo 3.17 e posteriores comparados a núcleos anteriores. Identifique e baixe os blobs exigidos; então instale-os: 

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

Construir o controlador amdgpu do núcleo como um módulo é recomendado porque os arquivos de firmware precisam estar acessíveis ao tempo que ele for carregado. Se você estiver construindo-o como parte da imagem do núcleo por qualquer motivo, você precisará incluir os arquivos de firmware no initramfs (leia-se “A respeito do initramfs” para detalhes) ou incluí-los na própria imagem do núcleo (leia-se “Incluir Blobs de Firmware na Imagem do Núcleo” para detalhes).

"Firmware" para chips de vídeo "amdgpu" "AMD"/"ATI"

Todos os controladores de vídeo que usam o controlador "amdgpu" do núcleo exigem "firmware", se você estará usando o controlador "amdgpu" do "Xorg", o controlador "modesetting" do "xserver" ou apenas o "modesetting" do núcleo para obter um "framebuffer" do console maior que "80x25".

Instale pciutils-3.13.0 e use-o para verificar o nome do modelo (procure por "VGA compatible controller:"). Se você tiver uma "Unidade de Processamento Acelerado" ("APU"), ou seja, "CPU" e vídeo no mesmo chip), provavelmente te dirá o nome. Se você tiver uma placa de vídeo "amdgpu" separada, [então] precisará pesquisar para determinar qual nome ela usa (por exemplo, uma placa descrita como "Advanced Micro Devices, Inc." ["AMD"/"ATI"] "Baffin" ["Radeon RX 550 640SP / RX 560/560X"] precisa de "firmware" "Polaris11". Existe uma tabela de "Família, nome do "Chipset", nome do Produto e Firmware" no final das seções "Kernel" na página AMDGPU do "wiki" do "Gentoo".

Depois que você tiver identificado o nome do "firmware", instale todos os arquivos relevantes para ele. Por exemplo, a placa "Baffin" mencionada acima tem vinte e um (21) arquivos "polaris11*", "APUs" como "renoir" e "picasso" tem pelo menos doze (12) arquivos e podem ganhar mais em atualizações futuras (por exemplo, a "APU" "raven" agora tem um décimo terceiro (13º) arquivo, "raven_ta.bin"). 

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

Se espaço em disco não for um problema, [então] você poderá instalar todos os arquivos atuais de "firmware" "amdgpu" e não se preocupar exatamente com qual "chipset" está instalado.

Construir o controlador amdgpu do núcleo como um módulo é recomendado porque os arquivos de firmware precisam estar acessíveis ao tempo que ele for carregado. Se você estiver construindo-o como parte da imagem do núcleo por qualquer motivo, você precisará incluir os arquivos de firmware no initramfs (leia-se “A respeito do initramfs” para detalhes) ou incluí-los na própria imagem do núcleo (leia-se “Incluir Blobs de Firmware na Imagem do Núcleo” para detalhes).

Firmware para chips de vídeo NVIDIA

Algumas GPUs NVIDIA a partir da Kepler em diante (incluindo todas as GPUs NVIDIA GeForce RTX e séries GTX 9xx em diante) exigem firmware assinado pela NVIDIA para funcionar. Para o controlador Nouveau, a NVIDIA lançou os arquivos assinados de firmware no diretório nvidia/ do linux-firmware. Leia-se a página CodeNames do wiki Nouveau para descobrir o nome do código da tua GPU NVIDIA (por exemplo, o nome do código da GeForce RTX 4060 Ti é AD106). O diretório para os arquivos de firmware que você precisa é nomeado como resultado da conversão do nome do código para letras minúsculas (ad106 para o exemplo). O diretório (ou parte do conteúdo dele) pode ser, na verdade, um link simbólico para outro diretório (ou alguns arquivos em outro diretório) e você precisará então criar o link simbólico e baixar o alvo dele você mesmo(a) (por exemplo, ad106 é um link simbólico para ad102).

Se você não conseguir encontrar o diretório da tua GPU nem na árvore linux-firmware nem no arquivo WHENCE (como um link simbólico), isso significa que, ou tua GPU não precisa de nenhum firmware, ou ela é mais recente que a Ada Lovelace (série RTX 40xx) e o firmware para ela ainda não foi lançado (no final de 2024).

Para as GPUs NVIDIA a partir da Tesla até a Kepler, o controlador Nouveau exige algum firmware extra para suportar aceleração de decodificação de vídeo. Esses arquivos de firmware não são lançados pela NVIDIA, mas eles podem ser extraídos a partir do controlador binário da NVIDIA. Para informações mais exatas acerca de quais chips precisam de firmware extraído, veja-se o VideoAcceleration do wiki Nouveau. Para extrair e instalar esses arquivos de firmware, emita: 

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 /usr/lib/firmware/nouveau
cp -d nv* vuc-* /usr/lib/firmware/nouveau/

Firmware para Interfaces de Rede de Comunicação

O núcleo gosta de carregar firmware para alguns controladores de rede de intercomunicação, particularmente aqueles provenientes da Realtek (o diretório /usr/lib/linux-firmware/rtl_nic/), mas eles geralmente parecem funcionar sem ele. Portanto, você pode inicializar o núcleo, verificar o dmesg para mensagens acerca desse firmware ausente e, se necessário, baixar o firmware e colocá-lo no diretório especificado em /usr/lib/firmware, de forma que ele seja encontrado em inicializações subsequentes. Observe que com os núcleos atuais isso funciona independentemente de o controlador ser compilado internamente ou construído como um módulo; não existe necessidade de construir esse firmware internamente no núcleo. Aqui está um exemplo onde o controlador R8169 foi compilado internamente, mas o firmware não foi disponibilizado. Uma vez que o firmware tenha sido fornecido, não existiu menção a ele em inicializações posteriores. 

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 para Base de Dados Regulatória de Dispositivos Sem Fio

Diferentes países tem diferentes regulamentações acerca do uso do espectro de rádio de dispositivos sem fio. Você pode instalar um firmware para fazer os dispositivos sem fio obedecerem às regulamentações locais do espectro, de forma que você não seja questionado(a) por autoridades locais ou encontre tua placa de rede sem fio bloqueando as frequências de outros dispositivos (por exemplo, controles remotos). O firmware da base de dados regulatória pode ser baixado a partir de https://kernel.org/pub/software/network/wireless-regdb/. Para instalá-lo, basta extrair regulatory.db e regulatory.db.p7s a partir do tarball em /usr/lib/firmware. Observe que ou o controlador cfg80211 precisa estar selecionado como um módulo para que os arquivos regulatory.* sejam carregados, ou esses arquivos precisam estar incluídos como firmware no núcleo, conforme explicado acima em “Firmware para Placas de Vídeo”.

O ponto de acesso (AP) enviaria um código de país para tua NIC sem fio e wpa_supplicant-2.11 diria ao núcleo para carregar a regulação desse país a partir de regulatory.db, e aplicá-la. Observe que vários AP não enviam esse código de país, de forma que você possivelmente fique bloqueado(a) para um uso bastante restrito (especialmente se quiser usar tua interface como um AP).

Firmware Aberto de Som

Alguns sistemas (especialmente laptops econômicos) utilizam um DSP fornecido com a CPU para conexão com o codificador de áudio. O Firmware Aberto de Som precisa ser carregado no DSP para torná-lo funcional. Esses arquivos de firmware podem ser baixados a partir de https://github.com/thesofproject/sof-bin/releases. Extraia o tarball e mude para o diretório extraído e, em seguida, como o(a) usuário(a) root instale o firmware: 

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.13 precisa de arquivos de configuração do Use Case Manager para os sistemas que usam o Sound Open Firmware também. Leia-se a página alsa-lib-1.2.13 para as instruções para instalá-los. Depois que o firmware for carregado (você possivelmente precise reinicializar para que o núcleo os carregue) e os arquivos de configuração do UCM forem instalados, siga “Configurando o ALSA Utilities” para configurar tua placa de som para ALSA corretamente.

Firmware para Outros Dispositivos

Identificar o firmware correto tipicamente exigirá que você instale o pciutils-3.13.0 e, então, use o lspci para identificar o dispositivo. Você deveria então procurar online para verificar qual módulo ele usa; qual firmware; e onde obter o firmware — nem todos eles estão no linux-firmware.

Se possível, você deveria iniciar usando uma conexão com fios quando inicializar pela primeira vez o teu sistema LFS. Para usar uma conexão sem fios, você precisará usar ferramentas de rede de comunicação, tais como iw-6.9, Wireless Tools-29 or wpa_supplicant-2.11.

Firmware possivelmente também seja necessário para outros dispositivos, tais como alguns controladores SCSI; adaptadores bluetooth; ou gravadores de TV. Os mesmos princípios se aplicam.

Incluir Blobs de Firmware na Imagem do Núcleo

Alguns controladores, principalmente os controladores para GPU ATI ou AMD, exigem os arquivos de firmware acessíveis no momento em que são carregados. O método mais fácil de lidar com esses controladores é o de construí-los como um módulo do núcleo. Um método alternativo é o de criar um initramfs (leia-se “A respeito do initramfs” para detalhes) incluindo os arquivos de firmware. Se não quiser usar nenhum dos métodos, você pode incluir os arquivos de firmware na própria imagem do núcleo. Instale os arquivos de firmware necessários em /usr/lib/firmware primeiro, depois configure a seguinte configuração do núcleo e reconstrua o núcleo: 

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]
      # This is the default, you can change it to "/usr/lib/firmware"
      # if you want:
      (/lib/firmware)           Firmware blobs root directory
                                                       ...  [EXTRA_FIRMWARE_DIR]

Substitua xx/aa.bin xx/bb.bin por uma lista de caminhos separados por espaços em branco para os arquivos de firmware necessários, relativos a /usr/lib/firmware. Um método mais fácil que digitar manualmente a lista (ele possivelmente seja longa) é o de executar o seguinte comando: 

echo CONFIG_EXTRA_FIRMWARE='"'$({ cd /usr/lib/firmware; echo amdgpu/* })'"' >> .config
make oldconfig

Substitua amdgpu/* por um padrão de shell que corresponda aos arquivos de firmware necessários.

[Atenção]

Atenção

Não distribua uma imagem do núcleo contendo o firmware para terceiros(as) ou você possivelmente viole a GPL.