source: postlfs/config/firmware.xml@ 4de7ca7

basic
Last change on this file since 4de7ca7 was 4de7ca7, checked in by Bruce Dubbs <bdubbs@…>, 4 years ago

Numerous typos and text corrections

git-svn-id: svn://svn.linuxfromscratch.org/BLFS/branches/basic@20528 af4574ff-66df-0310-9fd7-8a98e5e911e0

  • Property mode set to 100644
File size: 22.8 KB
Line 
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
4 <!ENTITY % general-entities SYSTEM "../../general.ent">
5 %general-entities;
6]>
7
8<sect1 id="postlfs-firmware" xreflabel="About Firmware">
9 <?dbhtml filename="firmware.html"?>
10
11 <sect1info>
12 <othername>$LastChangedBy$</othername>
13 <date>$Date$</date>
14 </sect1info>
15
16 <title>About Firmware</title>
17
18 <indexterm zone="postlfs-firmware">
19 <primary sortas="e-lib-firmware">/lib/firmware</primary>
20 </indexterm>
21
22 <para> On some recent PCs it can be necessary, or desirable, to load firmware
23 to make them work at their best. There is a directory, <filename
24 class="directory">/lib/firmware</filename>, where the kernel or kernel
25 drivers look for firmware images.</para>
26
27 <para>Preparing firmware for multiple different machines, as a distro would
28 do, is outside the scope of this book.</para>
29
30 <para>Currently, most firmware can be found at a <userinput>git</userinput>
31 repository: <ulink
32 url="http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/"/>.
33 For convenience, the LFS Project has created a mirror, updated daily, where
34 these firmware files can be accessed via <userinput>wget</userinput> or a web
35 browser at <ulink
36 url="&sources-anduin-http;/linux-firmware/"/>.</para>
37
38 <para>To get the firmware, either point a browser to one of the above
39 repositories and then download the item(s) which you need, or install
40 <userinput>git</userinput> and clone that repository.</para>
41
42 <para>For some other firmware, particularly for Intel microcode and certain
43 wifi devices, the needed firmware is not available in the above repository.
44 Some of this will be addressed below, but a search of the Internet for needed
45 firmware is sometimes necessary.</para>
46
47 <para>Firmware files are conventionally referred to as blobs because you cannot
48 determine what they will do. Note that firmware is distributed under various
49 different licenses which do not permit disassembly or reverse-engineering.</para>
50
51 <para>Firmware for PCs falls into four categories:</para>
52
53 <itemizedlist spacing="compact">
54 <listitem>
55 <para>Updates to the CPU to work around errata, usually referred to as
56 microcode.</para>
57 </listitem>
58 <listitem>
59 <para>Firmware for video controllers. On x86 machines this seems to mostly
60 apply to ATI devices (Radeon and AMDGPU chips) and Nvidia
61 Maxwell and Pascal cards which all require firmware to be able to use KMS
62 (kernel modesetting - the preferred option) as well as for Xorg. For
63 earlier radeon chips (before the R600), the firmware is still in the
64 kernel.</para>
65 </listitem>
66 <listitem>
67 <para>Firmware updates for wired network ports. Mostly they work even
68 without the updates, but one must assume that they will work better with
69 the updated firmware.</para>
70 </listitem>
71 <listitem>
72 <para>Firmware for other devices, such as wifi. These devices are not
73 required for the PC to boot, but need the firmware before these devices
74 can be used.</para>
75 </listitem>
76 </itemizedlist>
77
78 <note><para>Although not needed to load a firmware blob, the following
79 tools may be useful for determining, obtaining, or preparing the needed
80 firmware in order to load it into the system:
81 <xref linkend="cpio"/>,
82 <xref linkend="pciutils"/>,
83 <xref linkend="wget"/>, and
84 <!-- <xref linkend="git"/>, -->
85 <ulink url="&blfs-book;general/git.html">git</ulink>
86 </para></note>
87
88 <para condition="html" role="usernotes">User Notes:
89 <ulink url="&blfs-wiki;/aboutfirmware"/></para>
90
91 <sect2 id="cpu-microcode">
92 <title>Microcode updates for CPUs</title>
93
94 <para>In general, microcode can be loaded by the BIOS or UEFI, and it might
95 be updated by upgrading to a newer version of those. On linux, you can also
96 load the microcode from the kernel if you are using an AMD family 10h or
97 later processor (first introduced late 2007), or an Intel processor from
98 1998 and later (Pentium4, Core, etc), if updated microcode has been
99 released. These updates only last until the machine is powered off, so they
100 need to be applied on every boot.</para>
101
102 <para>Intel provide frequent updates of their microcode. It is not uncommon
103 to find a newer version of microcode for an Intel processor even two years
104 after its release. New versions of AMD firmware are rare and usually only
105 apply to a few models, although motherboard manufacturers get extra updates
106 which maybe update microcode along with the changes to support newer CPUs
107 and faster memory.</para>
108
109 <para>There used to be two ways of loading the microcode, described as 'early'
110 and 'late'. Early loading happens before userspace has been started, late
111 loading happens after userspace has started. Not surprisingly, early loading
112 was preferred, (see e.g. an explanatory comment in a kernel commit noted at
113 <ulink url="https://lwn.net/Articles/530346/">x86/microcode: Early load
114 microcode </ulink> on LWN.) Indeed, it is needed to work around one
115 particular erratum in early Intel Haswell processors which had TSX enabled.
116 (See <ulink
117 url="http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwellyi/">
118 Intel Disables TSX Instructions: Erratum Found in Haswell, Haswell-E/EP,
119 Broadwell-Y</ulink>.) Without this update glibc can do the wrong thing in
120 uncommon situations. </para>
121
122 <para>As a result, early loading is now expected, although for the moment
123 (4.18 kernels) it is still possible to manually force late loading of
124 microcode for testing. You will need to reconfigure your kernel for either
125 method. The instructions here will create a kernel
126 <filename>.config</filename> to suite early loading, before forcing late
127 loading to see if there is any microcode. If there is, the instructions
128 then show you how to create an initrd for early loading.</para>
129
130 <para>To confirm what processor(s) you have (if more than one, they will be
131 identical) look in /proc/cpuinfo.</para>
132
133 <sect3 id="intel-microcode">
134 <title>Intel Microcode for the CPU</title>
135
136 <para>The first step is to get the most recent version of the Intel
137 microcode. This must be done by navigating to
138 <ulink url='https://downloadcenter.intel.com/download/28039/Linux-Processor-Microcode-Data-File'/>
139 and following the instructions there. As of this writing the most recent
140 version of the microcode is <filename>microcode-20180807.tgz</filename>.
141 Extract this file in the normal way to create an <filename>intel-ucode</filename>
142 directory, containing various blobs with names in the form XX-YY-ZZ.
143 This tarball does not contain a top-level directory, two files
144 (microcode.dat which is the old-style of updates, still used by some
145 linux distros, and releasenote) will be extracted into the current
146 directory.</para>
147
148 <note><para>The above URL may not be the latest page. If it is not,
149 a line at the top of the page will direct you to the latest page.
150 </para></note>
151
152 <para>Now you need to determine your processor's identity to see if there
153 is any microcode for it. Determine the decimal values of the cpu family,
154 model and stepping by running the following command (it will also report
155 the current microcode version):</para>
156
157<screen><userinput>head -n7 /proc/cpuinfo</userinput></screen>
158
159 <para>Convert the cpu family, model and stepping to pairs of hexadecimal
160 digits. For a Haswell i7-4790 (described as Intel(R) Core(TM) i7-4790
161 CPU) the relevant values are cpu family 6, model 60, stepping 3 so in
162 this case the required identification is 06-3c-03. A look at the blobs
163 will show that there is one for this CPU (although it might
164 have already been applied by the BIOS). If there is a blob for your
165 system then test if it will be applied by copying it (replace &lt;XX-YY-ZZ&gt;
166 by the identifier for your machine) to where the kernel can find it:</para>
167
168<screen><userinput>mkdir -pv /lib/firmware/intel-ucode
169cp -v intel-ucode/&lt;XX-YY-ZZ&gt; /lib/firmware/intel-ucode</userinput></screen>
170
171 <para>Now that the Intel microcode has been prepared, use the following
172 options when you configure the kernel to load Intel
173 microcode:</para>
174
175<screen><literal>General Setup ---&gt;
176 [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
177Processor type and features ---&gt;
178 [y] CPU microcode loading support [CONFIG_MICROCODE]
179 [y] Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen>
180
181 <para>After you have successfully booted the new system, force late loading by
182 using the command:</para>
183
184<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
185
186 <para>Then use the following command to see if anything was loaded:</para>
187
188<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
189
190 <para>This example from the Haswell i7 which was released in Q2 2014 and is
191 not affected by the TSX errata shows it has been updated from revision 0x19
192 in the BIOS/UEFI (which this version of the kernel now complains about) to
193 revision 0x24. Unlike in older kernels, the individual CPUs are not separately
194 reported:</para>
195
196<screen><literal>[ 0.000000] Linux version 4.18.0-rc8 (root@plexi) (gcc version 8.2.0 (GCC))
197 #2 SMP PREEMPT Sat Aug 11 22:26:26 BST 2018
198[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.18.0-rc8-sda5 root=/dev/sda5 ro resume=/dev/sdb1
199[ 0.000000] [Firmware Bug]: TSC_DEADLINE disabled due to Errata;
200 please update microcode to version: 0x22 (or later)
201[ 0.482712] microcode: sig=0x306c3, pf=0x2, revision=0x19
202[ 0.274963] microcode: Microcode Update Driver: v2.2.
203[ 1475.941353] microcode: updated to revision 0x25, date = 2018-04-02
204[ 1475.944753] x86/CPU: CPU features have changed after loading microcode, but might not take effect</literal></screen>
205
206 <para>If the microcode was not updated, there is no new microcode for
207 this system's processor. If it did get updated, you can now proceed to <xref
208 linkend='early-microcode'/>.</para>
209
210 </sect3>
211
212 <sect3 id="and-microcode">
213 <title>AMD Microcode for the CPU</title>
214
215 <para>Begin by downloading a container of firmware for your CPU family
216 from <ulink
217 url='&sources-anduin-http;/linux-firmware/amd-ucode/'/>.
218 The family is always specified in hex. Families 10h to 14h (16 to 20)
219 are in microcode_amd.bin. Families 15h, 16h and 17h have their own containers.
220 Create the required directory and put the firmware you downloaded into
221 it as the <systemitem class="username">root</systemitem> user:</para>
222
223<screen><userinput>mkdir -pv /lib/firmware/amd-ucode
224cp -v microcode_amd* /lib/firmware/amd-ucode</userinput></screen>
225
226 <para>When you configure the kernel, use the following options
227 to load AMD microcode:</para>
228
229<screen><literal>General Setup ---&gt;
230 [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
231Processor type and features ---&gt;
232 [y] CPU microcode loading support [CONFIG_MICROCODE]
233 [y] AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen>
234
235 <para>After you have successfully booted the new system, force late loading by
236 using the command:</para>
237
238<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
239
240 <para>Then use the following command to see if anything was loaded:</para>
241
242<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
243 <para>This historic example from an old Athlon(tm) II X2 shows it has been
244 updated. At that time, all CPUs were still reported in the microcode details on
245 AMD machines (the current position for AMD machines where newer microcode is
246 available is unknown) :</para>
247
248<screen><literal>[ 0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
249 #1 SMP Sun Feb 18 02:08:12 GMT 2018
250[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.3-sda5 root=/dev/sda5 ro
251[ 0.307619] microcode: CPU0: patch_level=0x010000b6
252[ 0.307671] microcode: CPU1: patch_level=0x010000b6
253[ 0.307743] microcode: Microcode Update Driver: v2.2.
254[ 187.928891] microcode: CPU0: new patch_level=0x010000c8
255[ 187.928899] microcode: CPU1: new patch_level=0x010000c8</literal></screen>
256
257 <para>If the microcode was not updated, there is no new microcode for
258 this system's processor. If it did get updated, you can now proceed to <xref
259 linkend='early-microcode'/>.</para>
260
261 </sect3>
262
263 <sect3 id="early-microcode">
264 <title>Early loading of microcode</title>
265
266 <para>If you have established that updated microcode is available for
267 your system, it is time to prepare it for early loading. This requires
268 an additional package, <xref linkend='cpio'/> and the creation of an
269 initrd which will need to be added to grub.cfg.</para>
270
271 <para>It does not matter where you prepare the initrd, and once it is
272 working you can apply the same initrd to later LFS systems or newer
273 kernels on this same machine, at least until any newer microcode is
274 released. Use the following commands:</para>
275
276<screen><userinput>mkdir -p initrd/kernel/x86/microcode
277cd initrd</userinput></screen>
278
279 <para>For an AMD machine, use the following command (replace
280 &lt;MYCONTAINER&gt; with the name of the container for your CPU's
281 family):</para>
282
283<screen><userinput>cp -v /lib/firmware/amd-ucode/&lt;MYCONTAINER&gt; kernel/x86/microcode/AuthenticAMD.bin</userinput></screen>
284
285 <para>Or for an Intel machine copy the appropriate blob using this command:</para>
286
287<screen><userinput>cp -v /lib/firmware/intel-ucode/&lt;XX-YY-ZZ&gt; kernel/x86/microcode/GenuineIntel.bin</userinput></screen>
288
289 <para>Now prepare the initrd:</para>
290
291<screen><userinput>find . | cpio -o -H newc &gt; /boot/microcode.img</userinput></screen>
292
293 <para>You now need to add a new entry to /boot/grub/grub.cfg and
294 here you should add a new line after the linux line within the stanza.
295 If /boot is a separate mountpoint: </para>
296
297<screen><userinput>initrd /microcode.img</userinput></screen>
298
299 <para>or this if it is not:</para>
300
301<screen><userinput>initrd /boot/microcode.img</userinput></screen>
302
303 <para>If you are already booting with an initrd (see <xref
304 linkend="initramfs"/>) you must specify the microcode initrd first, using
305 a line such as <userinput>initrd /microcode.img
306 /other-initrd.img</userinput> (adapt that as above if /boot is not a
307 separate mountpoint).</para>
308
309 <para>You can now reboot with the added initrd, and then use the same
310 command to check that the early load worked.</para>
311
312<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
313
314 <para>The places and times where early loading happens are very different
315 in AMD and Intel machines. First, an Intel example from an updated
316 kernel, showing that the first notification comes before the kernel version
317 is mentioned:</para>
318
319<screen><literal>[ 0.000000] microcode: microcode updated early to revision 0x25, date = 2018-04-02
320[ 0.000000] Linux version 4.18.1-rc1 (ken@plexi) (gcc version 8.2.0 (GCC))
321 #2 SMP PREEMPT Tue Aug 14 20:22:35 BST 2018
322[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.18.1-rc1-sda5 root=/dev/sda5 ro resume=/dev/sdb1
323[ 0.275864] microcode: sig=0x306c3, pf=0x2, revision=0x25
324[ 0.275911] microcode: Microcode Update Driver: v2.2.</literal></screen>
325
326 <para>A historic AMD example:</para>
327
328<screen><literal>[ 0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
329 #2 SMP Sun Feb 18 02:32:03 GMT 2018
330[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.3-sda5 root=/dev/sda5 ro
331[ 0.307619] microcode: microcode updated early to new patch_level=0x010000c8
332[ 0.307678] microcode: CPU0: patch_level=0x010000c8
333[ 0.307723] microcode: CPU1: patch_level=0x010000c8
334[ 0.307795] microcode: Microcode Update Driver: v2.2.</literal></screen>
335
336 </sect3>
337
338 </sect2>
339
340 <sect2 id="video-firmware">
341 <title>Firmware for Video Cards</title>
342
343 <sect3 id="ati-video-firmware">
344 <title>Firmware for ATI video chips (R600 and later)</title>
345
346 <para>These instructions do NOT apply to old radeons before the R600
347 family. For those, the firmware is in the kernel's <filename
348 class='directory'>/lib/firmware/</filename> directory. Nor do they apply if
349 you intend to avoid a graphical setup such as Xorg and are content to use
350 the default 80x25 display rather than a framebuffer. </para>
351
352 <para> Early radeon devices only needed a single 2K blob of firmware.
353 Recent devices need several different blobs, and some of them are much
354 bigger. The total size of the radeon firmware directory is over 500K &mdash; on a
355 large modern system you can probably spare the space, but it is still
356 redundant to install all the unused files each time you build a system.</para>
357
358 <para>A better approach is to install <xref linkend='pciutils'/> and then
359 use <userinput>lspci</userinput> to identify which VGA controller is
360 installed.</para>
361
362 <para>With that information, check the RadeonFeature page of the Xorg wiki
363 for <ulink url="http://wiki.x.org/wiki/RadeonFeature/#index5h2">Decoder
364 ring for engineering vs marketing names</ulink> to identify the family (you
365 may need to know this for the Xorg driver in BLFS &mdash; Southern Islands and
366 Sea Islands use the radeonsi driver) and the specific model.</para>
367
368 <para>Now that you know which controller you are using, consult the
369 <ulink url="https://wiki.gentoo.org/wiki/Radeon#Firmware">Radeon</ulink> page
370 of the Gentoo wiki which has a table listing the required firmware blobs
371 for the various chipsets. Note that Southern Islands and Sea Islands chips
372 use different firmware for kernel 3.17 and later compared to earlier
373 kernels. Identify and download the required blobs then install them:</para>
374
375<screen><userinput>mkdir -pv /lib/firmware/radeon
376cp -v &lt;YOUR_BLOBS&gt; /lib/firmware/radeon</userinput></screen>
377
378 <para>There are actually two ways of installing this firmware. BLFS, in the
379 'Kernel Configuration for additional firmware' section part of the <!--<xref
380 linkend="xorg-ati-driver"/>--> section gives an example of compiling the
381 firmware into the kernel - that is slightly faster to load, but uses more
382 kernel memory. Here we will use the alternative method of making the radeon
383 driver a module. In your kernel config set the following: </para>
384
385<screen><literal>Device Drivers ---&gt;
386 Graphics support ---&gt;
387 Direct Rendering Manager ---&gt;
388 &lt;*&gt; Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
389 &lt;m&gt; ATI Radeon [CONFIG_DRM_RADEON]</literal></screen>
390
391 <para>Loading several large blobs from /lib/firmware takes a noticeable
392 time, during which the screen will be blank. If you do not enable the
393 penguin framebuffer logo, or change the console size by using a bigger
394 font, that probably does not matter. If desired, you can slightly
395 reduce the time if you follow the alternate method of specifying 'y' for
396 CONFIG_DRM_RADEON covered in BLFS at the link above &mdash; you must specify each
397 needed radeon blob if you do that.</para>
398
399 </sect3>
400
401 <sect3 id="nvidia-video-firmware">
402 <title>Firmware for Nvidia video chips</title>
403
404 <para>Some Nvidia graphics chips need firmware updates to take advantage
405 of all the card's capability. These are generally the GeForce 8, 9, 9300,
406 and 200-900 series chips. For more exact information, see <ulink
407 url="https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware">
408 https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware</ulink>.</para>
409
410 <para>First, the kernel Nvidia driver must be activated:</para>
411
412<screen><literal>Device Drivers ---&gt;
413 Graphics support ---&gt;
414 Direct Rendering Manager ---&gt;
415 &lt;*&gt; Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
416 &lt;*/m&gt; Nouveau (NVIDIA) cards [CONFIG_DRM_NOUVEAU]</literal></screen>
417
418 <para>The steps to install the Nvidia firmware are:</para>
419
420<screen><userinput>wget https://raw.github.com/imirkin/re-vp2/master/extract_firmware.py
421wget http://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86-325.15.run
422sh NVIDIA-Linux-x86-325.15.run --extract-only
423python extract_firmware.py
424mkdir -p /lib/firmware/nouveau
425cp -d nv* vuc-* /lib/firmware/nouveau/</userinput></screen>
426
427 </sect3>
428 </sect2>
429
430 <sect2 id="nic-firmware">
431 <title>Firmware for Network Interfaces</title>
432
433 <para>The kernel likes to load firmware for some network drivers,
434 particularly those from Realtek (the /lib/linux-firmware/rtl_nic/) directory,
435 but they generally appear to work without it. Therefore, you can boot the
436 kernel, check dmesg for messages about this missing firmware, and if
437 necessary download the firmware and put it in the specified directory in
438 /lib/firmware so that it will be found on subsequent boots. Note that with
439 current kernels this works whether or not the driver is compiled in or
440 built as a module, there is no need to build this firmware into the kernel.
441 Here is an example where the R8169 driver has been compiled in but the
442 firmware was not made available. Once the firmware had been provided, there
443 was no mention of it on later boots. </para>
444
445<screen><literal>dmesg | grep firmware | grep r8169
446[ 7.018028] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
447[ 7.018036] r8169 0000:01:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)</literal></screen>
448
449 </sect2>
450
451 <sect2 id="other-firmware">
452 <title>Firmware for Other Devices</title>
453
454 <para> Identifying the correct firmware will typically require you to
455 install <xref linkend='pciutils'/>, and then use
456 <userinput>lspci</userinput> to identify the device. You should then search
457 online to check which module it uses, which firmware, and where to obtain
458 the firmware &mdash; not all of it is in linux-firmware.</para>
459
460 <para>If possible, you should begin by using a wired connection when you
461 first boot your LFS system. To use a wireless connection you will need to
462 use a network tools such as <xref linkend='wireless_tools'/> and <xref
463 linkend='wpa_supplicant'/>.</para>
464
465 <para>Firmware may also be needed for other devices such as some SCSI
466 controllers, bluetooth adaptors, or TV recorders. The same principles
467 apply.</para>
468
469 </sect2>
470
471</sect1>
Note: See TracBrowser for help on using the repository browser.