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