- 06/23/2020 06:39:31 PM (15 months ago)
- 10.0, 10.1, 11.0, qt5new, trunk, xry111/git-date, xry111/git-date-for-trunk, xry111/git-date-test
- 1 edited
rdc96204 r3179c69 69 69 <listitem> 70 70 <para> 71 Firmware for video controllers. On x86 machines this seems to mostly 72 apply to ATI devices (Radeon and AMDGPU chips) and Nvidia Maxwell 73 and Pascal cards which all require firmware to be able to use KMS 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 74 78 (kernel modesetting - the preferred option) as well as for Xorg. For 75 earlier radeon chips (before the R600), the firmware is still in the 76 kernel. 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 93 url="https://wiki.archlinux.org/index.php/intel_graphics/">Arch 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. 77 105 </para> 78 106 </listitem> … … 178 206 The first step is to get the most recent version of the Intel 179 207 microcode. This must be done by navigating to <ulink url= 180 208 'https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/'/> 181 209 and downloading the latest file there. As of this writing the most 182 recent version of the microcode is microcode-20200609. Extract this 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 183 213 file in the normal way, the microcode is in the <filename>intel-ucode 184 214 </filename> directory, containing various blobs with names in the form … … 383 413 <caution> 384 414 <para> 385 On some Skylake machines with hex Model Number '4e' (78 decimal) the upgrade to 386 microcode version '0xdc' is reported to cause the machine to hang in early boot, 387 and the fix is to revert to version 0xd6 which was shipped in the 20191115 388 microcode release. 415 On some Skylake machines with hex Model Number '4e' (78 decimal) the 416 417 418 microcode release. 389 419 </para> 390 420 391 421 <para> 392 Doing that, while making the machine usable, will mean that the SRBDS 393 mitigations are not present. 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. 394 426 </para> 395 427 396 428 <para> 397 The Skylake machines with hex Model Number '5e' (94 decimal) use similar 398 firmware versions, but boot correctly with the mitigation applied. 429 430 . 399 431 </para> 400 432 </caution>
Note: See TracChangeset for help on using the changeset viewer.