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