source: postlfs/config/firmware.xml@ 1cc5345

10.0 10.1 11.0 7.10 7.9 8.0 8.1 8.2 8.3 8.4 9.0 9.1 basic bdubbs/svn elogind ken/refactor-virt lazarus nosym perl-modules qt5new trunk upgradedb xry111/git-date xry111/git-date-for-trunk xry111/git-date-test
Last change on this file since 1cc5345 was 1cc5345, checked in by Bruce Dubbs <bdubbs@…>, 6 years ago

Add section about nvidia firmware.
Update kde4 package links.
Tag kde and dependencies.

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

  • Property mode set to 100644
File size: 23.2 KB
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3 "" [
4 <!ENTITY % general-entities SYSTEM "../../general.ent">
5 %general-entities;
8<sect1 id="postlfs-firmware" xreflabel="About Firmware">
9 <?dbhtml filename="firmware.html"?>
11 <sect1info>
12 <othername>$LastChangedBy$</othername>
13 <date>$Date$</date>
14 </sect1info>
16 <title>About Firmware</title>
18 <indexterm zone="postlfs-firmware">
19 <primary sortas="e-lib-firmware">/lib/firmware</primary>
20 </indexterm>
22 <para> 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>
27 <para>Preparing firmware for multiple different machines, as a distro would
28 do, is outside the scope of this book.</para>
30 <para>Currently, most firmware can be found at a <userinput>git</userinput>
31 repository: <ulink
32 url=""/>.
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>
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>
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>
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>
51 <para>Firmware for PCs falls into four categories:</para>
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 only
60 apply to ATI devices : Radeons require firmware to be able to use KMS
61 (kernel modesetting - the preferred option) as well as for Xorg. For
62 earlier radeon chips (before the R600), the firmware is still in the
63 kernel.</para>
64 </listitem>
65 <listitem>
66 <para>Firmware updates for wired network ports. Mostly they work even
67 without the updates, but one must assume that they will work better with
68 the updated firmware.</para>
69 </listitem>
70 <listitem>
71 <para>Firmware for other devices, such as wifi. These devices are not
72 required for the PC to boot, but need the firmware before these devices
73 can be used.</para>
74 </listitem>
75 </itemizedlist>
77 <note><para>Although not needed to load a firmware blob, the following
78 tools may be useful for determining, obtaining, or preparing the needed
79 firmware in order to load it into the system:
80 <xref linkend="cpio"/>,
81 <xref linkend="git"/>,
82 <xref linkend="pciutils"/>, and
83 <xref linkend="wget"/></para></note>
85 <para condition="html" role="usernotes">User Notes:
86 <ulink url="&blfs-wiki;/aboutfirmware"/></para>
88 <sect2 id="cpu-microcode">
89 <title>Microcode updates for CPUs</title>
91 <para>In general, microcode can be loaded by the BIOS or UEFI, and it might
92 be updated by upgrading to a newer version of those. On linux, you can also
93 load the microcode from the kernel if you are using an AMD family 10h or
94 later processor (first introduced late 2007), or an intel processor from
95 1998 and later (Pentium4, Core, etc), if updated microcode has been
96 released. These updates only last until the machine is powered off, so they
97 need to be applied on every boot.</para>
99 <para>There are two ways of loading the microcode, described as 'early' and
100 'late'. Early loading happens before userspace has been started, late
101 loading happens when userspace has started. Not surprisingly, early loading
102 is preferred, (see e.g. an explanatory comment in a kernel commit noted at
103 <ulink url="">x86/microcode: Early load
104 microcode </ulink> on LWN.) Indeed, it is needed to work around one
105 particular erratum in early intel Haswell processors which had TSX enabled.
106 (See <ulink
107 url="">
108 Intel Disables TSX Instructions: Erratum Found in Haswell, Haswell-E/EP,
109 Broadwell-Y</ulink>.) Without this update glibc can do the wrong thing in
110 uncommon situations.</para>
112 <para>It is much simpler to begin by building a kernel which boots on
113 your hardware, try late microcode loading to see if there is an update (in
114 many cases the BIOS or UEFI will have already applied any update), and then
115 take the extra steps required for early loading.</para>
117 <para>This means you will be reconfiguring your kernel if you use early
118 loading, so keep the built source around to minimise what gets rebuilt, and
119 if you are at all uncertain, add your own identifier (A,B, etc) to the end
120 of the EXTRAVERSION in the kernel configuration, e.g. "EXTRAVERSION -A" if
121 nothing was set.</para>
123 <para>To confirm what processor(s) you have (if more than one, they will be
124 identical) look in /proc/cpuinfo.</para>
126 <sect3 id="intel-microcode">
127 <title>Intel Microcode for the CPU</title>
129 <bridgehead renderas="sect4">Required Package</bridgehead>
130 <para role='required'>
131 <ulink url=''/></para>
133 <para>For intel CPUs an extra package, microcode_ctl, is required. The
134 package chosen is the version hosted at fedora &mdash; there is an
135 alternative version at github from the same packager, but that still
136 includes a redundant old version of an AMD microcode container, and also
137 requires the unzip package.</para>
139 <para>Download the latest version from the link above; when last checked
140 this was 2.1-8 and is updated when intel releases new microcode.</para>
142 <para>This package reformats the microcode supplied by intel into a
143 format which the kernel can apply. The program
144 <userinput>intel-microcode2ucode</userinput> is built and invoked by the
145 Makefile to create the individual firmware blobs, so there is no reason
146 to install it.</para>
148 <para>Begin by extracting the tarball and changing to the directory it created.
149 Then change to the source directory and run:</para>
153 <para>This creates various blobs with names in the form XX-YY-ZZ. Now you
154 need to determine your processor's identity, to see if there is any
155 microcode for it. Determine the decimal values of the cpu family, model
156 and stepping by running:</para>
158<screen><userinput>head -n7 /proc/cpuinfo</userinput></screen>
160 <para>Now convert the cpu family, model and stepping to pairs of hexadecimal
161 digits. For a SandyBridge i3-2120 (described as Intel(R) Core(TM) i3-2120
162 CPU) the relevant values are cpu family 6, model 42, stepping 7 so in
163 this case the required identification is 06-2a-07. A look at the blobs
164 will show that there is one for this CPU (although it might
165 have already been applied by the BIOS). If there is a blob for your
166 system then test if it will be applied by copying it (replace &lt;XX-YY-ZZ&gt;
167 by the identifier for your machine) to where the kernel can find it:</para>
169<screen><userinput>mkdir -pv /lib/firmware/intel-ucode
170cp -v &lt;XX-YY-ZZ&gt; /lib/firmware/intel-ucode</userinput></screen>
172 <para>Now that the intel microcode has been prepared, use the following
173 options when you configure the kernel to try late loading of the intel
174 microcode:</para>
176<screen><literal>Processor type and features ---&gt;
177 &lt;M&gt; CPU microcode loading support [CONFIG_MICROCODE]
178 [*] Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen>
180 <para>After you have successfully booted the new system, use the command
181 <userinput>dmesg | grep microcode</userinput> and study the results to
182 see if the message new patch_level appears. This example from the
183 SandyBridge i3:</para>
185<screen><literal>[ 0.059906] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode
186[ 2.603083] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x23
187[ 2.669378] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x23
188[ 2.669994] microcode: CPU0 updated to revision 0x29, date = 2013-06-12
189[ 2.670069] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x23
190[ 2.670139] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x23
191[ 2.670501] microcode: CPU1 updated to revision 0x29, date = 2013-06-12
192[ 2.670509] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x23
193[ 2.670540] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x23
194[ 2.670917] microcode: CPU2 updated to revision 0x29, date = 2013-06-12
195[ 2.670955] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x23
196[ 2.670988] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x23
197[ 2.671348] microcode: CPU3 updated to revision 0x29, date = 2013-06-12
198[ 2.671356] perf_event_intel: PEBS enabled due to microcode update
199[ 2.671412] microcode: Microcode Update Driver: v2.00 &lt;;, Peter Oruba</literal></screen>
201 <para>If the microcode was not updated, there is no new microcode for
202 this system's processor. If it did get updated, you can now proceed to <xref
203 linkend='early-microcode'/>.</para>
205 </sect3>
207 <sect3 id="and-microcode">
208 <title>AMD Microcode for the CPU</title>
210 <para>Begin by downloading a container of firmware for your CPU family
211 from <ulink
212 url='&sources-anduin-http;/linux-firmware/amd-ucode/'/>.
213 The family is always specified in hex. Families 10h to 14h (16 to 20)
214 are in microcode_amd.bin. Families 15h and 16h have their own containers.
215 Create the required directory and put the firmware you downloaded into
216 it as the <systemitem class="username">root</systemitem> user:</para>
218<screen><userinput>mkdir -pv /lib/firmware/amd-ucode
219cp -v microcode_amd* /lib/firmware/amd-ucode</userinput></screen>
221 <para>When you configure the kernel, use the following options to try
222 late loading of AMD microcode:</para>
224<screen><literal>Processor type and features ---&gt;
225 &lt;M&gt; CPU microcode loading support [CONFIG_MICROCODE]
226 [*] AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen>
228 <para>After you have successfully booted the new system, use the command
229 <userinput>dmesg | grep microcode</userinput> and study the results to see
230 if the message new patch_level appears, as in this example from an old
231 Athlon(tm) II X2:</para>
233<screen><literal>[ 4.183907] microcode: CPU0: patch_level=0x010000b6
234[ 4.184271] microcode: CPU0: new patch_level=0x010000c8
235[ 4.184278] microcode: CPU1: patch_level=0x010000b6
236[ 4.184283] microcode: CPU1: new patch_level=0x010000c8
237[ 4.184359] microcode: Microcode Update Driver: v2.00 &lt;;, Peter Oruba</literal></screen>
239 <para>If the microcode was not updated, there is no new microcode for
240 this system's processor. If it did get updated, you can now proceed to <xref
241 linkend='early-microcode'/>.</para>
243 </sect3>
245 <sect3 id="early-microcode">
246 <title>Early loading of microcode</title>
248 <para>If you have established that updated microcode is available for
249 your system, it is time to prepare it for early loading. This requires
250 an additional package, <xref linkend='cpio'/>, as well as changes to
251 the kernel config and the creation of an initrd which will need to be
252 added to grub.cfg.</para>
254 <para>It does not matter where you prepare the initrd, and once it is
255 working you can apply the same initrd to later LFS systems or newer
256 kernels on this same machine, at least until any newer microcode is
257 released. Use the following commands:</para>
259<screen><userinput>mkdir -p initrd/kernel/x86/microcode
260cd initrd</userinput></screen>
262 <para>For an AMD machine, use the following command (replace
263 &lt;MYCONTAINER&gt; with the name of the container for your CPU's
264 family):</para>
266<screen><userinput>cp -v /lib/firmware/amd_ucode/&lt;MYCONTAINER&gt; kernel/x86/microcode/AuthenticAMD.bin</userinput></screen>
268 <para>Or for an Intel machine copy the appropriate blob using this command:</para>
270<screen><userinput>cp -v /lib/firmware/intel-ucode/&lt;XX-YY-ZZ&gt; kernel/x86/microcode/GenuineIntel.bin</userinput></screen>
272 <para>Now prepare the initrd:</para>
274<screen><userinput>find . | cpio -o -H newc &gt; /boot/microcode.img</userinput></screen>
276 <para>You will now need to reconfigure and rebuild your kernel. It is
277 safer to either add/change the EXTRAVERSION in the kernel's configuration
278 and install the newer kernel with a new name, or else (unless you have a
279 machine which requires an early firmware update) wait for the next
280 SUBLEVEL kernel release so that you can fall back to the existing kernel
281 in the event that something goes wrong.</para>
283 <para>You will also need to add a new entry to /boot/grub/grub.cfg and
284 here you should add a new line after the linux line within the stanza.
285 If /boot is a separate mountpoint: </para>
287<screen><userinput>initrd /microcode.img</userinput></screen>
289 <para>or this if it is not:</para>
291<screen><userinput>initrd /boot/microcode.img</userinput></screen>
293 <para>You must also change the kernel config:</para>
295<screen><literal>General Setup ---&gt;
296 [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
297 [y] CPU microcode loading support [CONFIG_MICROCODE]</literal></screen>
299 <para>Retain the setting for INTEL or AMD microcode. When you have saved
300 the .config file, either CONFIG_MICROCODE_INTEL_EARLY=y or
301 CONFIG_MICROCODE_AMD_EARLY=y should be set, together with
304 <para>When you have installed and booted this kernel, you should check
305 the output of dmesg to confirm that the early load worked. The places and
306 times where this happens are very different in AMD and Intel machines.
307 First, an Intel example where a development kernel is being tested,
308 showing that the first notification comes before the kernel version is
309 mentioned:</para>
311<screen><literal>[ 0.000000] CPU0 microcode updated early to revision 0x29, date = 2013-06-12
312[ 0.000000] Linux version 4.0.0-rc6 (ken@jtm1) (gcc version 4.9.2 (GCC) )
313 #3 SMP PREEMPT Mon Mar 30 21:26:02 BST 2015
314[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.0.0-rc6-sda13 root=/dev/sda13 ro
316[ 0.103091] CPU1 microcode updated early to revision 0x29, date = 2013-06-12
317[ 0.113241] #2
318[ 0.134631] #3
319[ 0.147821] x86: Booted up 1 node, 4 CPUs
320[ 0.147936] smpboot: Total of 4 processors activated (26338.66 BogoMIPS)
322[ 0.272643] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x29
323[ 0.272709] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x29
324[ 0.272775] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x29
325[ 0.272842] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x29
326[ 0.272941] microcode: Microcode Update Driver: v2.00 &lt;;, Peter Oruba</literal></screen>
328 <para>A second AMD example is where the machine was running a stable
329 kernel on an older version of LFS. Note that here there is no mention of
330 the previous microcode version &mdash; compare this output to the AMD
331 late loading messages (above) from the same machine:</para>
333<screen><literal>[ 0.000000] Linux version 3.18.11 (ken@milliways) (gcc version 4.9.1 (GCC) )
334 #4 SMP Thu Apr 9 21:51:05 BST 2015
335[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.18.11-sda5 root=/dev/sda5 video=800x600 ro
337[ 0.584009] Trying to unpack rootfs image as initramfs...
338[ 0.584092] microcode: updated early to new patch_level=0x010000c8
340[ 0.586733] microcode: CPU0: patch_level=0x010000c8
341[ 0.586778] microcode: CPU1: patch_level=0x010000c8
342[ 0.586866] microcode: Microcode Update Driver: v2.00 &lt;;, Peter Oruba</literal></screen>
344 </sect3>
346 </sect2>
348 <sect2 id="video-firmware">
349 <title>Firmware for Video Cards</title>
351 <sect3 id="ati-video-firmware">
352 <title>Firmware for ATI video chips (R600 and later)</title>
354 <para>These instructions do NOT apply to old radeons before the R600
355 family. For those, the firmware is in the kernel's <filename
356 class='directory'>/lib/firmware/</filename> directory. Nor do they apply if
357 you intend to avoid a graphical setup such as Xorg and are content to use
358 the default 80x25 display rather than a framebuffer. </para>
360 <para> Early radeon devices only needed a single 2K blob of firmware.
361 Recent devices need several different blobs, and some of them are much
362 bigger. The total size of the radeon firmware directory is over 500K &mdash; on a
363 large modern system you can probably spare the space, but it is still
364 redundant to install all the unused files each time you build a system.</para>
366 <para>A better approach is to install <xref linkend='pciutils'/> and then
367 use <userinput>lspci</userinput> to identify which VGA controller is
368 installed.</para>
370 <para>With that information, check the RadeonFeature page of the Xorg wiki
371 for <ulink url="">Decoder
372 ring for engineering vs marketing names</ulink> to identify the family (you
373 may need to know this for the Xorg driver in BLFS &mdash; Southern Islands and
374 Sea Islands use the radeonsi driver) and the specific model.</para>
376 <para>Now that you know which controller you are using, consult the
377 <ulink url="">Radeon</ulink> page
378 of the Gentoo wiki which has a table listing the required firmware blobs
379 for the various chipsets. Note that Southern Islands and Sea Islands chips
380 use different firmware for kernel 3.17 and later compared to earlier
381 kernels. Identify and download the required blobs then install them:</para>
383<screen><userinput>mkdir -pv /lib/firmware/radeon
384cp -v &lt;YOUR_BLOBS&gt; /lib/firmware/radeon</userinput></screen>
386 <para>There are actually two ways of installing this firmware. BLFS, in the
387 'Kernel Configuration for additional firmware' section part of the <xref
388 linkend="xorg-ati-driver"/> section gives an example of compiling the
389 firmware into the kernel - that is slightly faster to load, but uses more
390 kernel memory. Here we will use the alternative method of making the radeon
391 driver a module. In your kernel config set the following: </para>
393<screen><literal>Device Drivers ---&gt;
394 Graphics support ---&gt;
395 Direct Rendering Manager ---&gt;
396 &lt;*&gt; Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
397 &lt;m&gt; ATI Radeon [CONFIG_DRM_RADEON]</literal></screen>
399 <para>Loading several large blobs from /lib/firmware takes a noticeable
400 time, during which the screen will be blank. If you do not enable the
401 penguin framebuffer logo, or change the console size by using a bigger
402 font, that probably does not matter. If desired, you can slightly
403 reduce the time if you follow the alternate method of specifying 'y' for
404 CONFIG_DRM_RADEON covered in BLFS at the link above &mdash; you must specify each
405 needed radeon blob if you do that.</para>
407 </sect3>
409 <sect3 id="nvidia-video-firmware">
410 <title>Firmware for Nvidia video chips</title>
412 <para>Some Nvidia graphics chips need firmware updates to take advantage
413 of all the card's capability. These are generally the GeForce 8, 9, 9300,
414 and 200-900 series chips. For more exact information, see <ulink
415 url="">
418 <para>First, the kernel Nvidia driver must be activated:</para>
420<screen><literal>Device Drivers ---&gt;
421 Graphics support ---&gt;
422 Direct Rendering Manager ---&gt;
423 &lt;*&gt; Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
424 &lt;*/m&gt; Nouveau (NVIDIA) cards [CONFIG_DRM_NOUVEAU]</literal></screen>
426 <para>The steps to install the Nvidia firmware are:</para>
430sh --extract-only
432mkdir -p /lib/firmware/nouveau
433cp -d nv* vuc-* /lib/firmware/nouveau/</userinput></screen>
435 </sect3>
436 </sect2>
438 <sect2 id="nic-firmware">
439 <title>Firmware for Network Interfaces</title>
441 <para>The kernel likes to load firmware for some network drivers,
442 particularly those from Realtek (the /lib/linux-firmware/rtl_nic/) directory,
443 but they generally appear to work without it. Therefore, you can boot the
444 kernel, check dmesg for messages about this missing firmware, and if
445 necessary download the firmware and put it in the specified directory in
446 /lib/firmware so that it will be found on subsequent boots. Note that with
447 current kernels this works whether or not the driver is compiled in or
448 built as a module, there is no need to build this firmware into the kernel.
449 Here is an example where the R8169 driver has been compiled in but the
450 firmware was not made available. Once the firmware had been provided, there
451 was no mention of it on later boots. </para>
453<screen><literal>dmesg | grep firmware | grep r8169
454[ 7.018028] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
455[ 7.018036] r8169 0000:01:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)</literal></screen>
457 </sect2>
459 <sect2 id="other-firmware">
460 <title>Firmware for Other Devices</title>
462 <para> Identifying the correct firmware will typically require you to
463 install <xref linkend='pciutils'/>, and then use
464 <userinput>lspci</userinput> to identify the device. You should then search
465 online to check which module it uses, which firmware, and where to obtain
466 the firmware &mdash; not all of it is in linux-firmware.</para>
468 <para>If possible, you should begin by using a wired connection when you
469 first boot your LFS system. To use a wireless connection you will need to
470 use a network tools such as <xref linkend='wireless_tools'/> and <xref
471 linkend='wpa_supplicant'/>.</para>
473 <para>Firmware may also be needed for other devices such as some SCSI
474 controllers, bluetooth adaptors, or TV recorders. The same principles
475 apply.</para>
477 </sect2>
Note: See TracBrowser for help on using the repository browser.