På noen nyere PC-er kan det være nødvendig, eller ønskelig, å laste
fastvare for å få dem til å fungere på sitt beste. Det er en mappe,
/lib/firmware
, hvor kjernen eller
kjernedrivere ser etter fastvarebilder.
For øyeblikket kan det meste av fastvaren finnes på et git
depoet som kan vises i
nettleseren med URLen
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain.
For enkelhets skyld har LFS prosjektet laget et speil, som oppdateres
daglig, hvor disse fastvarefilene kan nås via wget
eller en nettleser på
https://anduin.linuxfromscratch.org/BLFS/linux-firmware/.
For å få fastvaren, pek en nettleser til en av de ovennevnte depoer
og last ned varen(e) du trenger. Hvis du vil ha alle disse
fastvarefilene (for eksempel distribuerer du systemet på flere
maskinvaresystemer), enten installer git-2.47.0 og klon
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git,
eller åpne denne URL-en i en nettleser og last ned det siste
øyeblikksbildet som er oppført i Tag
tabellen.
For noen annen fastvare, spesielt for Intel mikrokode og visse wifi enheter, den nødvendige fastvaren er ikke tilgjengelig i depotet ovenfor. Noe av dette vil bli behandlet nedenfor, men et søk på Internett etter nødvendig fastvare er noen ganger nødvendig.
Fastvarefiler blir konvensjonelt referert til som blobs fordi du ikke kan bestemme hva de vil gjøre. Merk at fastvaren er distribuert under ulike lisenser som ikke tillater demontering eller revers-engineering.
Fastvare for PC-er faller inn i fire kategorier:
Oppdateringer til CPU for å omgå errata, vanligvis referert til som mikrokode.
Firmware for videokontrollere. På x86-maskiner kreves dette for ATI-enheter (Radeon- og AMDGPU-brikker) og kan være nyttige for Intel (Skylake og senere) og Nvidia (Kepler og senere) GPUer.
ATI Radeon- og AMDGPU-enheter krever alle fastvare for å kunne bruke KMS (kjernemodusinnstilling - det foretrukne alternativet) så vel som for Xorg. Til gamle radeon-brikker (før R600), er fastvaren fortsatt i kjernekilden.
Intel integrerte GPUer fra Skylake og utover kan bruke fastvare for GuC (grafikkmikrokontrolleren), og også for HuC (HEVC/H265 mikrokontroller som avlastes til GPUen) og DMC (skjerm Mikrokontroller) for å gi ytterligere laveffekttilstander. GuC og HuC har hatt en kontrollert historikk i kjernen og oppdatert firmware kan være deaktivert som standard, avhengig av kjerneversjonen din. Lengre detaljer kan finnes på 01.org og Arch linux.
Nvidia GPUer fra Kepler og utover krever signert fastvare, ellers er nouveau-driveren ikke i stand til å gi maskinvareakselerasjon. Nvidia har nå utgitt firmware opp til Ampere (GeForce30-serien) til linux-firmware. Merk at raskere klokker enn standard ikke er aktivert av den utgitte fastvaren.
Fastvareoppdateringer for kablede nettverksporter. De fleste av dem fungerer til og med uten oppdateringene, men de vil nok fungere bedre med den oppdaterte fastvaren. For noen moderne bærbare datamaskiner, fastvare for begge kablet ethernet (f.eks. rtl_nic) og også for bluetooth-enheter (f.eks. qca) er påkrevd før det kablede nettverket kan brukes.
Fastvare for andre enheter, for eksempel trådløse NICs. Disse enhetene er ikke nødvendug for at PC-en skal starte opp, men trenger fastvaren før disse enhetene kan bli brukt.
Selv om det ikke er nødvendig for å laste inn en fastvareblob, kan følgende verktøy være nyttige for å bestemme, skaffe eller forberede den nødvendige fastvaren for å laste den inn i systemet: cpio-2.15, git-2.47.0, pciutils-3.13.0, og Wget-1.25.0
Generelt kan mikrokode lastes av BIOS eller UEFI, og det kan bli oppdatert ved å oppgradere til en nyere versjon av disse. På linux kan du også laste inn mikrokoden fra kjernen hvis du bruker en AMD-familie 10h eller senere prosessor (først introdusert sent i 2007), eller en Intel-prosessor fra 1998 og senere (Pentium4, Core, etc), hvis oppdatert mikrokode har vært utgitt. Disse oppdateringene varer bare til maskinen slås av, så de må brukes på hver oppstart.
I noen sjeldne tilfeller kan en mikrokodeoppdatering fra kjernen være ineffektiv. For eksempel intel-microcode-20241029 inneholder Raptor Lake mikrokode revisjon 0x12b som er ment å fikse en beryktet overdreven spenningsproblem som forårsaker stabilitetsproblemer og til og med permanente prosessorskader, når kjernen starter er det allerede for sent for at mikrokoden skal fikse problemet. Den eneste måten å fikse dette problemet på er å oppdatere BIOS.
Intel tilbyr oppdateringer av mikrokoden deres for Skylake og senere prosessorer etter som nye sårbarheter dukker opp, og har tidligere gitt oppdateringer for prosessorer fra SandyBridge og utover, selv om de ikke støttes for nye rettelser lenger. Nye versjoner av AMD fastvare er sjeldne og gjelder vanligvis bare for noen få modeller hovedkortprodusenter får AGESA (AMD Generic Encapsulated Software Architecture) oppdateringer for å endre BIOS verdier, f.eks. for å støtte flere minnevarianter, nye sårbarhetsrettinger eller nyere CPUer.
Det var to måter å laste mikrokoden på, beskrevet som "tidlig" og 'sent'. Tidlig lasting skjer før brukerområdet er startet, sen lasting skjer etter at brukerområdet har startet. Men sen lasting er kjent for å være problematisk og støttes ikke lenger (se kjerne-commit x86/microcode: Taint and warn on late loading). Faktisk tidlig lasting er nødvendig for å omgå en bestemt feil i tidlig Intel Haswell-prosessorer som hadde TSX aktivert. (Se Intel Disables TSX Instructions: Erratum Found in Haswell, Haswell-E/EP, Broadwell-Y.) Uten denne oppdateringen kan glibc gjøre feil ting i uvanlig situasjoner.
I tidligere versjoner av denne boken, sen lasting av mikrokode for å se om det ble brukt ble anbefalt, etterfulgt av bruk av en initrd for å tvinge tidlig lasting. Men nå som innholdet i Intel mikrokode tarballen er dokumentert, og AMD-mikrokode kan leses av et Python skript til å bestemme hvilke maskiner det dekker, er det ingen reell grunn til å bruke sen lasting.
Det kan fortsatt være mulig å manuelt tvinge sen innlasting av mikrokode. Men det kan forårsake kjernefeil, og du bør ta risikoen selv. Du må rekonfigurere kjernen for sen lasting, men tidlig lasting støttes alltid av Linux kjerneversjon 6.6 eller senere på et x86 (uansett 32-bit eller 64-bit) system. Instruksjonene her vil vise deg hvordan du oppretter en initrd for tidlig lasting. Det er også mulig å bygge inn den samme mikrokode bin-filen i kjernen, som tillater tidlig lasting, men krever at kjernen blir kompilert på nytt for å oppdatere mikrokoden.
For å bekrefte hvilken(e) prosessor(er) du har (hvis flere enn én, vil de være identisk) se i /proc/cpuinfo. Bestem desimalverdiene til cpuen familie, modell og stepping ved å kjøre følgende kommando (det vil også rapportere gjeldende mikrokodeversjon):
head -n7 /proc/cpuinfo
Konverter cpu familien, modellen og stepping til par med heksadesimal sifre, og husk verdien av «mikrokode» feltet. Du kan nå sjekke om det er en tilgjengelig mikrokode.
Hvis du oppretter en initrd for å oppdatere fastvare for forskjellige maskiner, som en distro ville gjort, gå ned til 'Tidlig lasting av mikrokode' og cat alle Intel blobs til GenuineIntel.bin eller cat alle AMD blobs til AuthenticAMD.bin. Dette skaper en større initrd - for alle Intel maskiner i 20200609 oppdateringen var størrelsen 3,0 MB sammenlignet med typisk 24 KB for en maskin.
Det første trinnet er å få den nyeste versjonen av Intel
mikrokode. Dette må gjøres ved å navigere til
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/
og laster ned den nyeste filen der. Når dette skrives den mest
sikre versjonen av mikrokoden er microcode-20241029. Pakk ut
denne filen på vanlig måte, mikrokoden er i intel-ucode
mappen, som inneholder ulike blobs
med navn i formen XX-YY-ZZ. Det er også forskjellige andre filer,
og en utgivelsesnotat.
Tidligere ga ikke Intel noen detaljer om hvilke blobs som hadde
endret versjoner, men nå beskriver utgivelsesmerknaden dette. Du
kan sammenligne mikrokodeversjonen i /proc/cpuinfo
med versjonen for din CPU modell
i utgivelsesmerknaden for å vite om det er en oppdatering.
Den nylige fastvaren for eldre prosessorer er tilgjengelig for å håndtere sårbarheter som nå er offentliggjort, og for noen av disse for eksempel Microarchitectural Data Sampling (MDS) vil du kanskje øke beskyttelsen ved å deaktivere hyperthreading, eller alternativt å deaktivere kjernens standardredusering på grunn av dens innvirkning på kompileringstider. Vennligst les dokumentasjonen på https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html.
For en Tigerlake bærbar (beskrevet som Intel(R) Core(TM)
i5-11300H CPU) de relevante verdiene er cpu familie 6, modell
140, stepping 1 så i dette tilfellet er nødvendig identifikasjon
06-8c-01. Utgivelsesnotat sier at den nyeste mikrokoden for den
er versjonert 0xb8. Hvis verdien av «mikrokode» feltet i
/proc/cpuinfo
er 0xb8 eller høyere,
indikerer det at mikrokodeoppdateringen allerede er tatt i bruk
av BIOS. Ellers, fortsett til «Tidlig lasting av mikrokode»:
Begynn med å laste ned en beholder med fastvare for CPU familien din fra https://anduin.linuxfromscratch.org/BLFS/linux-firmware/amd-ucode/. Familien er alltid spesifisert i hex. Familier 10-14 (16-20) er i microcode_amd.bin. Familier 15t, 16t, 17t (Zen, Zen+, Zen2) og 19h (Zen3) har sine egne beholdere, men sannsynligvis er det få maskiner som får oppdatert mikrokode. I stedet gir AMD en oppdatert AGESA til hovedkortprodusenter, som kan gi en oppdatert BIOS ved å bruke dette. Det er et Python3 skript på https://github.com/AMDESE/amd_ucode_info/blob/master/amd_ucode_info.py. Last ned det skriptet og kjør det mot bin filen for å sjekke hvilke prosessorer som har oppdateringer.
For den svært gamle Athlon(tm) II X2 i disse eksemplene var verdiene cpu familie 16, modell 5, trinn 3 gir en identifikasjon av Familie=0x10 Modell=0x05 Stepping=0x03. En linje av amd_ucode_info.py skriptutdataen beskriver mikrokodeversjon for det:
Family=0x10 Model=0x05 Stepping=0x03: Patch=0x010000c8 Length=960 bytes
Hvis verdien av «mikrokode» feltet i /proc/cpuinfo
er 0x10000c8 eller høyere,
indikerer det at BIOS allerede har tatt i bruk
mikrokodeoppdateringen. Ellers, fortsett deretter til «Tidlig lasting av mikrokode»:
Hvis du har etablert at en oppdatert mikrokode er tilgjengelig for systemet ditt, er det på tide å forberede det for tidlig lasting. Dette krever en ekstra pakke, cpio-2.15 og opprettelsen av en initrd som må legges til grub.cfg.
Det spiller ingen rolle hvor du forbereder initrd, og når det virker kan du bruke samme initrd til senere LFS systemer eller nyere kjerner på samme maskin, i det minste inntil en nyere mikrokode er utgitt. Bruk følgende kommandoer:
mkdir -p initrd/kernel/x86/microcode cd initrd
For en AMD maskin, bruk følgende kommando (erstatt <MYCONTAINER> med navnet på beholderen for CPU familien din):
cp -v ../<MYCONTAINER> kernel/x86/microcode/AuthenticAMD.bin
Eller for en Intel maskin, kopier den aktuelle bloben ved å bruke denne kommandoen:
cp -v ../intel-ucode/<XX-YY-ZZ> kernel/x86/microcode/GenuineIntel.bin
Forbered nå initrd:
find . | cpio -o -H newc > /boot/microcode.img
Du må nå legge til en ny oppføring i /boot/grub/grub.cfg og her bør du legge til en ny linje etter linux linjen i strofen. Hvis /boot er et separat monteringspunkt:
initrd /microcode.img
eller dette hvis det ikke er det:
initrd /boot/microcode.img
Hvis du allerede starter opp med en initrd (se «Om initramfs»),
bør du bør kjøre mkinitramfs igjen etter å ha
puttet den riktige bloben eller beholderen i /lib/firmware
. Mer presist, putt en intel blob
i /lib/firmware/intel-ucode
mappen
eller en AMD beholder i /lib/firmware/amd-ucode
mappen før du kjører
mkinitramfs.
Alternativt kan du ha begge initrd på samme linje, som f.eks
initrd /microcode.img
/other-initrd.img
(tilpass som ovenfor hvis /boot
ikke er et separat monteringspunkt).
Du kan nå starte på nytt med den ekstra initrd, og deretter bruke følgende kommando for å sjekke at den tidlige lastingen fungerte:
dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'
Hvis du oppdaterte for å adressere sårbarheter, kan du se på utdataen til lscpu kommandoen for å se hva som er rapportert nå.
Stedene og tidspunktene hvor tidlig lasting skjer er svært forskjellige i AMD- og Intel-maskiner. Først et eksempel på en Intel (Tigerlake bærbar) med tidlig lasting:
[ 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
Et historisk AMD eksempel:
[ 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.
Disse instruksjonene gjelder IKKE gamle radeoner før R600
familien. For dem er fastvaren i kjernen sin /lib/firmware/
mappen. Det gjør det heller ikke
hvis du har tenkt å unngå et grafisk oppsett som Xorg og er
komfortabel med å bruke standard 80x25-skjerm i stedet for en
rammebuffer.
Tidlige radeon enheter trengte bare en enkelt 2K blob med fastvare. Nylige enheter trenger flere forskjellige blobs, og noen av dem er mye større. Den totale størrelsen på radeon fastvarekatalogen er over 500K — på et stort moderne system kan du nok spare plassen, men det er fortsatt overflødig å installere alle ubrukte filer hver gang du bygger et system.
En bedre tilnærming er å installere pciutils-3.13.0 og så bruke lspci
for å identifisere
hvilken VGA kontroller som er installert.
Med den informasjonen, sjekk RadeonFeature siden til Xorg wikien Decoder ring for engineering vs marketing names for å identifisere familien (det kan hende du må vite dette for Xorg driveren i BLFS — Southern Islands og Sea Islands bruker radeonsi driveren) og den spesifikke modellen.
Nå som du vet hvilken kontroller du bruker, se Radeon siden til Gentoo wikien som har en tabellliste over de nødvendige fastvare blobene for de forskjellige brikkesettene. Merk at Southern Islands og Sea Islands chips bruker forskjellig fastvare for kernel 3.17 og senere sammenlignet med tidligere kjerner. Identifiser og last ned de nødvendige blobene og installer dem:
mkdir -pv /lib/firmware/radeon cp -v <YOUR_BLOBS> /lib/firmware/radeon
Det anbefales å bygge kjerne amdgpu driveren som en modul fordi fastvarefilene må være tilgjengelige når den lastes. Hvis du bygger det som en del av kjernebildet av en eller annen grunn, må du enten inkludere fastvarefilene i initramfs (les «Om initramfs» for detaljer), eller inkludere dem i selve kjernebildet (les «Inkluder fastvare blobber i kjernebildet» for detaljer).
Alle videokontrollere som bruker amdgpu kjernedriveren krever fastvare, om du skal bruke xorg amdgpu driveren, xserverens modusinnstillings driver, eller bare kjernemodusinnstilling for å få en konsollrammebuffer større enn 80 x 25.
Installer pciutils-3.13.0 og bruk det for å sjekke modellnavnet (se etter 'VGA-kompatibel kontroller:'). Hvis du har en APU (akselerert Processing Unit, dvs. CPU og video på samme brikke) som sannsynligvis vil fortelle deg navnet. Hvis du har et eget amdgpu skjermkort trenger du å søke for å finne ut hvilket navn den bruker (f.eks. et kort beskrevet som Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] trenger Polaris11 fastvare. Det er en tabell med "Familie, Chipset navn, produktnavn og fastvare" på slutten av kjernedelene i AMDGPU siden til Gentoo wikien.
Når du har identifisert fastvarenavnet, installer alle relevante filer for det. For eksempel har Baffin kortet nevnt ovenfor 21 forskjellige polaris11*-filer, APUer som renoir og picasso har minst 12 filer og kan få mer i fremtidige oppdateringer (f.eks. har raven APU nå en 13. fil, raven_ta.bin).
mkdir -pv /lib/firmware/amdgpu cp -v <YOUR_BLOBS> /lib/firmware/amdgpu
Hvis diskplass ikke er et problem, kan du installere all gjeldende amdgpu fastvarefiler og ikke bekymre deg for nøyaktig hvilket brikkesett som er installert.
Det anbefales å bygge kjerne amdgpu driveren som en modul fordi fastvarefilene må være tilgjengelige når den lastes. Hvis du bygger det som en del av kjernebildet av en eller annen grunn, må du enten inkludere fastvarefilene i initramfs (les «Om initramfs» for detaljer), eller inkludere dem i selve kjernebildet (les «Inkluder fastvare blobber i kjernebildet» for detaljer).
Nvidia har gitt ut grunnleggende signert fastvare for nyere grafikkbrikker, men betydelig etter at chipene og dens egne binære drivere var først tilgjengelig. For andre brikker har det vært nødvendig å trekke ut fastvaren fra den binære driveren.
For mer nøyaktig informasjon om hvilke brikker som trenger uttrukket fastvare, se https://nouveau.freedesktop.org/VideoAcceleration.html.
Hvis den nødvendige fastvaren er tilgjengelig i nvidia/
mappen over linux fastvare, kopier den
til /lib/firmware/nouveau
.
Hvis fastvaren ikke er gjort tilgjengelig i linux fastvaren, for de gamle brikkene nevnt i nouveau wiki lenken ovenfor kjør følgende kommandoer:
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/
Kjernen liker å laste fastvare for noen nettverksdrivere, spesielt
de fra Realtek (/lib/linux-firmware/rtl_nic/) mappen, men de ser
vanligvis ut til å fungere uten. Derfor kan du starte opp kjernen,
sjekke dmesg for meldinger om denne manglende fastvaren, og hvis
nødvendig last ned fastvaren og legg den i den angitte katalogen i
/lib/firmware
slik at det vil finnes
på neste oppstart. Merk at med nåværende kjerne fungerer dette
uansett om driveren er kompilert eller bygget som en modul, det er
ikke nødvendig å bygge denne fastvaren inn i kjernen. Her er et
eksempel hvor R8169 driveren har blitt kompilert inn men fastvaren
ble ikke gjort tilgjengelig. Når fastvaren ble levert, var det var
ingen omtale av det på senere oppstarter.
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)
Ulike land har ulike regler for radiospekteret brukt av trådløse
enheter. Du kan installere en fastvare for å at trådløse enheter
overholder lokale spektrumforskrifter, så du ikke vil bli forespurt
av lokale myndigheter eller finne ut at det trådløse NIC kortet
blokkerer frekvenser til andre enheter (for eksempel
fjernkontroller). Forskriftsdatabasens fastvare kan lastes ned fra
https://kernel.org/pub/software/network/wireless-regdb/.
For å installere det, bare pakk ut regulatory.db
og regulatory.db.p7s
fra tarballen til /lib/firmware
. Merk at enten cfg80211
driver må velges som en modul for
regulatory.*
filer som skal lastes,
eller må disse filene inkluderes som fastvare i kjernen, som
forklart ovenfor i «Firmware for Skjermkort».
Tilgangspunktet (AP) vil sende en landskode til det trådløse NIC,
og wpa_supplicant-2.11 ville fortelle
kjernen å laste reguleringen av dette landet fra regulatory.db
, og håndhever det. Merk at flere AP
ikke sender denne landskoden, så du kan være låst til en heller
begrenset bruk (spesielt hvis du vil bruke grensesnittet ditt som
en AP).
Noen systemer (spesielt budsjett bærbare datamaskiner) bruker en
DSP som leveres med CPU for tilkobling med lydkodeken. Åpen lyd
fastvare må lastes inn på DSP for å gjøre den funksjonell. Disse
fastvarene filer kan lastes ned fra https://github.com/thesofproject/sof-bin/releases.
Pakk ut tarballen og bytt til den utpakkede mappen, deretter som
root
bruker installer fastvaren:
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 behøver Use Case Manager konfigurasjonsfiler for systemene som bruker Sound Open Firmware også. Les alsa-lib-1.2.13 siden for instruksjoner for å installere dem. Når fastvaren er lastet inn (kan det hende du trenger en omstart slik at kjernen vil laste dem) og UCM konfigurasjonsfilene installeres, følg «Konfigurere ALSA Verktøy» for å sette opp lydkortet ditt for ALSA skikkelig.
Å identifisere riktig firmware vil vanligvis kreve at du
installerer pciutils-3.13.0, og deretter bruke
lspci
for å
identifisere enheten. Du bør deretter søke på nettet for å sjekke
hvilken modul den bruker, hvilken fastvare og hvor du kan få tak i
fastvaren — ikke alt er i linux fastvare.
Hvis det er mulig, bør du begynne med å bruke en kablet tilkobling når du først starter opp LFS systemet. For å bruke en trådløs tilkobling må du bruke et nettverksverktøy som f.eks iw-6.9, Wireless Tools-29, eller wpa_supplicant-2.11.
Fastvare kan også være nødvendig for andre enheter, for eksempel noen SCSI kontrollere, bluetooth adaptere eller TV opptakere. De samme prinsippene gjelder.
Noen drivere, spesielt driverne for ATI eller AMD GPU, krever
fastvarefiler tilgjengelig når den lastes. Den letteste metoden for
å håndtere disse driverne er å bygge dem som en kjernemodul. En
alternativ metode er å lage en initramfs (les «Om initramfs» for
detaljer), inkludert fastvarefilene. Hvis du ikke vil bruke noen av
metodene, kan du inkludere fastvare filer i selve kjernebildet.
Installer de nødvendige fastvarefilene inn i /lib/firmware
først angi følgende
kjernekonfigurasjon og gjenoppbygg kjernen:
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]
Erstatt xx/aa.bin
xx/bb.bin
med en mellomromseparert liste over stier til
de nødvendige fastvare filer, i forhold til /lib/firmware
. En metode enklere enn å manuelt
skrive inn listen (den kan være lang) kjør følgende kommando:
echo CONFIG_EXTRA_FIRMWARE='"'$({ cd /lib/firmware; echo amdgpu/*
})'"' >> .config
make oldconfig
Erstatt amdgpu/*
med et
skallmønster som samsvarer med de nødvendige fastvarefilene.
Ikke distribuer et kjernebilde som inneholder fastvaren til andre da kan du bryte GPL.