source: postlfs/config/firmware.xml@ 3179c69

10.0 10.1 11.0 ken/refactor-virt lazarus qt5new trunk xry111/git-date xry111/git-date-for-trunk xry111/git-date-test
Last change on this file since 3179c69 was 3179c69, checked in by Ken Moffat <ken@…>, 16 months ago

Firmware: update some details:

  1. Intel (CPU) microcode - update the details for Skylake in the light

of the later release.

  1. Video firmware - I had overlooked that Nvidia provided signed

firmware to linux-firmware in January and February for Turing GPUs
and that it is only needed for hardware acceleration so not
essential for working KMS. For completeness, also mention the
problematic Intel iGPU firmware for Skylake and later.

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

  • Property mode set to 100644
File size: 27.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>
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>
28
29 <para>
30 Currently, most firmware can be found at a <userinput>git</userinput>
31 repository: <ulink url=
32 "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
35 web browser at <ulink url="&sources-anduin-http;/linux-firmware/"/>.
36 </para>
37
38 <para>
39 To get the firmware, either point a browser to one of the above
40 repositories and then download the item(s) which you need, or install
41 <xref linkend="git"/> and clone that repository.
42 </para>
43
44 <para>
45 For some other firmware, particularly for Intel microcode and certain
46 wifi devices, the needed firmware is not available in the above repository.
47 Some of this will be addressed below, but a search of the Internet for
48 needed firmware is sometimes necessary.
49 </para>
50
51 <para>
52 Firmware files are conventionally referred to as blobs because you cannot
53 determine what they will do. Note that firmware is distributed under
54 various different licenses which do not permit disassembly or
55 reverse-engineering.
56 </para>
57
58 <para>
59 Firmware for PCs falls into four categories:
60 </para>
61
62 <itemizedlist spacing="compact">
63 <listitem>
64 <para>
65 Updates to the CPU to work around errata, usually referred to as
66 microcode.
67 </para>
68 </listitem>
69 <listitem>
70 <para>
71 Firmware for video controllers. On x86 machines this is required for
72 ATI devices (Radeon and AMDGPU chips) and may be useful for Intel (Skylake
73 and later) and Nvidia (Kepler and later) GPUs.
74 </para>
75
76 <para>
77 ATI Radeon and AMGPU devices all require firmware to be able to use KMS
78 (kernel modesetting - the preferred option) as well as for Xorg. For
79 old radeon chips (before the R600), the firmware is still in the
80 kernel source.
81 </para>
82
83 <para>
84 Intel integrated GPUs from Skylake onwards can use firmware for GuC
85 (the Graphics microcontroller), and also for the HuC (HEVC/H265
86 microcontroller which offloads to the GPU) and the DMC (Display
87 Microcontroller) to provide additional low-power states. The GuC and
88 HuC have had a chequered history in the kernel and updated firmware
89 may be disabled by default, depending on your kernel version. Further
90 details may be found at <ulink
91 url="https://01.org/linuxgraphics/downloads/firmware/">01.org</ulink>
92 and <ulink
93 url="https://wiki.archlinux.org/index.php/intel_graphics/">Arch
94 linux</ulink>.
95 </para>
96
97 <para>
98 Nvidia GPUs from Kepler onwards require signed firmware, otherwise the
99 nouveau driver is unable to provide hardware acceleration. Nvidia has
100 now released firmware up to Turing (most, maybe all, GTX16xx and RTX20xx
101 GPUs) to linux-firmware, and kernels from linux-5.6 should support it,
102 although Mesa support may require a development version until Mesa-20.2
103 is released. Note that faster clocks than the default are not enabled
104 by the released firmware.
105 </para>
106 </listitem>
107 <listitem>
108 <para>
109 Firmware updates for wired network ports. Mostly they work even
110 without the updates, but probably they will work better with
111 the updated firmware. For some modern laptops, firmware for both
112 wired ethernet (e.g. rtl_nic) and also for bluetooth devices (e.g. qca)
113 is <emphasis>required</emphasis> before the wired network can be used.
114 </para>
115 </listitem>
116 <listitem>
117 <para>
118 Firmware for other devices, such as wifi. These devices are not
119 required for the PC to boot, but need the firmware before these devices
120 can be used.
121 </para>
122 </listitem>
123 </itemizedlist>
124
125 <note>
126 <para>
127 Although not needed to load a firmware blob, the following
128 tools may be useful for determining, obtaining, or preparing the needed
129 firmware in order to load it into the system:
130 <xref linkend="cpio"/>,
131 <xref linkend="git"/>,
132 <xref linkend="pciutils"/>, and
133 <xref linkend="wget"/>
134 </para>
135 </note>
136
137 <para condition="html" role="usernotes">User Notes:
138 <ulink url="&blfs-wiki;/aboutfirmware"/></para>
139
140 <sect2 id="cpu-microcode">
141 <title>Microcode updates for CPUs</title>
142
143 <para>
144 In general, microcode can be loaded by the BIOS or UEFI, and it might be
145 updated by upgrading to a newer version of those. On linux, you can also
146 load the microcode from the kernel if you are using an AMD family 10h or
147 later processor (first introduced late 2007), or an Intel processor from
148 1998 and later (Pentium4, Core, etc), if updated microcode has been
149 released. These updates only last until the machine is powered off, so
150 they need to be applied on every boot.
151 </para>
152
153 <para>
154 Intel provide updates of their microcode for Haswell and later
155 processors as new vulnerabilities come to light, and have in the past
156 provided updates for processors from SandyBridge onwards, although those
157 are no-longer supported for new fixes. New versions of AMD
158 firmware are rare and usually only apply to a few models, although
159 motherboard manufacturers get extra updates which maybe update microcode
160 along with the changes to support newer CPUs and faster memory.
161 </para>
162
163 <para>
164 There are two ways of loading the microcode, described as 'early' and
165 'late'. Early loading happens before userspace has been started, late
166 loading happens after userspace has started. Not surprisingly, early
167 loading is preferred, (see e.g. an explanatory comment in a kernel
168 commit noted at <ulink url="https://lwn.net/Articles/530346/">
169 x86/microcode: Early load microcode</ulink> on LWN.) Indeed, it
170 is needed to work around one particular erratum in early Intel Haswell
171 processors which had TSX enabled. (See <ulink url=
172 "http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwellyi/">
173 Intel Disables TSX Instructions: Erratum Found in Haswell,
174 Haswell-E/EP, Broadwell-Y
175 </ulink>.) Without this update glibc can do the wrong thing in uncommon
176 situations.
177 </para>
178
179 <para>
180 It is still possible to manually force late loading of microcode, either
181 for testing or to prevent having to reboot. You will need to reconfigure
182 your kernel for either method. The instructions here will create a
183 kernel <filename>.config</filename> to suite early loading, before
184 forcing late loading to see if there is any microcode. If there is,
185 the instructions then show you how to create an initrd for early loading.
186 </para>
187
188 <para>
189 To confirm what processor(s) you have (if more than one, they will be
190 identical) look in /proc/cpuinfo.
191 </para>
192
193 <para>
194 If you are creating an initrd to update firmware for different machines,
195 as a distro would do, go down to 'Early loading of microcode' and cat all
196 the Intel blobs to GenuineIntel.bin or cat all the AMD blobs to
197 AuthenticAMD.bin. This creates a larger initrd - for all Intel machines in
198 the 20200609 update the size is 3.0 MB compared to typically 24 KB for one
199 machine.
200 </para>
201
202 <sect3 id="intel-microcode">
203 <title>Intel Microcode for the CPU</title>
204
205 <para>
206 The first step is to get the most recent version of the Intel
207 microcode. This must be done by navigating to <ulink url=
208 'https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/'/>
209 and downloading the latest file there. As of this writing the most
210 secure version of the microcode, for those machines which can boot it,
211 is microcode-20200609. If you have a Skylake machine, please read the
212 Caution in the 'Early loading of microcode' section below. Extract this
213 file in the normal way, the microcode is in the <filename>intel-ucode
214 </filename> directory, containing various blobs with names in the form
215 XX-YY-ZZ. There are also various other files, and a releasenote.
216 </para>
217
218 <para>
219 In the past, intel did not provide any details of which blobs had
220 changed versions, but now the release note details this.
221 </para>
222
223 <para>
224 The recent firmware for older processors is provided to deal with
225 vulnerabilities which have now been made public, and for some of these
226 such as Microarchitectural Data Sampling (MDS) you might wish to
227 increase the protection by disabling hyperthreading, or alternatively
228 to disable the kernel's default mitigation because of its impact on
229 compile times. Please read the online documentation at <ulink url=
230 'https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html'/>.
231 </para>
232
233 <para>
234 The documentation on the latest SRBDS (Special Register Buffer Data
235 Sampling) vulnerabilities/fixes will be documented in kernels 5.4.46,
236 5.6.18, 5.7.2, 5.8.0 and later.
237 </para>
238
239 <para>
240 Now you need to determine your processor's identity to see if there
241 is any microcode for it. Determine the decimal values of the cpu family,
242 model and stepping by running the following command (it will also report
243 the current microcode version):
244 </para>
245
246<screen><userinput>head -n7 /proc/cpuinfo</userinput></screen>
247
248 <para>
249 Convert the cpu family, model and stepping to pairs of hexadecimal
250 digits. For a Skylake i3 6100 (described as Intel(R) Core(TM) i3-6100
251 CPU) the relevant values are cpu family 6, model 94, stepping 3 so in
252 this case the required identification is 06-5e-03. A look at the blobs
253 will show that there is one for this CPU (although for older issues it
254 might have already been applied by the BIOS). If there is a blob for
255 your system then test if it will be applied by copying it (replace
256 &lt;XX-YY-ZZ&gt; by the identifier for your CPU) to where the
257 kernel can find it:
258 </para>
259
260<screen><userinput>mkdir -pv /lib/firmware/intel-ucode
261cp -v intel-ucode/&lt;XX-YY-ZZ&gt; /lib/firmware/intel-ucode</userinput></screen>
262
263 <para>
264 Now that the Intel microcode has been prepared, use the following
265 options when you configure the kernel to load Intel microcode:
266 </para>
267
268<screen><literal>General Setup ---&gt;
269 [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
270Processor type and features ---&gt;
271 [y] CPU microcode loading support [CONFIG_MICROCODE]
272 [y] Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen>
273
274 <para>
275 After you have successfully booted the new system, force late loading
276 by using the command:
277 </para>
278
279<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
280
281 <para>
282 Then use the following command to see if anything was loaded:
283 (N.B. the dates when microcode was created may be months ahead of when
284 it was released.)
285 </para>
286
287<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
288
289 <para>
290 This reformatted example for an old (20191115) verison of the microcode
291 was created by temporarily booting without
292 microcode, to show the current Firmware Bug message, then the late load
293 shows it being updated to revision 0xd6.
294 </para>
295
296<screen><literal>[ 0.000000] Linux version 5.4.2 (lfs@leshp) (gcc version 9.2.0 (GCC))
297 #1 SMP PREEMPT Wed Dec 18 11:52:13 GMT 2019
298[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.4.2-sda11 root=/dev/sda11 ro
299[ 0.020218] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode
300 to version: 0xb2 (or later)
301[ 0.153861] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
302[ 0.550009] microcode: sig=0x506e3, pf=0x2, revision=0x74
303[ 0.550036] microcode: Microcode Update Driver: v2.2.
304[ 277.673064] microcode: updated to revision 0xd6, date = 2019-10-03
305[ 277.674231] x86/CPU: CPU features have changed after loading microcode, but might not take effect</literal></screen>
306
307 <para>
308 If the microcode was not updated, there is no new microcode for this
309 system's processor. If it did get updated, you can now proceed to
310 <xref linkend='early-microcode'/>.
311 </para>
312
313 </sect3>
314
315 <sect3 id="and-microcode">
316 <title>AMD Microcode for the CPU</title>
317
318 <para>
319 Begin by downloading a container of firmware for your CPU family
320 from <ulink url=
321 '&sources-anduin-http;/linux-firmware/amd-ucode/'/>.
322 The family is always specified in hex. Families 10h to 14h (16 to 20)
323 are in microcode_amd.bin. Families 15h, 16h and 17h have their own
324 containers. Create the required directory and put the firmware you
325 downloaded into it as the <systemitem
326 class="username">root</systemitem> user:
327 </para>
328
329<screen><userinput>mkdir -pv /lib/firmware/amd-ucode
330cp -v microcode_amd* /lib/firmware/amd-ucode</userinput></screen>
331
332 <para>
333 When you configure the kernel, use the following options
334 to load AMD microcode:
335 </para>
336
337<screen><literal>General Setup ---&gt;
338 [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
339Processor type and features ---&gt;
340 [y] CPU microcode loading support [CONFIG_MICROCODE]
341 [y] AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen>
342
343 <para>
344 After you have successfully booted the new system, force late loading
345 by using the command:
346 </para>
347
348<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
349
350 <para>
351 Then use the following command to see if anything was loaded:
352 </para>
353
354<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
355 <para>
356 This historic example from an old Athlon(tm) II X2 shows it has been
357 updated. At that time, all CPUs were still reported in the microcode
358 details on AMD machines (the current position for AMD machines where
359 newer microcode is available is unknown) :
360 </para>
361
362<screen><literal>[ 0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
363 #1 SMP Sun Feb 18 02:08:12 GMT 2018
364[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.3-sda5 root=/dev/sda5 ro
365[ 0.307619] microcode: CPU0: patch_level=0x010000b6
366[ 0.307671] microcode: CPU1: patch_level=0x010000b6
367[ 0.307743] microcode: Microcode Update Driver: v2.2.
368[ 187.928891] microcode: CPU0: new patch_level=0x010000c8
369[ 187.928899] microcode: CPU1: new patch_level=0x010000c8</literal></screen>
370
371 <para>
372 If the microcode was not updated, there is no new microcode for
373 this system's processor. If it did get updated, you can now proceed to
374 <xref linkend='early-microcode'/>.
375 </para>
376
377 </sect3>
378
379 <sect3 id="early-microcode">
380 <title>Early loading of microcode</title>
381
382 <para>
383 If you have established that updated microcode is available for
384 your system, it is time to prepare it for early loading. This requires
385 an additional package, <xref linkend='cpio'/> and the creation of an
386 initrd which will need to be added to grub.cfg.
387 </para>
388
389 <para>
390 It does not matter where you prepare the initrd, and once it is
391 working you can apply the same initrd to later LFS systems or newer
392 kernels on this same machine, at least until any newer microcode is
393 released. Use the following commands:
394 </para>
395
396<screen><userinput>mkdir -p initrd/kernel/x86/microcode
397cd initrd</userinput></screen>
398
399 <para>
400 For an AMD machine, use the following command (replace
401 &lt;MYCONTAINER&gt; with the name of the container for your CPU's
402 family):
403 </para>
404
405<screen><userinput>cp -v /lib/firmware/amd-ucode/&lt;MYCONTAINER&gt; kernel/x86/microcode/AuthenticAMD.bin</userinput></screen>
406
407 <para>
408 Or for an Intel machine copy the appropriate blob using this command:
409 </para>
410
411<screen><userinput>cp -v /lib/firmware/intel-ucode/&lt;XX-YY-ZZ&gt; kernel/x86/microcode/GenuineIntel.bin</userinput></screen>
412
413 <caution>
414 <para>
415 On some Skylake machines with hex Model Number '4e' (78 decimal) the
416 upgrade to microcode version '0xdc' is reported to cause the machine to
417 hang in early boot, and the fix is to revert to version 0xd6 which was
418 first shipped in the 20191115 microcode release.
419 </para>
420
421 <para>
422 At least one model '5e' Skylake does boot successfully with version
423 0xdc, but Intel has now shipped a 20200616 release which is intended for
424 distros which need an initrd that will boot on everyone's machine: it
425 reverts both Skylake variants ('4e' and '5e') to the old 0xd6.
426 </para>
427
428 <para>
429 For a Skylake which does not boot with 0xdc, reverting to 0xd6 will make
430 the machine usable, but without the SRBDS mitigations.
431 </para>
432 </caution>
433
434 <para>
435 Now prepare the initrd:
436 </para>
437
438<screen><userinput>find . | cpio -o -H newc &gt; /boot/microcode.img</userinput></screen>
439
440 <para>
441 You now need to add a new entry to /boot/grub/grub.cfg and
442 here you should add a new line after the linux line within the stanza.
443 If /boot is a separate mountpoint:
444 </para>
445
446<screen><userinput>initrd /microcode.img</userinput></screen>
447
448 <para>
449 or this if it is not:
450 </para>
451
452<screen><userinput>initrd /boot/microcode.img</userinput></screen>
453
454 <para>
455 If you are already booting with an initrd (see <xref
456 linkend="initramfs"/>), you should run <command>mkinitramfs</command>
457 again after putting the appropriate blob or container into <filename
458 class="directory">/lib/firmware</filename> as explained above.
459 Alternatively, you can have both initrd on the same line, such as
460 <userinput>initrd /microcode.img /other-initrd.img</userinput> (adapt
461 that as above if /boot is not a separate mountpoint).
462 </para>
463
464 <para>
465 You can now reboot with the added initrd, and then use the same
466 command to check that the early load worked:
467 </para>
468
469<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
470
471 <para>
472 If you updated to address vulnerabilities, you can look at <filename
473 class="directory">/sys/devices/system/cpu/vulnerabilities/</filename>
474 to see what is now reported.
475 </para>
476
477 <para>
478 The places and times where early loading happens are very different
479 in AMD and Intel machines. First, an Intel (Haswell) example with early loading:
480 </para>
481
482<screen><literal>[ 0.000000] microcode: microcode updated early to revision 0x28, date = 2019-11-12
483[ 0.000000] Linux version 5.6.2 (ken@plexi) (gcc version 9.2.0 (GCC)) #2 SMP PREEMPT Tue Apr 7 21:34:32 BST 2020
484[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.6.2-sda10 root=/dev/sda10 ro resume=/dev/sdb1
485[ 0.371462] microcode: sig=0x306c3, pf=0x2, revision=0x28
486[ 0.371491] microcode: Microcode Update Driver: v2.2.</literal></screen>
487
488
489 <para>
490 A historic AMD example:
491 </para>
492
493<screen><literal>[ 0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
494 #2 SMP Sun Feb 18 02:32:03 GMT 2018
495[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.15.3-sda5 root=/dev/sda5 ro
496[ 0.307619] microcode: microcode updated early to new patch_level=0x010000c8
497[ 0.307678] microcode: CPU0: patch_level=0x010000c8
498[ 0.307723] microcode: CPU1: patch_level=0x010000c8
499[ 0.307795] microcode: Microcode Update Driver: v2.2.</literal></screen>
500
501 </sect3>
502
503 </sect2>
504
505 <sect2 id="video-firmware">
506 <title>Firmware for Video Cards</title>
507
508 <sect3 id="ati-video-firmware">
509 <title>Firmware for ATI video chips (R600 and later)</title>
510
511 <para>
512 These instructions do NOT apply to old radeons before the R600
513 family. For those, the firmware is in the kernel's <filename
514 class='directory'>/lib/firmware/</filename> directory. Nor do they
515 apply if you intend to avoid a graphical setup such as Xorg and are
516 content to use the default 80x25 display rather than a framebuffer.
517 </para>
518
519 <para>
520 Early radeon devices only needed a single 2K blob of firmware. Recent
521 devices need several different blobs, and some of them are much bigger.
522 The total size of the radeon firmware directory is over 500K &mdash;
523 on a large modern system you can probably spare the space, but it is
524 still redundant to install all the unused files each time you build
525 a system.
526 </para>
527
528 <para>
529 A better approach is to install <xref linkend='pciutils'/> and then
530 use <userinput>lspci</userinput> to identify which VGA controller is
531 installed.
532 </para>
533
534 <para>
535 With that information, check the RadeonFeature page of the Xorg wiki
536 for <ulink url="http://wiki.x.org/wiki/RadeonFeature/#index5h2">Decoder
537 ring for engineering vs marketing names</ulink> to identify the family
538 (you may need to know this for the Xorg driver in BLFS &mdash;
539 Southern Islands and Sea Islands use the radeonsi driver) and the
540 specific model.
541 </para>
542
543 <para>
544 Now that you know which controller you are using, consult the
545 <ulink url="https://wiki.gentoo.org/wiki/Radeon#Firmware">
546 Radeon</ulink> page of the Gentoo wiki which has a table listing
547 the required firmware blobs for the various chipsets. Note that
548 Southern Islands and Sea Islands chips use different firmware for
549 kernel 3.17 and later compared to earlier kernels. Identify and
550 download the required blobs then install them:
551 </para>
552
553<screen><userinput>mkdir -pv /lib/firmware/radeon
554cp -v &lt;YOUR_BLOBS&gt; /lib/firmware/radeon</userinput></screen>
555
556 <para>
557 There are actually two ways of installing this firmware. BLFS, in the
558 'Kernel Configuration for additional firmware' section part of the
559 <xref linkend="xorg-ati-driver"/> section gives an example of
560 compiling the firmware into the kernel - that is slightly faster to
561 load, but uses more kernel memory. Here we will use the alternative
562 method of making the radeon driver a module. In your kernel config
563 set the following:
564 </para>
565
566<screen><literal>Device Drivers ---&gt;
567 Graphics support ---&gt;
568 Direct Rendering Manager ---&gt;
569 &lt;*&gt; Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
570 &lt;m&gt; ATI Radeon [CONFIG_DRM_RADEON]</literal></screen>
571
572 <para>
573 Loading several large blobs from /lib/firmware takes a noticeable
574 time, during which the screen will be blank. If you do not enable the
575 penguin framebuffer logo, or change the console size by using a bigger
576 font, that probably does not matter. If desired, you can slightly
577 reduce the time if you follow the alternate method of specifying 'y'
578 for CONFIG_DRM_RADEON covered in BLFS at the link above &mdash; you
579 must specify each needed radeon blob if you do that.
580 </para>
581
582 </sect3>
583
584 <sect3 id="nvidia-video-firmware">
585 <title>Firmware for Nvidia video chips</title>
586
587 <para>
588 Some Nvidia graphics chips need firmware updates to take advantage
589 of all the card's capability. These are generally the GeForce 8, 9,
590 9300, and 200-900 series chips. For more exact information, see
591 <ulink url=
592 "https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware"/>.
593 </para>
594
595 <para>
596 First, the kernel Nvidia driver must be activated:
597 </para>
598
599<screen><literal>Device Drivers ---&gt;
600 Graphics support ---&gt;
601 Direct Rendering Manager ---&gt;
602 &lt;*&gt; Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
603 &lt;*/m&gt; Nouveau (NVIDIA) cards [CONFIG_DRM_NOUVEAU]</literal></screen>
604
605 <para>
606 The steps to install the Nvidia firmware are:
607 </para>
608
609<screen><userinput>wget https://raw.github.com/imirkin/re-vp2/master/extract_firmware.py
610wget http://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86-325.15.run
611sh NVIDIA-Linux-x86-325.15.run --extract-only
612python extract_firmware.py
613mkdir -p /lib/firmware/nouveau
614cp -d nv* vuc-* /lib/firmware/nouveau/</userinput></screen>
615
616 </sect3>
617 </sect2>
618
619 <sect2 id="nic-firmware">
620 <title>Firmware for Network Interfaces</title>
621
622 <para>
623 The kernel likes to load firmware for some network drivers, particularly
624 those from Realtek (the /lib/linux-firmware/rtl_nic/) directory, but
625 they generally appear to work without it. Therefore, you can boot the
626 kernel, check dmesg for messages about this missing firmware, and if
627 necessary download the firmware and put it in the specified directory in
628 <filename class="directory">/lib/firmware</filename> so that it will
629 be found on subsequent boots. Note that with current kernels this
630 works whether or not the driver is compiled in or built as a module,
631 there is no need to build this firmware into the kernel.
632 Here is an example where the R8169 driver has been compiled in but the
633 firmware was not made available. Once the firmware had been provided,
634 there was no mention of it on later boots.
635 </para>
636
637<screen><literal>dmesg | grep firmware | grep r8169
638[ 7.018028] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
639[ 7.018036] r8169 0000:01:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)</literal></screen>
640
641 </sect2>
642
643 <sect2 id="other-firmware">
644 <title>Firmware for Other Devices</title>
645
646 <para>
647 Identifying the correct firmware will typically require you to install
648 <xref linkend='pciutils'/>, and then use <userinput>lspci</userinput>
649 to identify the device. You should then search online to check which
650 module it uses, which firmware, and where to obtain the firmware &mdash;
651 not all of it is in linux-firmware.
652 </para>
653
654 <para>
655 If possible, you should begin by using a wired connection when you first
656 boot your LFS system. To use a wireless connection you will need to
657 use a network tools such as <xref linkend='wireless_tools'/> and <xref
658 linkend='wpa_supplicant'/>.
659 </para>
660
661 <para>
662 Firmware may also be needed for other devices such as some SCSI
663 controllers, bluetooth adaptors, or TV recorders. The same principles
664 apply.
665 </para>
666
667 </sect2>
668
669</sect1>
Note: See TracBrowser for help on using the repository browser.