source: postlfs/config/firmware.xml@ 7dff3ca

10.0 10.1 11.0 11.1 8.2 8.3 8.4 9.0 9.1 basic bdubbs/svn elogind lazarus perl-modules qt5new trunk upgradedb xry111/intltool xry111/test-20220226
Last change on this file since 7dff3ca was 7dff3ca, checked in by Bruce Dubbs <bdubbs@…>, 4 years ago

Update to mariadb-10.2.12.
Update to php-7.2.1.
Update location of intel firmware.
Tweak lightdm.

git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@19653 af4574ff-66df-0310-9fd7-8a98e5e911e0

  • Property mode set to 100644
File size: 22.1 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 : Radeons, the later AMD amdgpu chips, and Nvidia
61 Maxwell cards 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="git"/>,
83 <xref linkend="pciutils"/>, and
84 <xref linkend="wget"/></para></note>
85
86 <para condition="html" role="usernotes">User Notes:
87 <ulink url="&blfs-wiki;/aboutfirmware"/></para>
88
89 <sect2 id="cpu-microcode">
90 <title>Microcode updates for CPUs</title>
91
92 <para>In general, microcode can be loaded by the BIOS or UEFI, and it might
93 be updated by upgrading to a newer version of those. On linux, you can also
94 load the microcode from the kernel if you are using an AMD family 10h or
95 later processor (first introduced late 2007), or an Intel processor from
96 1998 and later (Pentium4, Core, etc), if updated microcode has been
97 released. These updates only last until the machine is powered off, so they
98 need to be applied on every boot.</para>
99
100 <para>Intel provide frequent updates of their microcode. It is not uncommon
101 to find a newer version of microcode for an Intel processor even two years
102 after its release. New versions of AMD firmware are less common.</para>
103
104 <para>There used to be two ways of loading the microcode, described as 'early'
105 and 'late'. Early loading happens before userspace has been started, late
106 loading happens after userspace has started. Not surprisingly, early loading
107 was preferred, (see e.g. an explanatory comment in a kernel commit noted at
108 <ulink url="https://lwn.net/Articles/530346/">x86/microcode: Early load
109 microcode </ulink> on LWN.) Indeed, it is needed to work around one
110 particular erratum in early Intel Haswell processors which had TSX enabled.
111 (See <ulink
112 url="http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwellyi/">
113 Intel Disables TSX Instructions: Erratum Found in Haswell, Haswell-E/EP,
114 Broadwell-Y</ulink>.) Without this update glibc can do the wrong thing in
115 uncommon situations. </para>
116
117 <para>As a result, early loading is now expected, although for the moment
118 (4.11 kernels) it is still possible to manually force late loading of
119 microcode for testing. You will need to reconfigure your kernel for either
120 method. The instructions here will create a kernel
121 <filename>.config</filename> to suite early loading, before forcing late
122 loading to see if there is any microcode. If there is, the instructions
123 then show you how to create an initrd for early loading.</para>
124
125 <para>To confirm what processor(s) you have (if more than one, they will be
126 identical) look in /proc/cpuinfo.</para>
127
128 <sect3 id="intel-microcode">
129 <title>Intel Microcode for the CPU</title>
130
131 <para>The first step is to get the most recent version of the Intel
132 microcode. This must be done by navigating to
133 <ulink url='https://downloadcenter.intel.com/download/27377/Linux-Processor-Microcode-Data-File'/>
134 and following the instructions there. As of this writing the most recent
135 version of the microcode is <filename>microcode-20171117.tgz</filename>.
136 Extract this file in the normal way to create an <filename>intel-ucode</filename>
137 directory, containing various blobs with names in the form XX-YY-ZZ.</para>
138
139 <note><para>The above URL may not be the latest page. If it is not,
140 a line at the top of the list will direct you to the latest page.
141 </para></note>
142
143 <para>Now you need to determine your processor's identity to see if there
144 is any microcode for it. Determine the decimal values of the cpu family,
145 model and stepping by running the following command (it will also report
146 the current microcode version):</para>
147
148<screen><userinput>head -n7 /proc/cpuinfo</userinput></screen>
149
150 <para>Convert the cpu family, model and stepping to pairs of hexadecimal
151 digits. For a Haswell i7-4790 (described as Intel(R) Core(TM) i7-4790
152 CPU) the relevant values are cpu family 6, model 60, stepping 3 so in
153 this case the required identification is 06-3c-03. A look at the blobs
154 will show that there is one for this CPU (although it might
155 have already been applied by the BIOS). If there is a blob for your
156 system then test if it will be applied by copying it (replace &lt;XX-YY-ZZ&gt;
157 by the identifier for your machine) to where the kernel can find it:</para>
158
159<screen><userinput>mkdir -pv /lib/firmware/intel-ucode
160cp -v intel-ucode/&lt;XX-YY-ZZ&gt; /lib/firmware/intel-ucode</userinput></screen>
161
162 <para>Now that the Intel microcode has been prepared, use the following
163 options when you configure the kernel to load Intel
164 microcode:</para>
165
166<screen><literal>General Setup ---&gt;
167 [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
168Processor type and features ---&gt;
169 [y] CPU microcode loading support [CONFIG_MICROCODE]
170 [y] Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen>
171
172 <para>After you have successfully booted the new system, force late loading by
173 using the command:</para>
174
175<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
176
177 <para>Then use the following command to see if anything was loaded:</para>
178
179<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
180
181 <para>This example from the Haswell i7 which was released in Q2 2014 and is
182 not affected by the TSX errata shows it has been updated from revision 0x19
183 in the BIOS/UEFI to revision 0x22. Unlike in older kernels, the individual
184 CPUs are not separately reported:</para>
185
186<screen><literal>[ 0.000000] Linux version 4.11.0 (lfs@plexi) (gcc version 7.1.0 (GCC) )
187 #1 SMP PREEMPT Sun May 14 16:00:00 BST 2017
188[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.11.0-sda6 root=/dev/sda6 ro
189[ 0.913685] microcode: sig=0x306c3, pf=0x2, revision=0x22
190[ 0.913905] microcode: Microcode Update Driver: v2.2.
191[ 148.723932] microcode: updated to revision 0x22, date = 2017-01-27</literal></screen>
192 <para>That may be followed by individual reports for each core.</para>
193
194 <para>If the microcode was not updated, there is no new microcode for
195 this system's processor. If it did get updated, you can now proceed to <xref
196 linkend='early-microcode'/>.</para>
197
198 </sect3>
199
200 <sect3 id="and-microcode">
201 <title>AMD Microcode for the CPU</title>
202
203 <para>Begin by downloading a container of firmware for your CPU family
204 from <ulink
205 url='&sources-anduin-http;/linux-firmware/amd-ucode/'/>.
206 The family is always specified in hex. Families 10h to 14h (16 to 20)
207 are in microcode_amd.bin. Families 15h and 16h have their own containers.
208 Create the required directory and put the firmware you downloaded into
209 it as the <systemitem class="username">root</systemitem> user:</para>
210
211<screen><userinput>mkdir -pv /lib/firmware/amd-ucode
212cp -v microcode_amd* /lib/firmware/amd-ucode</userinput></screen>
213
214 <para>When you configure the kernel, use the following options
215 to load AMD microcode:</para>
216
217<screen><literal>General Setup ---&gt;
218 [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
219Processor type and features ---&gt;
220 [y] CPU microcode loading support [CONFIG_MICROCODE]
221 [y] AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen>
222
223 <para>After you have successfully booted the new system, force late loading by
224 using the command:</para>
225
226<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
227
228 <para>Then use the following command to see if anything was loaded:</para>
229
230<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
231 <para>This example from an old Athlon(tm) II X2 shows it has been updated.
232 For the moment, all CPUs are still reported in the microcode details on AMD
233 machines:</para>
234
235<screen><literal>[ 0.000000] Linux version 4.9.8 (ken@testserver) (gcc version 6.3.0 (GCC) )
236 #1 SMP Mon Mar 6 22:27:18 GMT 2017
237[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.9.8-sdc6 root=/dev/sdc6 ro
238[ 0.907752] microcode: CPU0: patch_level=0x010000b6
239[ 0.907788] microcode: CPU1: patch_level=0x010000b6
240[ 0.907844] microcode: Microcode Update Driver: v2.01 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba
241[ 121.952667] microcode: CPU0: new patch_level=0x010000c8
242[ 121.952687] microcode: CPU1: new patch_level=0x010000c8</literal></screen>
243
244 <para>If the microcode was not updated, there is no new microcode for
245 this system's processor. If it did get updated, you can now proceed to <xref
246 linkend='early-microcode'/>.</para>
247
248 </sect3>
249
250 <sect3 id="early-microcode">
251 <title>Early loading of microcode</title>
252
253 <para>If you have established that updated microcode is available for
254 your system, it is time to prepare it for early loading. This requires
255 an additional package, <xref linkend='cpio'/> and the creation of an
256 initrd which will need to be added to grub.cfg.</para>
257
258 <para>It does not matter where you prepare the initrd, and once it is
259 working you can apply the same initrd to later LFS systems or newer
260 kernels on this same machine, at least until any newer microcode is
261 released. Use the following commands:</para>
262
263<screen><userinput>mkdir -p initrd/kernel/x86/microcode
264cd initrd</userinput></screen>
265
266 <para>For an AMD machine, use the following command (replace
267 &lt;MYCONTAINER&gt; with the name of the container for your CPU's
268 family):</para>
269
270<screen><userinput>cp -v /lib/firmware/amd_ucode/&lt;MYCONTAINER&gt; kernel/x86/microcode/AuthenticAMD.bin</userinput></screen>
271
272 <para>Or for an Intel machine copy the appropriate blob using this command:</para>
273
274<screen><userinput>cp -v /lib/firmware/intel-ucode/&lt;XX-YY-ZZ&gt; kernel/x86/microcode/GenuineIntel.bin</userinput></screen>
275
276 <para>Now prepare the initrd:</para>
277
278<screen><userinput>find . | cpio -o -H newc &gt; /boot/microcode.img</userinput></screen>
279
280 <para>You now need to add a new entry to /boot/grub/grub.cfg and
281 here you should add a new line after the linux line within the stanza.
282 If /boot is a separate mountpoint: </para>
283
284<screen><userinput>initrd /microcode.img</userinput></screen>
285
286 <para>or this if it is not:</para>
287
288<screen><userinput>initrd /boot/microcode.img</userinput></screen>
289
290 <para>If you are already booting with an initrd (see <xref
291 linkend="initramfs"/>) you must specify the microcode initrd first, using
292 a line such as <userinput>initrd /microcode.img
293 /other-initrd.img</userinput> (adapt that as above if /boot is not a
294 separate mountpoint).</para>
295
296 <para>You can now reboot with the added initrd, and then use the same
297 command to check that the early load worked.</para>
298
299<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
300
301 <para>The places and times where early loading happens are very different
302 in AMD and Intel machines. First, an Intel example from an updated
303 kernel, showing that the first notification comes before the kernel version
304 is mentioned:</para>
305
306<screen><literal>[ 0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27
307[ 0.000000] Linux version 4.11.0 (lfs@plexi) (gcc version 7.1.0 (GCC) )
308 #2 SMP PREEMPT Sun May 14 17:58:53 BST 2017
309[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.11.0-sda6 root=/dev/sda6 ro
310[ 0.928947] microcode: sig=0x306c3, pf=0x2, revision=0x22
311[ 0.929160] microcode: Microcode Update Driver: v2.2.</literal></screen>
312
313 <para>An AMD example for an earlier stable kernel version:</para>
314
315<screen><literal>[ 0.000000] Linux version 4.9.14 (ken@testserver) (gcc version 6.3.0 (GCC) )
316 #2 SMP Mon Mar 13 22:23:44 GMT 2017
317[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.9.14-sdc6 root=/dev/sdc6 ro
318[ 0.907648] microcode: microcode updated early to new patch_level=0x010000c8
319[ 0.907690] microcode: CPU0: patch_level=0x010000c8
320[ 0.907733] microcode: CPU1: patch_level=0x010000c8
321[ 0.907808] microcode: Microcode Update Driver: v2.01 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba</literal></screen>
322
323 </sect3>
324
325 </sect2>
326
327 <sect2 id="video-firmware">
328 <title>Firmware for Video Cards</title>
329
330 <sect3 id="ati-video-firmware">
331 <title>Firmware for ATI video chips (R600 and later)</title>
332
333 <para>These instructions do NOT apply to old radeons before the R600
334 family. For those, the firmware is in the kernel's <filename
335 class='directory'>/lib/firmware/</filename> directory. Nor do they apply if
336 you intend to avoid a graphical setup such as Xorg and are content to use
337 the default 80x25 display rather than a framebuffer. </para>
338
339 <para> Early radeon devices only needed a single 2K blob of firmware.
340 Recent devices need several different blobs, and some of them are much
341 bigger. The total size of the radeon firmware directory is over 500K &mdash; on a
342 large modern system you can probably spare the space, but it is still
343 redundant to install all the unused files each time you build a system.</para>
344
345 <para>A better approach is to install <xref linkend='pciutils'/> and then
346 use <userinput>lspci</userinput> to identify which VGA controller is
347 installed.</para>
348
349 <para>With that information, check the RadeonFeature page of the Xorg wiki
350 for <ulink url="http://wiki.x.org/wiki/RadeonFeature/#index5h2">Decoder
351 ring for engineering vs marketing names</ulink> to identify the family (you
352 may need to know this for the Xorg driver in BLFS &mdash; Southern Islands and
353 Sea Islands use the radeonsi driver) and the specific model.</para>
354
355 <para>Now that you know which controller you are using, consult the
356 <ulink url="https://wiki.gentoo.org/wiki/Radeon#Firmware">Radeon</ulink> page
357 of the Gentoo wiki which has a table listing the required firmware blobs
358 for the various chipsets. Note that Southern Islands and Sea Islands chips
359 use different firmware for kernel 3.17 and later compared to earlier
360 kernels. Identify and download the required blobs then install them:</para>
361
362<screen><userinput>mkdir -pv /lib/firmware/radeon
363cp -v &lt;YOUR_BLOBS&gt; /lib/firmware/radeon</userinput></screen>
364
365 <para>There are actually two ways of installing this firmware. BLFS, in the
366 'Kernel Configuration for additional firmware' section part of the <xref
367 linkend="xorg-ati-driver"/> section gives an example of compiling the
368 firmware into the kernel - that is slightly faster to load, but uses more
369 kernel memory. Here we will use the alternative method of making the radeon
370 driver a module. In your kernel config set the following: </para>
371
372<screen><literal>Device Drivers ---&gt;
373 Graphics support ---&gt;
374 Direct Rendering Manager ---&gt;
375 &lt;*&gt; Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
376 &lt;m&gt; ATI Radeon [CONFIG_DRM_RADEON]</literal></screen>
377
378 <para>Loading several large blobs from /lib/firmware takes a noticeable
379 time, during which the screen will be blank. If you do not enable the
380 penguin framebuffer logo, or change the console size by using a bigger
381 font, that probably does not matter. If desired, you can slightly
382 reduce the time if you follow the alternate method of specifying 'y' for
383 CONFIG_DRM_RADEON covered in BLFS at the link above &mdash; you must specify each
384 needed radeon blob if you do that.</para>
385
386 </sect3>
387
388 <sect3 id="nvidia-video-firmware">
389 <title>Firmware for Nvidia video chips</title>
390
391 <para>Some Nvidia graphics chips need firmware updates to take advantage
392 of all the card's capability. These are generally the GeForce 8, 9, 9300,
393 and 200-900 series chips. For more exact information, see <ulink
394 url="https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware">
395 https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware</ulink>.</para>
396
397 <para>First, the kernel Nvidia driver must be activated:</para>
398
399<screen><literal>Device Drivers ---&gt;
400 Graphics support ---&gt;
401 Direct Rendering Manager ---&gt;
402 &lt;*&gt; Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
403 &lt;*/m&gt; Nouveau (NVIDIA) cards [CONFIG_DRM_NOUVEAU]</literal></screen>
404
405 <para>The steps to install the Nvidia firmware are:</para>
406
407<screen><userinput>wget https://raw.github.com/imirkin/re-vp2/master/extract_firmware.py
408wget http://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86-325.15.run
409sh NVIDIA-Linux-x86-325.15.run --extract-only
410python extract_firmware.py
411mkdir -p /lib/firmware/nouveau
412cp -d nv* vuc-* /lib/firmware/nouveau/</userinput></screen>
413
414 </sect3>
415 </sect2>
416
417 <sect2 id="nic-firmware">
418 <title>Firmware for Network Interfaces</title>
419
420 <para>The kernel likes to load firmware for some network drivers,
421 particularly those from Realtek (the /lib/linux-firmware/rtl_nic/) directory,
422 but they generally appear to work without it. Therefore, you can boot the
423 kernel, check dmesg for messages about this missing firmware, and if
424 necessary download the firmware and put it in the specified directory in
425 /lib/firmware so that it will be found on subsequent boots. Note that with
426 current kernels this works whether or not the driver is compiled in or
427 built as a module, there is no need to build this firmware into the kernel.
428 Here is an example where the R8169 driver has been compiled in but the
429 firmware was not made available. Once the firmware had been provided, there
430 was no mention of it on later boots. </para>
431
432<screen><literal>dmesg | grep firmware | grep r8169
433[ 7.018028] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
434[ 7.018036] r8169 0000:01:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)</literal></screen>
435
436 </sect2>
437
438 <sect2 id="other-firmware">
439 <title>Firmware for Other Devices</title>
440
441 <para> Identifying the correct firmware will typically require you to
442 install <xref linkend='pciutils'/>, and then use
443 <userinput>lspci</userinput> to identify the device. You should then search
444 online to check which module it uses, which firmware, and where to obtain
445 the firmware &mdash; not all of it is in linux-firmware.</para>
446
447 <para>If possible, you should begin by using a wired connection when you
448 first boot your LFS system. To use a wireless connection you will need to
449 use a network tools such as <xref linkend='wireless_tools'/> and <xref
450 linkend='wpa_supplicant'/>.</para>
451
452 <para>Firmware may also be needed for other devices such as some SCSI
453 controllers, bluetooth adaptors, or TV recorders. The same principles
454 apply.</para>
455
456 </sect2>
457
458</sect1>
Note: See TracBrowser for help on using the repository browser.