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: bdubbs $</othername>
|
---|
13 | <date>$Date: 2012-03-13 13:19:34 -0500 (Tue, 13 Mar 2012) $</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. The kernel contains 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="http://anduin.linuxfromscratch.org/sources/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 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>
|
---|
76 |
|
---|
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>
|
---|
84 |
|
---|
85 | <para condition="html" role="usernotes">User Notes:
|
---|
86 | <ulink url="&blfs-wiki;/aboutfirmware"/></para>
|
---|
87 |
|
---|
88 | <sect2 id="cpu-microcode">
|
---|
89 | <title>Microcode updates for CPUs</title>
|
---|
90 |
|
---|
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>
|
---|
98 |
|
---|
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="https://lwn.net/Articles/530346/">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="http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwellyi/">
|
---|
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>
|
---|
111 |
|
---|
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>
|
---|
116 |
|
---|
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>
|
---|
122 |
|
---|
123 | <para>To confirm what processor(s) you have (if more than one, they will be
|
---|
124 | identical) look in /proc/cpuinfo.</para>
|
---|
125 |
|
---|
126 | <sect3 id="intel-microcode">
|
---|
127 | <title>Intel Microcode for the CPU</title>
|
---|
128 |
|
---|
129 | <bridgehead renderas="sect4">Required Package</bridgehead>
|
---|
130 | <para role='required'>
|
---|
131 | <ulink url='http://fedorahosted.org/released/microcode_ctl/'/></para>
|
---|
132 |
|
---|
133 | <para>For intel CPUs an extra package, microcode_ctl, is required. The
|
---|
134 | package chosen is the version hosted at fedora — 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>
|
---|
138 |
|
---|
139 | <para>Download the latest version from the link above; when last checked,
|
---|
140 | this was 2.1-7 and is updated when intel releases new microcode.</para>
|
---|
141 |
|
---|
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>
|
---|
147 |
|
---|
148 | <para>Begin by extracting the tarball and changing to the directory it created.
|
---|
149 | Then change to the source diirectory and run:</para>
|
---|
150 |
|
---|
151 | <screen><userinput>make</userinput></screen>
|
---|
152 |
|
---|
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>
|
---|
157 |
|
---|
158 | <screen><userinput>head -n7 /proc/cpuinfo</userinput></screen>
|
---|
159 |
|
---|
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 <XX-YY-ZZ>
|
---|
167 | by the identifier for your machine) to where the kernel can find it:</para>
|
---|
168 |
|
---|
169 | <screen><userinput>mkdir -pv /lib/firmware/intel-ucode
|
---|
170 | cp -v <XX-YY-ZZ> /lib/firmware/intel-ucode</userinput></screen>
|
---|
171 |
|
---|
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>
|
---|
175 |
|
---|
176 | <screen><literal>Processor type and features --->
|
---|
177 | <M> CPU microcode loading support [CONFIG_MICROCODE]
|
---|
178 | [*] Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen>
|
---|
179 |
|
---|
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>
|
---|
184 |
|
---|
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 <tigran@aivazian.fsnet.co.uk>, Peter Oruba</literal></screen>
|
---|
200 |
|
---|
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>
|
---|
204 |
|
---|
205 | </sect3>
|
---|
206 |
|
---|
207 | <sect3 id="and-microcode">
|
---|
208 | <title>AMD Microcode for the CPU</title>
|
---|
209 |
|
---|
210 | <para>Begin by downloading a container of firmware for your CPU family
|
---|
211 | from <ulink
|
---|
212 | url='http://anduin.linuxfromscratch.org/sources/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>
|
---|
217 |
|
---|
218 | <screen><userinput>mkdir -pv /lib/firmware/amd-ucode
|
---|
219 | cp -v microcode_amd* /lib/firmware/amd-ucode</userinput></screen>
|
---|
220 |
|
---|
221 | <para>When you configure the kernel, use the following options to try
|
---|
222 | late loading of AMD microcode:</para>
|
---|
223 |
|
---|
224 | <screen><literal>Processor type and features --->
|
---|
225 | <M> CPU microcode loading support [CONFIG_MICROCODE]
|
---|
226 | [*] AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen>
|
---|
227 |
|
---|
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>
|
---|
232 |
|
---|
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 <tigran@aivazian.fsnet.co.uk>, Peter Oruba</literal></screen>
|
---|
238 |
|
---|
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>
|
---|
242 |
|
---|
243 | </sect3>
|
---|
244 |
|
---|
245 | <sect3 id="early-microcode">
|
---|
246 | <title>Early loading of microcode</title>
|
---|
247 |
|
---|
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>
|
---|
253 |
|
---|
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>
|
---|
258 |
|
---|
259 | <screen><userinput>mkdir -p initrd/kernel/x86/microcode
|
---|
260 | cd initrd</userinput></screen>
|
---|
261 |
|
---|
262 | <para>For an AMD machine, use the following command (replace
|
---|
263 | <MYCONTAINER> with the name of the container for your CPU's
|
---|
264 | family):</para>
|
---|
265 |
|
---|
266 | <screen><userinput>cp -v /lib/firmware/amd_ucode/<MYCONTAINER> kernel/x86/microcode/AuthenticAMD.bin</userinput></screen>
|
---|
267 |
|
---|
268 | <para>Or for an Intel machine copy the appropriate blob using this command:</para>
|
---|
269 |
|
---|
270 | <screen><userinput>cp -v /lib/firmware/intel-ucode/<XX-YY-ZZ> kernel/x86/microcode/GenuineIntel.bin</userinput></screen>
|
---|
271 |
|
---|
272 | <para>Now prepare the initrd:</para>
|
---|
273 |
|
---|
274 | <screen><userinput>find . | cpio -o -H newc > /boot/microcode.img</userinput></screen>
|
---|
275 |
|
---|
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>
|
---|
282 |
|
---|
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>
|
---|
286 |
|
---|
287 | <screen><userinput>initrd /microcode.img</userinput></screen>
|
---|
288 |
|
---|
289 | <para>or this if it is not:</para>
|
---|
290 |
|
---|
291 | <screen><userinput>initrd /boot/microcode.img</userinput></screen>
|
---|
292 |
|
---|
293 | <para>You must also change the kernel config:</para>
|
---|
294 |
|
---|
295 | <screen><literal>General Setup --->
|
---|
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>
|
---|
298 |
|
---|
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
|
---|
302 | CONFIG_MICROCODE_EARLY=y.</para>
|
---|
303 |
|
---|
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>
|
---|
310 |
|
---|
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
|
---|
315 | ...
|
---|
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)
|
---|
321 | ...
|
---|
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 <tigran@aivazian.fsnet.co.uk>, Peter Oruba</literal></screen>
|
---|
327 |
|
---|
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 — compare this output to the AMD
|
---|
331 | late loading messages (above) from the same machine:</para>
|
---|
332 |
|
---|
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
|
---|
336 | ...
|
---|
337 | [ 0.584009] Trying to unpack rootfs image as initramfs...
|
---|
338 | [ 0.584092] microcode: updated early to new patch_level=0x010000c8
|
---|
339 | ...
|
---|
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 <tigran@aivazian.fsnet.co.uk>, Peter Oruba</literal></screen>
|
---|
343 |
|
---|
344 | </sect3>
|
---|
345 |
|
---|
346 | </sect2>
|
---|
347 |
|
---|
348 | <sect2 id="ati-video-firmware">
|
---|
349 | <title>Firmware for ATI video chips (R600 and later)</title>
|
---|
350 |
|
---|
351 | <para>These instructions do NOT apply to old radeons before the R600
|
---|
352 | family. For those, the firmware is in the kernel's <filename
|
---|
353 | class='directory'>/lib/firmware/</filename> directory. Nor do they apply if
|
---|
354 | you intend to avoid a graphical setup such as Xorg and are content to use
|
---|
355 | the default 80x25 display rather than a framebuffer. </para>
|
---|
356 |
|
---|
357 | <para> Early radeon devices only needed a single 2K blob of firmware.
|
---|
358 | Recent devices need several different blobs, and some of them are much
|
---|
359 | bigger. The total size of the radeon firmware directory is over 500K — on a
|
---|
360 | large modern system you can probably spare the space, but it is still
|
---|
361 | redundant to install all the unused files each time you build a system.</para>
|
---|
362 |
|
---|
363 | <para>A better approach is to install <xref linkend='pciutils'/> and then
|
---|
364 | use <userinput>lspci</userinput> to identify which VGA controller is
|
---|
365 | installed.</para>
|
---|
366 |
|
---|
367 | <para>With that information, check the RadeonFeature page of the Xorg wiki
|
---|
368 | for <ulink url="http://wiki.x.org/wiki/RadeonFeature/#index5h2">Decoder
|
---|
369 | ring for engineering vs marketing names</ulink> to identify the family (you
|
---|
370 | may need to know this for the Xorg driver in BLFS — Southern Islands and
|
---|
371 | Sea Islands use the radeonsi driver) and the specific model.</para>
|
---|
372 |
|
---|
373 | <para>Now that you know which controller you are using, consult the
|
---|
374 | <ulink url="https://wiki.gentoo.org/wiki/Radeon#Firmware">Radeon</ulink> page
|
---|
375 | of the Gentoo wiki which has a table listing the required firmware blobs
|
---|
376 | for the various chipsets. Note that Southern Islands and Sea Islands chips
|
---|
377 | use different firmware for kernel 3.17 and later compared to earlier
|
---|
378 | kernels. Identify and download the required blobs then install them:</para>
|
---|
379 |
|
---|
380 | <screen><userinput>mkdir -pv /lib/firmware/radeon
|
---|
381 | cp -v <YOUR_BLOBS> /lib/firmware/radeon</userinput></screen>
|
---|
382 |
|
---|
383 | <para>There are actually two ways of installing this firmware. BLFS, in the
|
---|
384 | 'Kernel Configuration for additional firmware' section part of the <xref
|
---|
385 | linkend="xorg-ati-driver"/> section gives an example of compiling the
|
---|
386 | firmware into the kernel - that is slightly faster to load, but uses more
|
---|
387 | kernel memory. Here we will use the alternative method of making the radeon
|
---|
388 | driver a module. In your kernel config set the following: </para>
|
---|
389 |
|
---|
390 | <screen><literal>Device Drivers --->
|
---|
391 | Graphics support --->
|
---|
392 | Direct Rendering Manager --->
|
---|
393 | <*> Direct Rendering Manager (XFree86 ... support) [CONFIG_DRM]
|
---|
394 | <m> ATI Radeon [CONFIG_DRM_RADEON]</literal></screen>
|
---|
395 |
|
---|
396 | <para>Loading several large blobs from /lib/firmware takes a noticeable
|
---|
397 | time, during which the screen will be blank. If you do not enable the
|
---|
398 | penguin framebuffer logo, or change the console size by using a bigger
|
---|
399 | font, that probably does not matter. If desired, you can slightly
|
---|
400 | reduce the time if you follow the alternate method of specifying 'y' for
|
---|
401 | CONFIG_DRM_RADEON covered in BLFS at the link above — you must specify each
|
---|
402 | needed radeon blob if you do that.</para>
|
---|
403 |
|
---|
404 | </sect2>
|
---|
405 |
|
---|
406 | <sect2 id="nic-firmware">
|
---|
407 | <title>Firmware for Network Interfaces</title>
|
---|
408 |
|
---|
409 | <para>The kernel likes to load firmware for some network drivers,
|
---|
410 | particularly those from Realtek (the /lib/linux-firmware/rtl_nic/) directory,
|
---|
411 | but they generally appear to work without it. Therefore, you can boot the
|
---|
412 | kernel, check dmesg for messages about this missing firmware, and if
|
---|
413 | necessary download the firmware and put it in the specified directory in
|
---|
414 | /lib/firmware so that it will be found on subsequent boots. Note that with
|
---|
415 | current kernels this works whether or not the driver is compiled in or
|
---|
416 | built as a module, there is no need to build this firmware into the kernel.
|
---|
417 | Here is an example where the R8169 driver has been compiled in but the
|
---|
418 | firmware was not made available. Once the firmware had been provided, there
|
---|
419 | was no mention of it on later boots. </para>
|
---|
420 |
|
---|
421 | <screen><literal>dmesg | grep firmware | grep r8169
|
---|
422 | [ 7.018028] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
|
---|
423 | [ 7.018036] r8169 0000:01:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)</literal></screen>
|
---|
424 |
|
---|
425 | </sect2>
|
---|
426 |
|
---|
427 | <sect2 id="other-firmware">
|
---|
428 | <title>Firmware for Other Devices</title>
|
---|
429 |
|
---|
430 | <para> Identifying the correct firmware will typically require you to
|
---|
431 | install <xref linkend='pciutils'/>, and then use
|
---|
432 | <userinput>lspci</userinput> to identify the device. You should then search
|
---|
433 | online to check which module it uses, which firmware, and where to obtain
|
---|
434 | the firmware — not all of it is in linux-firmware.</para>
|
---|
435 |
|
---|
436 | <para>If possible, you should begin by using a wired connection when you
|
---|
437 | first boot your LFS system. To use a wireless connection you will need to
|
---|
438 | use a network tools such as <xref linkend='wireless_tools'/> and <xref
|
---|
439 | linkend='wpa_supplicant'/>.</para>
|
---|
440 |
|
---|
441 | <para>Firmware may also be needed for other devices such as some SCSI
|
---|
442 | controllers, bluetooth adaptors, or TV recorders. The same principles
|
---|
443 | apply.</para>
|
---|
444 |
|
---|
445 | </sect2>
|
---|
446 |
|
---|
447 | </sect1>
|
---|