source: postlfs/config/firmware.xml@ 81a73ed8

10.0 10.1 11.0 11.1 11.2 11.3 ken/inkscape-core-mods lazarus plabs/python-mods qt5new trunk upgradedb xry111/intltool xry111/soup3 xry111/test-20220226
Last change on this file since 81a73ed8 was 81a73ed8, checked in by Pierre Labastie <pieere@…>, 3 years ago

Format postlfs config

git-svn-id: svn:// af4574ff-66df-0310-9fd7-8a98e5e911e0

  • Property mode set to 100644
File size: 24.9 KB
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3 "" [
4 <!ENTITY % general-entities SYSTEM "../../general.ent">
5 %general-entities;
8<sect1 id="postlfs-firmware" xreflabel="About Firmware">
9 <?dbhtml filename="firmware.html"?>
11 <sect1info>
12 <othername>$LastChangedBy$</othername>
13 <date>$Date$</date>
14 </sect1info>
16 <title>About Firmware</title>
18 <indexterm zone="postlfs-firmware">
19 <primary sortas="e-lib-firmware">/lib/firmware</primary>
20 </indexterm>
22 <para>
23 On some recent PCs it can be necessary, or desirable, to load firmware
24 to make them work at their best. There is a directory, <filename
25 class="directory">/lib/firmware</filename>, where the kernel or kernel
26 drivers look for firmware images.
27 </para>
29 <para>
30 Preparing firmware for multiple different machines, as a distro would
31 do, is outside the scope of this book.
32 </para>
34 <para>
35 Currently, most firmware can be found at a <userinput>git</userinput>
36 repository: <ulink url=
37 ""/>.
38 For convenience, the LFS Project has created a mirror, updated daily, where
39 these firmware files can be accessed via <userinput>wget</userinput> or a
40 web browser at <ulink url="&sources-anduin-http;/linux-firmware/"/>.
41 </para>
43 <para>
44 To get the firmware, either point a browser to one of the above
45 repositories and then download the item(s) which you need, or install
46 <xref linkend="git"/> and clone that repository.
47 </para>
49 <para>
50 For some other firmware, particularly for Intel microcode and certain
51 wifi devices, the needed firmware is not available in the above repository.
52 Some of this will be addressed below, but a search of the Internet for
53 needed firmware is sometimes necessary.
54 </para>
56 <para>
57 Firmware files are conventionally referred to as blobs because you cannot
58 determine what they will do. Note that firmware is distributed under
59 various different licenses which do not permit disassembly or
60 reverse-engineering.
61 </para>
63 <para>
64 Firmware for PCs falls into four categories:
65 </para>
67 <itemizedlist spacing="compact">
68 <listitem>
69 <para>
70 Updates to the CPU to work around errata, usually referred to as
71 microcode.
72 </para>
73 </listitem>
74 <listitem>
75 <para>
76 Firmware for video controllers. On x86 machines this seems to mostly
77 apply to ATI devices (Radeon and AMDGPU chips) and Nvidia Maxwell
78 and Pascal cards which all require firmware to be able to use KMS
79 (kernel modesetting - the preferred option) as well as for Xorg. For
80 earlier radeon chips (before the R600), the firmware is still in the
81 kernel.
82 </para>
83 </listitem>
84 <listitem>
85 <para>
86 Firmware updates for wired network ports. Mostly they work even
87 without the updates, but probably they will work better with
88 the updated firmware. For some modern laptops, firmware for both
89 wired ethernet (e.g. rtl_nic) and also for bluetooth devices (e.g. qca)
90 is <emphasis>required</emphasis> before the wired network can be used.
91 </para>
92 </listitem>
93 <listitem>
94 <para>
95 Firmware for other devices, such as wifi. These devices are not
96 required for the PC to boot, but need the firmware before these devices
97 can be used.
98 </para>
99 </listitem>
100 </itemizedlist>
102 <note>
103 <para>
104 Although not needed to load a firmware blob, the following
105 tools may be useful for determining, obtaining, or preparing the needed
106 firmware in order to load it into the system:
107 <xref linkend="cpio"/>,
108 <xref linkend="git"/>,
109 <xref linkend="pciutils"/>, and
110 <xref linkend="wget"/>
111 </para>
112 </note>
114 <para condition="html" role="usernotes">User Notes:
115 <ulink url="&blfs-wiki;/aboutfirmware"/></para>
117 <sect2 id="cpu-microcode">
118 <title>Microcode updates for CPUs</title>
120 <para>
121 In general, microcode can be loaded by the BIOS or UEFI, and it might be
122 updated by upgrading to a newer version of those. On linux, you can also
123 load the microcode from the kernel if you are using an AMD family 10h or
124 later processor (first introduced late 2007), or an Intel processor from
125 1998 and later (Pentium4, Core, etc), if updated microcode has been
126 released. These updates only last until the machine is powered off, so
127 they need to be applied on every boot.
128 </para>
130 <para>
131 Intel provide updates of their microcode for SandyBridge and later
132 processors as new vulnerabilities come to light. New versions of AMD
133 firmware are rare and usually only apply to a few models, although
134 motherboard manufacturers get extra updates which maybe update microcode
135 along with the changes to support newer CPUs and faster memory.
136 </para>
138 <para>
139 There are two ways of loading the microcode, described as 'early' and
140 'late'. Early loading happens before userspace has been started, late
141 loading happens after userspace has started. Not surprisingly, early
142 loading is preferred, (see e.g. an explanatory comment in a kernel
143 commit noted at <ulink url="">
144 x86/microcode: Early load microcode</ulink> on LWN.) Indeed, it
145 is needed to work around one particular erratum in early Intel Haswell
146 processors which had TSX enabled. (See <ulink url=
147 "">
148 Intel Disables TSX Instructions: Erratum Found in Haswell,
149 Haswell-E/EP, Broadwell-Y
150 </ulink>.) Without this update glibc can do the wrong thing in uncommon
151 situations.
152 </para>
154 <para>
155 It is still possible to manually force late loading of microcode, either
156 for testing or to prevent having to reboot. You will need to reconfigure
157 your kernel for either method. The instructions here will create a
158 kernel <filename>.config</filename> to suite early loading, before
159 forcing late loading to see if there is any microcode. If there is,
160 the instructions then show you how to create an initrd for early loading.
161 </para>
163 <para>
164 To confirm what processor(s) you have (if more than one, they will be
165 identical) look in /proc/cpuinfo.
166 </para>
168 <sect3 id="intel-microcode">
169 <title>Intel Microcode for the CPU</title>
171 <para>
172 The first step is to get the most recent version of the Intel
173 microcode. This must be done by navigating to <ulink url=
174 ''/>
175 and downloading the latest file there. As of this writing the most
176 recent version of the microcode is microcode-20191115. Extract this
177 file in the normal way, the microcode is in the <filename>intel-ucode
178 </filename> directory, containing various blobs with names in the form
179 XX-YY-ZZ. There are also various other files, and a releasenote.
180 </para>
182 <para>
183 In the past, intel did not provide any details of which blobs had
184 changed versions, but now the release note details this.
185 </para>
187 <para>
188 The recent firmware for older processors is provided to deal with
189 vulnerabilities which have now been made public, and for some of these
190 such as Microarchitectural Data Sampling (MDS) you might wish to
191 increase the protection by disabling hyperthreading, or alternatively
192 to disable the kernel's default mitigation because of its impact on
193 compile times. Please read the online documentation at <ulink url=
194 ''/>.
195 </para>
197 <para>
198 To be able to use this latest microcode to provide mitigation on all
199 the affected processors, the kernel version needs to be at least 5.3.11
200 (or 4.19.84 if you are using the 4.19 long term support series).
201 </para>
203 <para>
204 Now you need to determine your processor's identity to see if there
205 is any microcode for it. Determine the decimal values of the cpu family,
206 model and stepping by running the following command (it will also report
207 the current microcode version):
208 </para>
210<screen><userinput>head -n7 /proc/cpuinfo</userinput></screen>
212 <para>
213 Convert the cpu family, model and stepping to pairs of hexadecimal
214 digits. For a Skylake i3 6100 (described as Intel(R) Core(TM) i3-6100
215 CPU) the relevant values are cpu family 6, model 94, stepping 3 so in
216 this case the required identification is 06-5e-03. A look at the blobs
217 will show that there is one for this CPU (although for older issues it
218 might have already been applied by the BIOS). If there is a blob for
219 your system then test if it will be applied by copying it (replace
220 &lt;XX-YY-ZZ&gt; by the identifier for your CPU) to where the
221 kernel can find it:
222 </para>
224<screen><userinput>mkdir -pv /lib/firmware/intel-ucode
225cp -v intel-ucode/&lt;XX-YY-ZZ&gt; /lib/firmware/intel-ucode</userinput></screen>
227 <para>
228 Now that the Intel microcode has been prepared, use the following
229 options when you configure the kernel to load Intel microcode:
230 </para>
232<screen><literal>General Setup ---&gt;
233 [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
234Processor type and features ---&gt;
235 [y] CPU microcode loading support [CONFIG_MICROCODE]
236 [y] Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen>
238 <para>
239 After you have successfully booted the new system, force late loading
240 by using the command:
241 </para>
243<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
245 <para>
246 Then use the following command to see if anything was loaded:
247 </para>
249<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
251 <para>
252 This reformatted example was created by temporarily booting without
253 microcode, to show the current Firmware Bug message, then the late load
254 shows it being updated to revision 0xd6.
255 </para>
257<screen><literal>[ 0.000000] Linux version 5.4.2 (lfs@leshp) (gcc version 9.2.0 (GCC))
258 #1 SMP PREEMPT Wed Dec 18 11:52:13 GMT 2019
259[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.4.2-sda11 root=/dev/sda11 ro
260[ 0.020218] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode
261 to version: 0xb2 (or later)
262[ 0.153861] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
263[ 0.550009] microcode: sig=0x506e3, pf=0x2, revision=0x74
264[ 0.550036] microcode: Microcode Update Driver: v2.2.
265[ 277.673064] microcode: updated to revision 0xd6, date = 2019-10-03
266[ 277.674231] x86/CPU: CPU features have changed after loading microcode, but might not take effect</literal></screen>
268 <para>
269 If the microcode was not updated, there is no new microcode for this
270 system's processor. If it did get updated, you can now proceed to
271 <xref linkend='early-microcode'/>.
272 </para>
274 </sect3>
276 <sect3 id="and-microcode">
277 <title>AMD Microcode for the CPU</title>
279 <para>
280 Begin by downloading a container of firmware for your CPU family
281 from <ulink url=
282 '&sources-anduin-http;/linux-firmware/amd-ucode/'/>.
283 The family is always specified in hex. Families 10h to 14h (16 to 20)
284 are in microcode_amd.bin. Families 15h, 16h and 17h have their own
285 containers. Create the required directory and put the firmware you
286 downloaded into it as the <systemitem
287 class="username">root</systemitem> user:
288 </para>
290<screen><userinput>mkdir -pv /lib/firmware/amd-ucode
291cp -v microcode_amd* /lib/firmware/amd-ucode</userinput></screen>
293 <para>
294 When you configure the kernel, use the following options
295 to load AMD microcode:
296 </para>
298<screen><literal>General Setup ---&gt;
299 [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
300Processor type and features ---&gt;
301 [y] CPU microcode loading support [CONFIG_MICROCODE]
302 [y] AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen>
304 <para>
305 After you have successfully booted the new system, force late loading
306 by using the command:
307 </para>
309<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
311 <para>
312 Then use the following command to see if anything was loaded:
313 </para>
315<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
316 <para>
317 This historic example from an old Athlon(tm) II X2 shows it has been
318 updated. At that time, all CPUs were still reported in the microcode
319 details on AMD machines (the current position for AMD machines where
320 newer microcode is available is unknown) :
321 </para>
323<screen><literal>[ 0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
324 #1 SMP Sun Feb 18 02:08:12 GMT 2018
325[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.3-sda5 root=/dev/sda5 ro
326[ 0.307619] microcode: CPU0: patch_level=0x010000b6
327[ 0.307671] microcode: CPU1: patch_level=0x010000b6
328[ 0.307743] microcode: Microcode Update Driver: v2.2.
329[ 187.928891] microcode: CPU0: new patch_level=0x010000c8
330[ 187.928899] microcode: CPU1: new patch_level=0x010000c8</literal></screen>
332 <para>
333 If the microcode was not updated, there is no new microcode for
334 this system's processor. If it did get updated, you can now proceed to
335 <xref linkend='early-microcode'/>.
336 </para>
338 </sect3>
340 <sect3 id="early-microcode">
341 <title>Early loading of microcode</title>
343 <para>
344 If you have established that updated microcode is available for
345 your system, it is time to prepare it for early loading. This requires
346 an additional package, <xref linkend='cpio'/> and the creation of an
347 initrd which will need to be added to grub.cfg.
348 </para>
350 <para>
351 It does not matter where you prepare the initrd, and once it is
352 working you can apply the same initrd to later LFS systems or newer
353 kernels on this same machine, at least until any newer microcode is
354 released. Use the following commands:
355 </para>
357<screen><userinput>mkdir -p initrd/kernel/x86/microcode
358cd initrd</userinput></screen>
360 <para>
361 For an AMD machine, use the following command (replace
362 &lt;MYCONTAINER&gt; with the name of the container for your CPU's
363 family):
364 </para>
366<screen><userinput>cp -v /lib/firmware/amd-ucode/&lt;MYCONTAINER&gt; kernel/x86/microcode/AuthenticAMD.bin</userinput></screen>
368 <para>
369 Or for an Intel machine copy the appropriate blob using this command:
370 </para>
372<screen><userinput>cp -v /lib/firmware/intel-ucode/&lt;XX-YY-ZZ&gt; kernel/x86/microcode/GenuineIntel.bin</userinput></screen>
374 <para>
375 Now prepare the initrd:
376 </para>
378<screen><userinput>find . | cpio -o -H newc &gt; /boot/microcode.img</userinput></screen>
380 <para>
381 You now need to add a new entry to /boot/grub/grub.cfg and
382 here you should add a new line after the linux line within the stanza.
383 If /boot is a separate mountpoint:
384 </para>
386<screen><userinput>initrd /microcode.img</userinput></screen>
388 <para>
389 or this if it is not:
390 </para>
392<screen><userinput>initrd /boot/microcode.img</userinput></screen>
394 <para>
395 If you are already booting with an initrd (see <xref
396 linkend="initramfs"/>), you should run <command>mkinitramfs</command>
397 again after putting the appropriate blob or container into <filename
398 class="directory">/lib/firmware</filename> as explained above.
399 Alternatively, you can have both initrd on the same line, such as
400 <userinput>initrd /microcode.img /other-initrd.img</userinput> (adapt
401 that as above if /boot is not a separate mountpoint).
402 </para>
404 <para>
405 You can now reboot with the added initrd, and then use the same
406 command to check that the early load worked:
407 </para>
409<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
411 <para>
412 If you updated to address vulnerabilities, you can look at <filename
413 class="directory">/sys/devices/system/cpu/vulnerabilities/</filename>
414 to see what is now reported.
415 </para>
417 <para>
418 The places and times where early loading happens are very different
419 in AMD and Intel machines. First, an Intel example with early loading:
420 </para>
422<screen><literal>[ 0.000000] microcode: microcode updated early to revision 0xd6, date = 2019-10-03
423[ 0.000000] Linux version 5.4.6 (ken@leshp) (gcc version 9.2.0 (GCC))i
424 #4 SMP PREEMPT Sat Dec 21 21:41:03 GMT 2019
425[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.4.6-sda11 root=/dev/sda11 ro resume=/dev/sda10
426[ 0.579936] microcode: sig=0x506e3, pf=0x2, revision=0xd6
427[ 0.579961] microcode: Microcode Update Driver: v2.2.</literal></screen>
429 <para>
430 A historic AMD example:
431 </para>
433<screen><literal>[ 0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
434 #2 SMP Sun Feb 18 02:32:03 GMT 2018
435[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.3-sda5 root=/dev/sda5 ro
436[ 0.307619] microcode: microcode updated early to new patch_level=0x010000c8
437[ 0.307678] microcode: CPU0: patch_level=0x010000c8
438[ 0.307723] microcode: CPU1: patch_level=0x010000c8
439[ 0.307795] microcode: Microcode Update Driver: v2.2.</literal></screen>
441 </sect3>
443 </sect2>
445 <sect2 id="video-firmware">
446 <title>Firmware for Video Cards</title>
448 <sect3 id="ati-video-firmware">
449 <title>Firmware for ATI video chips (R600 and later)</title>
451 <para>
452 These instructions do NOT apply to old radeons before the R600
453 family. For those, the firmware is in the kernel's <filename
454 class='directory'>/lib/firmware/</filename> directory. Nor do they
455 apply if you intend to avoid a graphical setup such as Xorg and are
456 content to use the default 80x25 display rather than a framebuffer.
457 </para>
459 <para>
460 Early radeon devices only needed a single 2K blob of firmware. Recent
461 devices need several different blobs, and some of them are much bigger.
462 The total size of the radeon firmware directory is over 500K &mdash;
463 on a large modern system you can probably spare the space, but it is
464 still redundant to install all the unused files each time you build
465 a system.
466 </para>
468 <para>
469 A better approach is to install <xref linkend='pciutils'/> and then
470 use <userinput>lspci</userinput> to identify which VGA controller is
471 installed.
472 </para>
474 <para>
475 With that information, check the RadeonFeature page of the Xorg wiki
476 for <ulink url="">Decoder
477 ring for engineering vs marketing names</ulink> to identify the family
478 (you may need to know this for the Xorg driver in BLFS &mdash;
479 Southern Islands and Sea Islands use the radeonsi driver) and the
480 specific model.
481 </para>
483 <para>
484 Now that you know which controller you are using, consult the
485 <ulink url="">
486 Radeon</ulink> page of the Gentoo wiki which has a table listing
487 the required firmware blobs for the various chipsets. Note that
488 Southern Islands and Sea Islands chips use different firmware for
489 kernel 3.17 and later compared to earlier kernels. Identify and
490 download the required blobs then install them:
491 </para>
493<screen><userinput>mkdir -pv /lib/firmware/radeon
494cp -v &lt;YOUR_BLOBS&gt; /lib/firmware/radeon</userinput></screen>
496 <para>
497 There are actually two ways of installing this firmware. BLFS, in the
498 'Kernel Configuration for additional firmware' section part of the
499 <xref linkend="xorg-ati-driver"/> section gives an example of
500 compiling the firmware into the kernel - that is slightly faster to
501 load, but uses more kernel memory. Here we will use the alternative
502 method of making the radeon driver a module. In your kernel config
503 set the following:
504 </para>
506<screen><literal>Device Drivers ---&gt;
507 Graphics support ---&gt;
508 Direct Rendering Manager ---&gt;
509 &lt;*&gt; Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
510 &lt;m&gt; ATI Radeon [CONFIG_DRM_RADEON]</literal></screen>
512 <para>
513 Loading several large blobs from /lib/firmware takes a noticeable
514 time, during which the screen will be blank. If you do not enable the
515 penguin framebuffer logo, or change the console size by using a bigger
516 font, that probably does not matter. If desired, you can slightly
517 reduce the time if you follow the alternate method of specifying 'y'
518 for CONFIG_DRM_RADEON covered in BLFS at the link above &mdash; you
519 must specify each needed radeon blob if you do that.
520 </para>
522 </sect3>
524 <sect3 id="nvidia-video-firmware">
525 <title>Firmware for Nvidia video chips</title>
527 <para>
528 Some Nvidia graphics chips need firmware updates to take advantage
529 of all the card's capability. These are generally the GeForce 8, 9,
530 9300, and 200-900 series chips. For more exact information, see
531 <ulink url=
532 ""/>.
533 </para>
535 <para>
536 First, the kernel Nvidia driver must be activated:
537 </para>
539<screen><literal>Device Drivers ---&gt;
540 Graphics support ---&gt;
541 Direct Rendering Manager ---&gt;
542 &lt;*&gt; Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
543 &lt;*/m&gt; Nouveau (NVIDIA) cards [CONFIG_DRM_NOUVEAU]</literal></screen>
545 <para>
546 The steps to install the Nvidia firmware are:
547 </para>
551sh --extract-only
553mkdir -p /lib/firmware/nouveau
554cp -d nv* vuc-* /lib/firmware/nouveau/</userinput></screen>
556 </sect3>
557 </sect2>
559 <sect2 id="nic-firmware">
560 <title>Firmware for Network Interfaces</title>
562 <para>
563 The kernel likes to load firmware for some network drivers, particularly
564 those from Realtek (the /lib/linux-firmware/rtl_nic/) directory, but
565 they generally appear to work without it. Therefore, you can boot the
566 kernel, check dmesg for messages about this missing firmware, and if
567 necessary download the firmware and put it in the specified directory in
568 <filename class="directory">/lib/firmware</filename> so that it will
569 be found on subsequent boots. Note that with current kernels this
570 works whether or not the driver is compiled in or built as a module,
571 there is no need to build this firmware into the kernel.
572 Here is an example where the R8169 driver has been compiled in but the
573 firmware was not made available. Once the firmware had been provided,
574 there was no mention of it on later boots.
575 </para>
577<screen><literal>dmesg | grep firmware | grep r8169
578[ 7.018028] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
579[ 7.018036] r8169 0000:01:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)</literal></screen>
581 </sect2>
583 <sect2 id="other-firmware">
584 <title>Firmware for Other Devices</title>
586 <para>
587 Identifying the correct firmware will typically require you to install
588 <xref linkend='pciutils'/>, and then use <userinput>lspci</userinput>
589 to identify the device. You should then search online to check which
590 module it uses, which firmware, and where to obtain the firmware &mdash;
591 not all of it is in linux-firmware.
592 </para>
594 <para>
595 If possible, you should begin by using a wired connection when you first
596 boot your LFS system. To use a wireless connection you will need to
597 use a network tools such as <xref linkend='wireless_tools'/> and <xref
598 linkend='wpa_supplicant'/>.
599 </para>
601 <para>
602 Firmware may also be needed for other devices such as some SCSI
603 controllers, bluetooth adaptors, or TV recorders. The same principles
604 apply.
605 </para>
607 </sect2>
Note: See TracBrowser for help on using the repository browser.