Changeset 0576c595 for postlfs/config
- Timestamp:
- 03/15/2017 03:07:05 AM (7 years ago)
- Branches:
- 10.0, 10.1, 11.0, 11.1, 11.2, 11.3, 12.0, 12.1, 8.1, 8.2, 8.3, 8.4, 9.0, 9.1, basic, bdubbs/svn, elogind, kea, ken/TL2024, ken/inkscape-core-mods, ken/tuningfonts, lazarus, lxqt, perl-modules, plabs/newcss, plabs/python-mods, python3.11, qt5new, rahul/power-profiles-daemon, renodr/vulkan-addition, trunk, upgradedb, xry111/intltool, xry111/llvm18, xry111/soup3, xry111/test-20220226, xry111/xf86-video-removal
- Children:
- ee4bec2d
- Parents:
- 13b9ae57
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
postlfs/config/firmware.xml
r13b9ae57 r0576c595 97 97 need to be applied on every boot.</para> 98 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 99 <para>Intel provide frequent updates of their microcode. It is not uncommon 100 to find a newer version of microcode for an Intel processor even two years 101 after its release. New versions of AMD firmware are less common.</para> 102 103 <para>There used to be two ways of loading the microcode, described as 'early' 104 and 'late'. Early loading happens before userspace has been started, late 105 loading happens after userspace has started. Not surprisingly, early loading 106 was preferred, (see e.g. an explanatory comment in a kernel commit noted at 103 107 <ulink url="https://lwn.net/Articles/530346/">x86/microcode: Early load 104 108 microcode </ulink> on LWN.) Indeed, it is needed to work around one … … 108 112 Intel Disables TSX Instructions: Erratum Found in Haswell, Haswell-E/EP, 109 113 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> 114 uncommon situations. </para> 115 116 <para>As a result, early loading is now expected, although for the moment 117 (4.9 kernels) it is still possible to manually force late loading of 118 microcode for testing. You will need to reconfigure your kernel for either 119 method. The instructions here will create a kernel 120 <filename>.config</filename> to suite early loading, before forcing late 121 loading to see if there is any microcode. If there is, the instructions 122 then show you how to create an initrd for early loading.</para> 122 123 123 124 <para>To confirm what processor(s) you have (if more than one, they will be … … 126 127 <sect3 id="intel-microcode"> 127 128 <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. The134 package chosen is the version hosted at fedora — there is an135 alternative version at github from the same packager, but that still136 includes a redundant old version of an AMD microcode container, and also137 requires the unzip package.</para>138 139 <para>Download the latest version from the link above; when last checked140 this was 2.1-8 and is updated when Intel releases new microcode.</para>141 142 <para>This package reformats the microcode supplied by Intel into a143 format which the kernel can apply. The program144 <userinput>intel-microcode2ucode</userinput> is built and invoked by the145 Makefile to create the individual firmware blobs, so there is no reason146 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 directory 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 you154 need to determine your processor's identity, to see if there is any155 microcode for it. Determine the decimal values of the cpu family, model156 and stepping by running:</para>157 -->158 129 159 130 <bridgehead renderas="sect4">Required File</bridgehead> … … 201 172 202 173 <para>Convert the cpu family, model and stepping to pairs of hexadecimal 203 digits. For a SandyBridge i3-2120 (described as Intel(R) Core(TM) i3-2120204 CPU) the relevant values are cpu family 6, model 42, stepping 7so in205 this case the required identification is 06- 2a-07. A look at the blobs174 digits. For a Haswell i7-4790 (described as Intel(R) Core(TM) i7-4790 175 CPU) the relevant values are cpu family 6, model 60, stepping 3 so in 176 this case the required identification is 06-3c-03. A look at the blobs 206 177 will show that there is one for this CPU (although it might 207 178 have already been applied by the BIOS). If there is a blob for your … … 213 184 214 185 <para>Now that the Intel microcode has been prepared, use the following 215 options when you configure the kernel to try late loading of theIntel186 options when you configure the kernel to load Intel 216 187 microcode:</para> 217 188 218 <screen><literal>Processor type and features ---> 219 <M> CPU microcode loading support [CONFIG_MICROCODE] 220 [*] Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen> 221 222 <para>After you have successfully booted the new system, use the command 223 <userinput>dmesg | grep microcode</userinput> and study the results to 224 see if the message new patch_level appears. This example from the 225 SandyBridge i3:</para> 226 227 <screen><literal>[ 0.059906] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode 228 [ 2.603083] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x23 229 [ 2.669378] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x23 230 [ 2.669994] microcode: CPU0 updated to revision 0x29, date = 2013-06-12 231 [ 2.670069] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x23 232 [ 2.670139] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x23 233 [ 2.670501] microcode: CPU1 updated to revision 0x29, date = 2013-06-12 234 [ 2.670509] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x23 235 [ 2.670540] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x23 236 [ 2.670917] microcode: CPU2 updated to revision 0x29, date = 2013-06-12 237 [ 2.670955] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x23 238 [ 2.670988] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x23 239 [ 2.671348] microcode: CPU3 updated to revision 0x29, date = 2013-06-12 240 [ 2.671356] perf_event_intel: PEBS enabled due to microcode update 241 [ 2.671412] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba</literal></screen> 189 <screen><literal>General Setup ---> 190 [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD] 191 Processor type and features ---> 192 [y] CPU microcode loading support [CONFIG_MICROCODE] 193 [y] Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen> 194 195 <para>After you have successfully booted the new system, force late loading by 196 using the command:</para> 197 198 <screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen> 199 200 <para>Then use the following command to see if anything was loaded:</para> 201 202 <screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen> 203 204 <para>This example from the Haswell i7 which was released in Q2 2014 and is 205 not affected by the TSX errate shows it has been updated from revision 0x19 206 in the BIOS/UEFI to revision 0x20. Unlike in older kernels, the individual 207 CPUs are not separately reported:</para> 208 209 <screen><literal>[ 0.000000] Linux version 4.9.12 (ken@plexi) (gcc version 6.3.0 (GCC) ) 210 #3 SMP PREEMPT Mon Mar 6 03:29:27 GMT 2017 211 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.9.12-sda8 root=/dev/sda8 ro 212 [ 0.913685] microcode: sig=0x306c3, pf=0x2, revision=0x19 213 [ 0.913905] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba 214 [ 148.723932] microcode: updated to revision 0x20, date = 2016-03-16</literal></screen> 242 215 243 216 <para>If the microcode was not updated, there is no new microcode for … … 261 234 cp -v microcode_amd* /lib/firmware/amd-ucode</userinput></screen> 262 235 263 <para>When you configure the kernel, use the following options to try 264 late loading of AMD microcode:</para> 265 266 <screen><literal>Processor type and features ---> 267 <M> CPU microcode loading support [CONFIG_MICROCODE] 268 [*] AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen> 269 270 <para>After you have successfully booted the new system, use the command 271 <userinput>dmesg | grep microcode</userinput> and study the results to see 272 if the message new patch_level appears, as in this example from an old 273 Athlon(tm) II X2:</para> 274 275 <screen><literal>[ 4.183907] microcode: CPU0: patch_level=0x010000b6 276 [ 4.184271] microcode: CPU0: new patch_level=0x010000c8 277 [ 4.184278] microcode: CPU1: patch_level=0x010000b6 278 [ 4.184283] microcode: CPU1: new patch_level=0x010000c8 279 [ 4.184359] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba</literal></screen> 236 <para>When you configure the kernel, use the following options when you 237 configure the kernel to load AMD microcode:</para> 238 239 <screen><literal>General Setup ---> 240 [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD] 241 Processor type and features ---> 242 [y] CPU microcode loading support [CONFIG_MICROCODE] 243 [y] AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen> 244 245 <para>After you have successfully booted the new system, force late loading by 246 using the command:</para> 247 248 <screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen> 249 250 <para>Then use the following command to see if anything was loaded:</para> 251 252 <screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen> 253 <para>This example from an old Athlon(tm) II X2 shows it has been updated. 254 For the moment, all CPUs are still reported in the microcode details on AMD 255 machines:</para> 256 257 <screen><literal>[ 0.000000] Linux version 4.9.8 (ken@testserver) (gcc version 6.3.0 (GCC) ) 258 #1 SMP Mon Mar 6 22:27:18 GMT 2017 259 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.9.8-sdc6 root=/dev/sdc6 ro 260 [ 0.907752] microcode: CPU0: patch_level=0x010000b6 261 [ 0.907788] microcode: CPU1: patch_level=0x010000b6 262 [ 0.907844] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba 263 [ 121.952667] microcode: CPU0: new patch_level=0x010000c8 264 [ 121.952687] microcode: CPU1: new patch_level=0x010000c8</literal></screen> 280 265 281 266 <para>If the microcode was not updated, there is no new microcode for … … 290 275 <para>If you have established that updated microcode is available for 291 276 your system, it is time to prepare it for early loading. This requires 292 an additional package, <xref linkend='cpio'/>, as well as changes to 293 the kernel config and the creation of an initrd which will need to be 294 added to grub.cfg.</para> 277 an additional package, <xref linkend='cpio'/> and the creation of an 278 initrd which will need to be added to grub.cfg.</para> 295 279 296 280 <para>It does not matter where you prepare the initrd, and once it is … … 316 300 <screen><userinput>find . | cpio -o -H newc > /boot/microcode.img</userinput></screen> 317 301 318 <para>You will now need to reconfigure and rebuild your kernel. It is 319 safer to either add/change the EXTRAVERSION in the kernel's configuration 320 and install the newer kernel with a new name, or else (unless you have a 321 machine which requires an early firmware update) wait for the next 322 SUBLEVEL kernel release so that you can fall back to the existing kernel 323 in the event that something goes wrong.</para> 324 325 <para>You will also need to add a new entry to /boot/grub/grub.cfg and 302 <para>You now need to add a new entry to /boot/grub/grub.cfg and 326 303 here you should add a new line after the linux line within the stanza. 327 304 If /boot is a separate mountpoint: </para> … … 333 310 <screen><userinput>initrd /boot/microcode.img</userinput></screen> 334 311 335 <para>You must also change the kernel config:</para> 336 337 <screen><literal>General Setup ---> 338 [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD] 339 [y] CPU microcode loading support [CONFIG_MICROCODE]</literal></screen> 340 341 <para>Retain the setting for INTEL or AMD microcode. When you have saved 342 the .config file, either CONFIG_MICROCODE_INTEL_EARLY=y or 343 CONFIG_MICROCODE_AMD_EARLY=y should be set, together with 344 CONFIG_MICROCODE_EARLY=y.</para> 345 346 <para>When you have installed and booted this kernel, you should check 347 the output of dmesg to confirm that the early load worked. The places and 348 times where this happens are very different in AMD and Intel machines. 349 First, an Intel example where a development kernel is being tested, 350 showing that the first notification comes before the kernel version is 351 mentioned:</para> 352 353 <screen><literal>[ 0.000000] CPU0 microcode updated early to revision 0x29, date = 2013-06-12 354 [ 0.000000] Linux version 4.0.0-rc6 (ken@jtm1) (gcc version 4.9.2 (GCC) ) 355 #3 SMP PREEMPT Mon Mar 30 21:26:02 BST 2015 356 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.0.0-rc6-sda13 root=/dev/sda13 ro 357 ... 358 [ 0.103091] CPU1 microcode updated early to revision 0x29, date = 2013-06-12 359 [ 0.113241] #2 360 [ 0.134631] #3 361 [ 0.147821] x86: Booted up 1 node, 4 CPUs 362 [ 0.147936] smpboot: Total of 4 processors activated (26338.66 BogoMIPS) 363 ... 364 [ 0.272643] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x29 365 [ 0.272709] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x29 366 [ 0.272775] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x29 367 [ 0.272842] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x29 368 [ 0.272941] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba</literal></screen> 369 370 <para>A second AMD example is where the machine was running a stable 371 kernel on an older version of LFS. Note that here there is no mention of 372 the previous microcode version — compare this output to the AMD 373 late loading messages (above) from the same machine:</para> 374 375 <screen><literal>[ 0.000000] Linux version 3.18.11 (ken@milliways) (gcc version 4.9.1 (GCC) ) 376 #4 SMP Thu Apr 9 21:51:05 BST 2015 377 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.18.11-sda5 root=/dev/sda5 video=800x600 ro 378 ... 379 [ 0.584009] Trying to unpack rootfs image as initramfs... 380 [ 0.584092] microcode: updated early to new patch_level=0x010000c8 381 ... 382 [ 0.586733] microcode: CPU0: patch_level=0x010000c8 383 [ 0.586778] microcode: CPU1: patch_level=0x010000c8 384 [ 0.586866] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba</literal></screen> 312 <para>You can now reboot with the added initrd, and then use the same 313 command to check that the early load worked.</para> 314 315 <screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen> 316 317 <para>The places and times where early loading happens are very different 318 in AMD and Intel machines. First, an Intel example from an updated stable 319 kernel, showing that the first notification comes before the kernel version 320 is mentioned:</para> 321 322 <screen><literal>[ 0.000000] microcode: microcode updated early to revision 0x20, date = 2016-03-16 323 [ 0.000000] Linux version 4.9.14 (ken@plexi) (gcc version 6.3.0 (GCC) ) 324 #6 SMP PREEMPT Mon Mar 13 16:19:11 GMT 2017 325 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.9.14-sda8 root=/dev/sda8 ro 326 [ 0.920217] microcode: sig=0x306c3, pf=0x2, revision=0x20 327 [ 0.920514] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba</literal></screen> 328 329 <para>An AMD example for the same kernel version:</para> 330 331 <screen><literal>[ 0.000000] Linux version 4.9.14 (ken@testserver) (gcc version 6.3.0 (GCC) ) 332 #2 SMP Mon Mar 13 22:23:44 GMT 2017 333 [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.9.14-sdc6 root=/dev/sdc6 ro 334 [ 0.907648] microcode: microcode updated early to new patch_level=0x010000c8 335 [ 0.907690] microcode: CPU0: patch_level=0x010000c8 336 [ 0.907733] microcode: CPU1: patch_level=0x010000c8 337 [ 0.907808] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba</literal></screen> 385 338 386 339 </sect3>
Note:
See TracChangeset
for help on using the changeset viewer.