source: postlfs/config/firmware.xml@ fe2553a

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 fe2553a was fe2553a, checked in by Ken Moffat <ken@…>, 16 months ago

Microcode - add a Caution for certain Intel machines.

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

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