mirror of
https://github.com/Zeckmathederg/glfs.git
synced 2025-02-07 17:57:47 +08:00
39eae8f182
Clarify that vulnerabilities are now fixed by AMD supplying an updated AGESA to motherboard manufacturers, for those to update the BIOS.
711 lines
31 KiB
XML
711 lines
31 KiB
XML
<?xml version="1.0" encoding="ISO-8859-1"?>
|
|
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
|
<!ENTITY % general-entities SYSTEM "../../general.ent">
|
|
%general-entities;
|
|
]>
|
|
|
|
<sect1 id="postlfs-firmware" xreflabel="About Firmware">
|
|
<?dbhtml filename="firmware.html"?>
|
|
|
|
|
|
<title>About Firmware</title>
|
|
|
|
<indexterm zone="postlfs-firmware">
|
|
<primary sortas="e-lib-firmware">/lib/firmware</primary>
|
|
</indexterm>
|
|
|
|
<para>
|
|
On some recent PCs it can be necessary, or desirable, to load firmware
|
|
to make them work at their best. There is a directory, <filename
|
|
class="directory">/lib/firmware</filename>, where the kernel or kernel
|
|
drivers look for firmware images.
|
|
</para>
|
|
|
|
<para>
|
|
Currently, most firmware can be found at a <userinput>git</userinput>
|
|
repository: <ulink url=
|
|
"https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/"/>.
|
|
For convenience, the LFS Project has created a mirror, updated daily, where
|
|
these firmware files can be accessed via <userinput>wget</userinput> or a
|
|
web browser at <ulink url="&sources-anduin-http;/linux-firmware/"/>.
|
|
</para>
|
|
|
|
<para>
|
|
To get the firmware, either point a browser to one of the above
|
|
repositories and then download the item(s) which you need, or install
|
|
<xref linkend="git"/> and clone that repository.
|
|
</para>
|
|
|
|
<para>
|
|
For some other firmware, particularly for Intel microcode and certain
|
|
wifi devices, the needed firmware is not available in the above repository.
|
|
Some of this will be addressed below, but a search of the Internet for
|
|
needed firmware is sometimes necessary.
|
|
</para>
|
|
|
|
<para>
|
|
Firmware files are conventionally referred to as blobs because you cannot
|
|
determine what they will do. Note that firmware is distributed under
|
|
various different licenses which do not permit disassembly or
|
|
reverse-engineering.
|
|
</para>
|
|
|
|
<para>
|
|
Firmware for PCs falls into four categories:
|
|
</para>
|
|
|
|
<itemizedlist spacing="compact">
|
|
<listitem>
|
|
<para>
|
|
Updates to the CPU to work around errata, usually referred to as
|
|
microcode.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Firmware for video controllers. On x86 machines this is required for
|
|
ATI devices (Radeon and AMDGPU chips) and may be useful for Intel (Skylake
|
|
and later) and Nvidia (Kepler and later) GPUs.
|
|
</para>
|
|
|
|
<para>
|
|
ATI Radeon and AMDGPU devices all require firmware to be able to use KMS
|
|
(kernel modesetting - the preferred option) as well as for Xorg. For
|
|
old radeon chips (before the R600), the firmware is still in the
|
|
kernel source.
|
|
</para>
|
|
|
|
<para>
|
|
Intel integrated GPUs from Skylake onwards can use firmware for GuC
|
|
(the Graphics microcontroller), and also for the HuC (HEVC/H265
|
|
microcontroller which offloads to the GPU) and the DMC (Display
|
|
Microcontroller) to provide additional low-power states. The GuC and
|
|
HuC have had a chequered history in the kernel and updated firmware
|
|
may be disabled by default, depending on your kernel version. Further
|
|
details may be found at <ulink
|
|
url="https://01.org/linuxgraphics/downloads/firmware/">01.org</ulink>
|
|
and <ulink
|
|
url="https://wiki.archlinux.org/index.php/intel_graphics">Arch
|
|
linux</ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
Nvidia GPUs from Kepler onwards require signed firmware, otherwise the
|
|
nouveau driver is unable to provide hardware acceleration. Nvidia has
|
|
now released firmware up to Ampere (GeForce30 series) to linux-firmware.
|
|
Note that faster clocks than the default are not enabled
|
|
by the released firmware.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Firmware updates for wired network ports. Mostly they work even
|
|
without the updates, but probably they will work better with
|
|
the updated firmware. For some modern laptops, firmware for both
|
|
wired ethernet (e.g. rtl_nic) and also for bluetooth devices (e.g. qca)
|
|
is <emphasis>required</emphasis> before the wired network can be used.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Firmware for other devices, such as wifi. These devices are not
|
|
required for the PC to boot, but need the firmware before these devices
|
|
can be used.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<note>
|
|
<para>
|
|
Although not needed to load a firmware blob, the following
|
|
tools may be useful for determining, obtaining, or preparing the needed
|
|
firmware in order to load it into the system:
|
|
<xref linkend="cpio"/>,
|
|
<xref linkend="git"/>,
|
|
<xref linkend="pciutils"/>, and
|
|
<xref linkend="wget"/>
|
|
</para>
|
|
</note>
|
|
|
|
<para condition="html" role="usernotes">User Notes:
|
|
<ulink url="&blfs-wiki;/aboutfirmware"/></para>
|
|
|
|
<sect2 id="cpu-microcode">
|
|
<title>Microcode updates for CPUs</title>
|
|
|
|
<para>
|
|
In general, microcode can be loaded by the BIOS or UEFI, and it might be
|
|
updated by upgrading to a newer version of those. On linux, you can also
|
|
load the microcode from the kernel if you are using an AMD family 10h or
|
|
later processor (first introduced late 2007), or an Intel processor from
|
|
1998 and later (Pentium4, Core, etc), if updated microcode has been
|
|
released. These updates only last until the machine is powered off, so
|
|
they need to be applied on every boot.
|
|
</para>
|
|
|
|
<para>
|
|
Intel provide updates of their microcode for Skylake and later
|
|
processors as new vulnerabilities come to light, and have in the past
|
|
provided updates for processors from SandyBridge onwards, although those
|
|
are no-longer supported for new fixes. New versions of AMD
|
|
firmware are rare and usually only apply to a few models, although
|
|
motherboard manufacturers get AGESA (AMD Generic Encapsulated Software
|
|
Architecture) updates to change BIOS values, e.g. to support more memory
|
|
variants, new vulnerability fixes or newer CPUs.
|
|
</para>
|
|
|
|
<para>
|
|
There were two ways of loading the microcode, described as 'early' and
|
|
'late'. Early loading happens before userspace has been started, late
|
|
loading happens after userspace has started. However, late loading is
|
|
known to be problematic and not supported anymore (see the kernel commit
|
|
<ulink url="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d23d33e">
|
|
x86/microcode: Taint and warn on late loading</ulink>.) Indeed, early
|
|
loading is needed to work around one particular erratum in early Intel
|
|
Haswell processors which had TSX enabled. (See <ulink url=
|
|
"https://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwelly/">
|
|
Intel Disables TSX Instructions: Erratum Found in Haswell,
|
|
Haswell-E/EP, Broadwell-Y</ulink>.)
|
|
Without this update glibc can do the wrong thing in uncommon
|
|
situations.
|
|
</para>
|
|
|
|
<para>
|
|
In previous versions of this book, late loading of microcode to see if
|
|
it gets applied was recommended, followed by using an initrd to force
|
|
early loading. But now that the contents of the Intel microcode tarball
|
|
is documented, and AMD microcode can be read by a Python script to
|
|
determine which machines it covers, there is no real reason to use late
|
|
loading.
|
|
</para>
|
|
|
|
<para>
|
|
It might be still possible to manually force late loading of microcode.
|
|
But it may cause kernel malfunction and you should take the risk yourself.
|
|
You will need to reconfigure your kernel for either method. The
|
|
instructions here will show you how to create an initrd for early
|
|
loading. It is also possible to build the same microcode bin file into
|
|
the kernel, which allows early loading but requires the kernel to be
|
|
recompiled to update the microcode.
|
|
</para>
|
|
|
|
<para>
|
|
To confirm what processor(s) you have (if more than one, they will be
|
|
identical) look in /proc/cpuinfo. Determine the decimal values of the cpu
|
|
family, model and stepping by running the following command (it will also
|
|
report the current microcode version):
|
|
</para>
|
|
|
|
<screen><userinput>head -n7 /proc/cpuinfo</userinput></screen>
|
|
|
|
<para>
|
|
Convert the cpu family, model and stepping to pairs of hexadecimal
|
|
digits, and remember the value of the <quote>microcode</quote> field.
|
|
You can now check if there is any microcode available.
|
|
</para>
|
|
|
|
<para>
|
|
If you are creating an initrd to update firmware for different machines,
|
|
as a distro would do, go down to 'Early loading of microcode' and cat all
|
|
the Intel blobs to GenuineIntel.bin or cat all the AMD blobs to
|
|
AuthenticAMD.bin. This creates a larger initrd - for all Intel machines in
|
|
the 20200609 update the size was 3.0 MB compared to typically 24 KB for one
|
|
machine.
|
|
</para>
|
|
|
|
<sect3 id="intel-microcode">
|
|
<title>Intel Microcode for the CPU</title>
|
|
|
|
<para>
|
|
The first step is to get the most recent version of the Intel
|
|
microcode. This must be done by navigating to <ulink url=
|
|
'https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/'/>
|
|
and downloading the latest file there. As of this writing the most
|
|
<!-- at one time, some skylakes had problems with a certain revision
|
|
secure version of the microcode, for those machines which can boot it, -->
|
|
secure version of the microcode
|
|
is microcode-20221108.<!-- If you have a Skylake machine, please read the
|
|
Caution in the 'Early loading of microcode' section below.--> Extract this
|
|
file in the normal way, the microcode is in the <filename>intel-ucode
|
|
</filename> directory, containing various blobs with names in the form
|
|
XX-YY-ZZ. There are also various other files, and a releasenote.
|
|
</para>
|
|
|
|
<para>
|
|
In the past, intel did not provide any details of which blobs had
|
|
changed versions, but now the releasenote details this. You can
|
|
compare the microcode version in <filename>/proc/cpuinfo</filename>
|
|
with the version for your CPU model in the releasenote to know if
|
|
there is an update.
|
|
</para>
|
|
|
|
<para>
|
|
The recent firmware for older processors is provided to deal with
|
|
vulnerabilities which have now been made public, and for some of these
|
|
such as Microarchitectural Data Sampling (MDS) you might wish to
|
|
increase the protection by disabling hyperthreading, or alternatively
|
|
to disable the kernel's default mitigation because of its impact on
|
|
compile times. Please read the online documentation at <ulink url=
|
|
'https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html'/>.
|
|
</para>
|
|
|
|
<para>
|
|
For an Icelake mobile (described as Intel(R) Core(TM) i7-1065G7
|
|
CPU) the relevant values are cpu family 6, model 126, stepping 5 so
|
|
in this case the required identification is 06-7e-05. The
|
|
releasenote says the latest microcode for it is versioned 0xb6. If
|
|
the value of the <quote>microcode</quote> field in
|
|
<filename>/proc/cpuinfo</filename> is 0xb6 or greater, it indicates
|
|
the microcode update is already applied by the BIOS. Otherwise,
|
|
configure the kernel to support loading Intel microcode, and then
|
|
proceed to <xref linkend='early-microcode'/>:
|
|
</para>
|
|
|
|
<screen><literal>General Setup --->
|
|
[*] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
|
|
Processor type and features --->
|
|
[*] CPU microcode loading support [CONFIG_MICROCODE]
|
|
[*] Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen>
|
|
|
|
</sect3>
|
|
|
|
<sect3 id="amd-microcode">
|
|
<title>AMD Microcode for the CPU</title>
|
|
|
|
<para>
|
|
Begin by downloading a container of firmware for your CPU family
|
|
from <ulink url=
|
|
'&sources-anduin-http;/linux-firmware/amd-ucode/'/>.
|
|
The family is always specified in hex. Families 10h to 14h (16 to 20)
|
|
are in microcode_amd.bin. Families 15h, 16h, 17h (Zen, Zen+, Zen2) and
|
|
19h (Zen3) have their own containers, but very few machines are likely to
|
|
get updated microcode. Instead, AMD provide an updated AGESA to the
|
|
motherboard makers, who may provide an updated BIOS using this.
|
|
There is a Python3 script at <ulink url=
|
|
'https://github.com/AMDESE/amd_ucode_info/blob/master/amd_ucode_info.py'/>.
|
|
Download that script and run it against the bin file to check which
|
|
processors have updates.
|
|
</para>
|
|
|
|
<para>
|
|
For the very old Athlon(tm) II X2 in these examples the values were
|
|
cpu family 16, model 5, stepping 3 giving an identification of
|
|
Family=0x10 Model=0x05 Stepping=0x03. One line of the
|
|
<command>amd_ucode_info.py</command> script output describes the
|
|
microcode version for it:
|
|
</para>
|
|
|
|
<screen><computeroutput>Family=0x10 Model=0x05 Stepping=0x03: Patch=0x010000c8 Length=960 bytes</computeroutput></screen>
|
|
|
|
<para>
|
|
If the value of the <quote>microcode</quote> field in
|
|
<filename>/proc/cpuinfo</filename> is 0x10000c8 or greater, it
|
|
indicates the BIOS has already applied the microcode update.
|
|
Otherwise, configure the kernel to support loading AMD microcode,
|
|
and then proceed to <xref linkend='early-microcode'/>:
|
|
</para>
|
|
|
|
<screen><literal>General Setup --->
|
|
[*] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
|
|
Processor type and features --->
|
|
[*] CPU microcode loading support [CONFIG_MICROCODE]
|
|
[*] AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen>
|
|
</sect3>
|
|
|
|
<sect3 id="early-microcode">
|
|
<title>Early loading of microcode</title>
|
|
|
|
<para>
|
|
If you have established that updated microcode is available for
|
|
your system, it is time to prepare it for early loading. This requires
|
|
an additional package, <xref linkend='cpio'/> and the creation of an
|
|
initrd which will need to be added to grub.cfg.
|
|
</para>
|
|
|
|
<para>
|
|
It does not matter where you prepare the initrd, and once it is
|
|
working you can apply the same initrd to later LFS systems or newer
|
|
kernels on this same machine, at least until any newer microcode is
|
|
released. Use the following commands:
|
|
</para>
|
|
|
|
<screen><userinput>mkdir -p initrd/kernel/x86/microcode
|
|
cd initrd</userinput></screen>
|
|
|
|
<para>
|
|
For an AMD machine, use the following command (replace
|
|
<MYCONTAINER> with the name of the container for your CPU's
|
|
family):
|
|
</para>
|
|
|
|
<screen><userinput>cp -v ../<MYCONTAINER> kernel/x86/microcode/AuthenticAMD.bin</userinput></screen>
|
|
|
|
<para>
|
|
Or for an Intel machine copy the appropriate blob using this command:
|
|
</para>
|
|
|
|
<screen><userinput>cp -v ../intel-ucode/<XX-YY-ZZ> kernel/x86/microcode/GenuineIntel.bin</userinput></screen>
|
|
|
|
<!-- new version from 20201110 release onwards, assumed to work on all skylakes
|
|
But complaints about previous version took some days to appear, so keep as a comment for now.
|
|
<caution>
|
|
<para>
|
|
On some Skylake machines with hex Model Number '4e' (78 decimal) the
|
|
upgrade to microcode version '0xdc' is reported to cause the machine to
|
|
hang in early boot, and the fix is to revert to version 0xd6 which was
|
|
first shipped in the 20191115 microcode release.
|
|
</para>
|
|
|
|
<para>
|
|
At least one model '5e' Skylake does boot successfully with version
|
|
0xdc, but Intel has now shipped a 20200616 release which is intended for
|
|
distros which need an initrd that will boot on everyone's machine: it
|
|
reverts both Skylake variants ('4e' and '5e') to the old 0xd6.
|
|
</para>
|
|
|
|
<para>
|
|
For a Skylake which does not boot with 0xdc, reverting to 0xd6 will make
|
|
the machine usable, but without the SRBDS mitigations.
|
|
</para>
|
|
</caution>-->
|
|
|
|
<para>
|
|
Now prepare the initrd:
|
|
</para>
|
|
|
|
<screen><userinput>find . | cpio -o -H newc > /boot/microcode.img</userinput></screen>
|
|
|
|
<para>
|
|
You now need to add a new entry to /boot/grub/grub.cfg and
|
|
here you should add a new line after the linux line within the stanza.
|
|
If /boot is a separate mountpoint:
|
|
</para>
|
|
|
|
<screen><userinput>initrd /microcode.img</userinput></screen>
|
|
|
|
<para>
|
|
or this if it is not:
|
|
</para>
|
|
|
|
<screen><userinput>initrd /boot/microcode.img</userinput></screen>
|
|
|
|
<para>
|
|
If you are already booting with an initrd (see <xref
|
|
linkend="initramfs"/>), you should run <command>mkinitramfs</command>
|
|
again after putting the appropriate blob or container into <filename
|
|
class="directory">/lib/firmware</filename>. More precisely, put an
|
|
intel blob in a <filename
|
|
class="directory">/lib/firmware/intel-ucode</filename> directory
|
|
or an AMD container in a <filename
|
|
class="directory">/lib/firmware/amd-ucode</filename> directory before
|
|
running <command>mkinitramfs</command>.
|
|
Alternatively, you can have both initrd on the same line, such as
|
|
<userinput>initrd /microcode.img /other-initrd.img</userinput> (adapt
|
|
that as above if /boot is not a separate mountpoint).
|
|
</para>
|
|
|
|
<para>
|
|
You can now reboot with the added initrd, and then use the following
|
|
command to check that the early load worked:
|
|
</para>
|
|
|
|
<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
|
|
|
|
<para>
|
|
If you updated to address vulnerabilities, you can look at the
|
|
output of the <command>lscpu</command> command to see what is now
|
|
reported.
|
|
</para>
|
|
|
|
<para>
|
|
The places and times where early loading happens are very different
|
|
in AMD and Intel machines. First, an example of an Intel (Icelake
|
|
mobile) with early loading:
|
|
</para>
|
|
|
|
<screen><literal>[ 0.000000] microcode: microcode updated early to revision 0xb6, date = 2022-08-02
|
|
[ 0.000000] Linux version 6.1.6 (xry111@xry111-X57S1) (gcc (GCC) 12.2.0, GNU ld (GNU Binutils) 2.40) #32 SMP PREEMPT_DYNAMIC Sat Jan 28 11:32:21 CST 2023
|
|
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.1.6-lfs-r11.2-34-systemd root=/dev/nvme0n1p7 ro
|
|
[ 0.454985] microcode: sig=0x706e5, pf=0x80, revision=0xb6
|
|
[ 0.455011] microcode: Microcode Update Driver: v2.2.</literal></screen>
|
|
|
|
|
|
<para>
|
|
A historic AMD example:
|
|
</para>
|
|
|
|
<screen><literal>[ 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.</literal></screen>
|
|
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="video-firmware">
|
|
<title>Firmware for Video Cards</title>
|
|
|
|
<sect3 id="ati-video-firmware">
|
|
<title>Firmware for ATI video chips (R600 and later)</title>
|
|
|
|
<para>
|
|
These instructions do NOT apply to old radeons before the R600
|
|
family. For those, the firmware is in the kernel's <filename
|
|
class='directory'>/lib/firmware/</filename> directory. Nor do they
|
|
apply if you intend to avoid a graphical setup such as Xorg and are
|
|
content to use the default 80x25 display rather than a framebuffer.
|
|
</para>
|
|
|
|
<para>
|
|
Early radeon devices only needed a single 2K blob of firmware. Recent
|
|
devices need several different blobs, and some of them are much bigger.
|
|
The total size of the radeon firmware directory is over 500K —
|
|
on a large modern system you can probably spare the space, but it is
|
|
still redundant to install all the unused files each time you build
|
|
a system.
|
|
</para>
|
|
|
|
<para>
|
|
A better approach is to install <xref linkend='pciutils'/> and then
|
|
use <userinput>lspci</userinput> to identify which VGA controller is
|
|
installed.
|
|
</para>
|
|
|
|
<para>
|
|
With that information, check the RadeonFeature page of the Xorg wiki
|
|
for <ulink url="https://wiki.x.org/wiki/RadeonFeature/#index5h2">Decoder
|
|
ring for engineering vs marketing names</ulink> to identify the family
|
|
(you may need to know this for the Xorg driver in BLFS —
|
|
Southern Islands and Sea Islands use the radeonsi driver) and the
|
|
specific model.
|
|
</para>
|
|
|
|
<para>
|
|
Now that you know which controller you are using, consult the
|
|
<ulink url="https://wiki.gentoo.org/wiki/Radeon#Firmware">
|
|
Radeon</ulink> page of the Gentoo wiki which has a table listing
|
|
the required firmware blobs for the various chipsets. Note that
|
|
Southern Islands and Sea Islands chips use different firmware for
|
|
kernel 3.17 and later compared to earlier kernels. Identify and
|
|
download the required blobs then install them:
|
|
</para>
|
|
|
|
<screen><userinput>mkdir -pv /lib/firmware/radeon
|
|
cp -v <YOUR_BLOBS> /lib/firmware/radeon</userinput></screen>
|
|
|
|
<para>
|
|
There are actually two ways of installing this firmware. BLFS, in the
|
|
'Kernel Configuration for additional firmware' section part of the
|
|
<xref linkend="xorg-ati-driver"/> section gives an example of
|
|
compiling the firmware into the kernel - that is slightly faster to
|
|
load, but uses more kernel memory. Here we will use the alternative
|
|
method of making the radeon driver a module. In your kernel config
|
|
set the following:
|
|
</para>
|
|
|
|
<screen><literal>Device Drivers --->
|
|
Graphics support --->
|
|
Direct Rendering Manager --->
|
|
[*] Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
|
|
[M] ATI Radeon [CONFIG_DRM_RADEON]</literal></screen>
|
|
|
|
<para>
|
|
Loading several large blobs from /lib/firmware takes a noticeable
|
|
time, during which the screen will be blank. If you do not enable the
|
|
penguin framebuffer logo, or change the console size by using a bigger
|
|
font, that probably does not matter. If desired, you can slightly
|
|
reduce the time if you follow the alternate method of specifying 'y'
|
|
for CONFIG_DRM_RADEON covered in BLFS at the link above — you
|
|
must specify each needed radeon blob if you do that.
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3 id="amdgpu-video-firmware">
|
|
<title>Firmware for AMD/ATI amdgpu video chips</title>
|
|
|
|
<para>
|
|
All video controllers using the amdgpu kernel driver require firmware,
|
|
whether you will be using the xorg amdgpu driver, the xserver's modesetting
|
|
driver, or just kernel modesetting to get a console framebuffer larger than
|
|
80x25.
|
|
</para>
|
|
|
|
<para>
|
|
Install <xref linkend="pciutils"/> and use that to check the model name
|
|
(look for 'VGA compatible controller:'). If you have an APU (Accelerated
|
|
Processing Unit, i.e. CPU and video on the same chip) that will probably
|
|
tell you the name. If you have a separate amdgpu video card you will need
|
|
to search to determine which name it uses (e.g. a card described as
|
|
Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 550 640SP / RX
|
|
560/560X] needs Polaris11 firmware. There is a table of "Family, Chipset
|
|
name, Product name and Firmware" at the end of the Kernel sections in
|
|
<ulink url="https://wiki.gentoo.org/wiki/AMDGPU#Known_firmware_blobs">
|
|
AMDGPU</ulink> page of the Gentoo wiki.
|
|
</para>
|
|
|
|
<para>
|
|
Once you have identified the firmware name, install all the relevant
|
|
files for it. For example, the Baffin card mentioned above has 21 different
|
|
polaris11* files, APUs such as renoir and picasso have at least 12 files and
|
|
might gain more in future updates (e.g. the raven APU now has a 13th file,
|
|
raven_ta.bin).
|
|
</para>
|
|
|
|
<screen><userinput>mkdir -pv /lib/firmware/amdgpu
|
|
cp -v <YOUR_BLOBS> /lib/firmware/amdgpu</userinput></screen>
|
|
|
|
<para>
|
|
If disk space is not a problem, you could install all the current amdgpu
|
|
firmware files and not worry about exactly which chipset is installed.
|
|
</para>
|
|
|
|
<para>
|
|
Building the kernel amdgpu driver as a module is recommended.
|
|
In your kernel .config set at least the following options and review
|
|
the other AMDGPU options according to your target hardware,
|
|
for example "ACP (Audio Co-Processor) Configuration":
|
|
</para>
|
|
|
|
<screen><literal>Device Drivers --->
|
|
Graphics support --->
|
|
Direct Rendering Manager --->
|
|
[*] Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
|
|
[M] AMD GPU [CONFIG_DRM_AMDGPU]
|
|
Display Engine Configuration --->
|
|
[*] AMD DC - Enable new display engine (NEW) [CONFIG_DRM_AMD_DC]</literal></screen>
|
|
|
|
<para>
|
|
As written above at the end of the section on 'Firmware for ATI video
|
|
chips', loading large blobs from /lib/firmware can take a noticeable
|
|
time during which the screen will be blank. On a slow machine you might
|
|
wish to refer to the 'Kernel Configuration for additional firmware'
|
|
part of <xref linkend="xorg-amdgpu-driver"/> and compile all the
|
|
required modules into the kernel to reduce this time, at the cost of
|
|
using more kernel memory.
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3 id="nvidia-video-firmware">
|
|
<title>Firmware for Nvidia video chips</title>
|
|
|
|
<para>
|
|
Nvidia has released basic signed firmware for recent graphics chips,
|
|
but significantly after the chips and its own binary drivers were first
|
|
available. For other chips it has been necessary to extract the firmware
|
|
from the binary driver.
|
|
</para>
|
|
<para>
|
|
For more exact information about which chips need extracted firmware, see
|
|
<ulink url=
|
|
"https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware"/>.
|
|
</para>
|
|
|
|
<para>
|
|
First, the kernel Nvidia driver must be activated:
|
|
</para>
|
|
|
|
<screen><literal>Device Drivers --->
|
|
Graphics support --->
|
|
Direct Rendering Manager --->
|
|
<*> Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
|
|
<*/M> Nouveau (NVIDIA) cards [CONFIG_DRM_NOUVEAU]</literal></screen>
|
|
|
|
<para>
|
|
If the necessary firmware is available in the
|
|
<filename class="directory">nvidia/</filename> directory of
|
|
linux-firmware, copy it to
|
|
<filename class="directory">/lib/firmware/nouveau</filename>.
|
|
</para>
|
|
<para>
|
|
If the firmware has not been made available in linux-firmware,
|
|
for the old chips mentioned in the nouveau wiki link above ensure you have
|
|
installed <xref linkend="python2"/> and run the following commands:
|
|
</para>
|
|
|
|
<!-- Someone please port this to Python 3. -->
|
|
<screen><userinput>wget https://raw.github.com/imirkin/re-vp2/master/extract_firmware.py
|
|
wget https://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86-325.15.run
|
|
sh NVIDIA-Linux-x86-325.15.run --extract-only
|
|
python2 extract_firmware.py
|
|
mkdir -p /lib/firmware/nouveau
|
|
cp -d nv* vuc-* /lib/firmware/nouveau/</userinput></screen>
|
|
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2 id="nic-firmware">
|
|
<title>Firmware for Network Interfaces</title>
|
|
|
|
<para>
|
|
The kernel likes to load firmware for some network drivers, particularly
|
|
those from Realtek (the /lib/linux-firmware/rtl_nic/) directory, but
|
|
they generally appear to work without it. Therefore, you can boot the
|
|
kernel, check dmesg for messages about this missing firmware, and if
|
|
necessary download the firmware and put it in the specified directory in
|
|
<filename class="directory">/lib/firmware</filename> so that it will
|
|
be found on subsequent boots. Note that with current kernels this
|
|
works whether or not the driver is compiled in or built as a module,
|
|
there is no need to build this firmware into the kernel.
|
|
Here is an example where the R8169 driver has been compiled in but the
|
|
firmware was not made available. Once the firmware had been provided,
|
|
there was no mention of it on later boots.
|
|
</para>
|
|
|
|
<screen><literal>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)</literal></screen>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="other-firmware">
|
|
<title>Firmware for Other Devices</title>
|
|
|
|
<para>
|
|
Identifying the correct firmware will typically require you to install
|
|
<xref linkend='pciutils'/>, and then use <userinput>lspci</userinput>
|
|
to identify the device. You should then search online to check which
|
|
module it uses, which firmware, and where to obtain the firmware —
|
|
not all of it is in linux-firmware.
|
|
</para>
|
|
|
|
<para>
|
|
If possible, you should begin by using a wired connection when you first
|
|
boot your LFS system. To use a wireless connection you will need to
|
|
use a network tools such as <xref linkend='wireless_tools'/> and <xref
|
|
linkend='wpa_supplicant'/>.
|
|
</para>
|
|
|
|
<para>
|
|
Different countries have different regulations on the radio spectrum
|
|
usage of wireless devices. You can install a firmware to make the
|
|
wireless devices obey local spectrum regulations, so you won't be
|
|
inquired by local authority or find your wireless NIC jamming the
|
|
frequencies of other devices (for example, remote controllers).
|
|
The regulatory database firmware can be downloaded from
|
|
<ulink url = 'https://kernel.org/pub/software/network/wireless-regdb/'/>.
|
|
To install it, simply extract <filename>regulatory.db</filename> and
|
|
<filename>regulatory.db.p7s</filename> from the tarball into
|
|
<filename class="directory">/lib/firmware</filename>.
|
|
The access point would send a country code to your wireless NIC,
|
|
and <xref linkend='wpa_supplicant'/> would tell the kernel to load
|
|
the regulation of this country from
|
|
<filename>regulatory.db</filename>, and enforce it.
|
|
</para>
|
|
|
|
<para>
|
|
Firmware may also be needed for other devices such as some SCSI
|
|
controllers, bluetooth adaptors, or TV recorders. The same principles
|
|
apply.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|