Ignore:
Timestamp:
03/25/2020 03:07:11 PM (4 years ago)
Author:
Pierre Labastie <pieere@…>
Branches:
10.0, 10.1, 11.0, 11.1, 11.2, 11.3, 12.0, 12.1, kea, ken/TL2024, ken/inkscape-core-mods, ken/tuningfonts, lazarus, lxqt, 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:
986f53b9
Parents:
fa3edfef
Message:

Format postlfs config

git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@22886 af4574ff-66df-0310-9fd7-8a98e5e911e0

File:
1 edited

Legend:

Unmodified
Added
Removed

  • postlfs/config/firmware.xml

    rfa3edfef r81a73ed8  
    2020  </indexterm>
    2121
    22   <para> 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.</para>
    26 
    27   <para>Preparing firmware for multiple different machines, as a distro would
    28   do, is outside the scope of this book.</para>
    29 
    30   <para>Currently, most firmware can be found at a <userinput>git</userinput>
    31   repository: <ulink
    32   url="http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/"/>.
    33   For convenience, the LFS Project has created a mirror, updated daily, where
    34   these firmware files can be accessed via <userinput>wget</userinput> or a web
    35   browser at <ulink
    36   url="&sources-anduin-http;/linux-firmware/"/>.</para>
    37 
    38   <para>To get the firmware, either point a browser to one of the above
    39   repositories and then download the item(s) which you need, or install
    40   <userinput>git</userinput> and clone that repository.</para>
    41 
    42   <para>For some other firmware, particularly for Intel microcode and certain
    43   wifi devices, the needed firmware is not available in the above repository.
    44   Some of this will be addressed below, but a search of the Internet for needed
    45   firmware is sometimes necessary.</para>
    46 
    47   <para>Firmware files are conventionally referred to as blobs because you cannot
    48   determine what they will do. Note that firmware is distributed under various
    49   different licenses which do not permit disassembly or reverse-engineering.</para>
    50 
    51   <para>Firmware for PCs falls into four categories:</para>
     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    Preparing firmware for multiple different machines, as a distro would
     31    do, is outside the scope of this book.
     32  </para>
     33
     34  <para>
     35    Currently, most firmware can be found at a <userinput>git</userinput>
     36    repository: <ulink url=
     37      "http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/"/>.
     38    For convenience, the LFS Project has created a mirror, updated daily, where
     39    these firmware files can be accessed via <userinput>wget</userinput> or a
     40    web browser at <ulink url="&sources-anduin-http;/linux-firmware/"/>.
     41  </para>
     42
     43  <para>
     44    To get the firmware, either point a browser to one of the above
     45    repositories and then download the item(s) which you need, or install
     46    <xref linkend="git"/> and clone that repository.
     47  </para>
     48
     49  <para>
     50    For some other firmware, particularly for Intel microcode and certain
     51    wifi devices, the needed firmware is not available in the above repository.
     52    Some of this will be addressed below, but a search of the Internet for
     53    needed firmware is sometimes necessary.
     54  </para>
     55
     56  <para>
     57    Firmware files are conventionally referred to as blobs because you cannot
     58    determine what they will do. Note that firmware is distributed under
     59    various different licenses which do not permit disassembly or
     60    reverse-engineering.
     61  </para>
     62
     63  <para>
     64    Firmware for PCs falls into four categories:
     65  </para>
    5266
    5367  <itemizedlist spacing="compact">
    5468    <listitem>
    55       <para>Updates to the CPU to work around errata, usually referred to as
    56        microcode.</para>
     69      <para>
     70        Updates to the CPU to work around errata, usually referred to as
     71        microcode.
     72      </para>
    5773    </listitem>
    5874    <listitem>
    59       <para>Firmware for video controllers. On x86 machines this seems to mostly
    60       apply to ATI devices (Radeon and AMDGPU chips) and Nvidia
    61       Maxwell and Pascal cards which all require firmware to be able to use KMS
    62       (kernel modesetting - the preferred option) as well as for Xorg. For
    63       earlier radeon chips (before the R600), the firmware is still in the
    64       kernel.</para>
     75      <para>
     76        Firmware for video controllers. On x86 machines this seems to mostly
     77        apply to ATI devices (Radeon and AMDGPU chips) and Nvidia Maxwell
     78        and Pascal cards which all require firmware to be able to use KMS
     79        (kernel modesetting - the preferred option) as well as for Xorg. For
     80        earlier radeon chips (before the R600), the firmware is still in the
     81        kernel.
     82      </para>
    6583    </listitem>
    6684    <listitem>
    67       <para>Firmware updates for wired network ports. Mostly they work even
    68       without the updates, but probably they will work better with
    69       the updated firmware. For some modern laptops, firmware for both
    70       wired ethernet (e.g. rtl_nic) and also for bluetooth devices (e.g. qca)
    71       is <emphasis>required</emphasis> before the wired network can be used.
     85      <para>
     86        Firmware updates for wired network ports. Mostly they work even
     87        without the updates, but probably they will work better with
     88        the updated firmware. For some modern laptops, firmware for both
     89        wired ethernet (e.g. rtl_nic) and also for bluetooth devices (e.g. qca)
     90        is <emphasis>required</emphasis> before the wired network can be used.
    7291      </para>
    7392    </listitem>
    7493    <listitem>
    75       <para>Firmware for other devices, such as wifi. These devices are not
    76       required for the PC to boot, but need the firmware before these devices
    77       can be used.</para>
     94      <para>
     95        Firmware for other devices, such as wifi. These devices are not
     96        required for the PC to boot, but need the firmware before these devices
     97        can be used.
     98      </para>
    7899    </listitem>
    79100  </itemizedlist>
    80101
    81   <note><para>Although not needed to load a firmware blob, the following
    82   tools may be useful for determining, obtaining, or preparing the needed
    83   firmware in order to load it into the system:
    84     <xref linkend="cpio"/>,
    85     <xref linkend="git"/>,
    86     <xref linkend="pciutils"/>, and
    87     <xref linkend="wget"/></para></note>
     102  <note>
     103    <para>
     104      Although not needed to load a firmware blob, the following
     105      tools may be useful for determining, obtaining, or preparing the needed
     106      firmware in order to load it into the system:
     107      <xref linkend="cpio"/>,
     108      <xref linkend="git"/>,
     109      <xref linkend="pciutils"/>, and
     110      <xref linkend="wget"/>
     111    </para>
     112  </note>
    88113
    89114  <para condition="html" role="usernotes">User Notes:
    … …  
    93118    <title>Microcode updates for CPUs</title>
    94119
    95     <para>In general, microcode can be loaded by the BIOS or UEFI, and it might
    96     be updated by upgrading to a newer version of those. On linux, you can also
    97     load the microcode from the kernel if you are using an AMD family 10h or
    98     later processor (first introduced late 2007), or an Intel processor from
    99     1998 and later (Pentium4, Core, etc), if updated microcode has been
    100     released. These updates only last until the machine is powered off, so they
    101     need to be applied on every boot.</para>
    102 
    103     <para>Intel provide updates of their microcode for SandyBridge and later
    104     processors as new vulnerabilities come to light. New versions of AMD
    105     firmware are rare and usually only apply to a few models, although
    106     motherboard manufacturers get extra updates which maybe update microcode
    107     along with the changes to support newer CPUs and faster memory.</para>
    108 
    109     <para>There are two ways of loading the microcode, described as 'early'
    110     and 'late'. Early loading happens before userspace has been started, late
    111     loading happens after userspace has started. Not surprisingly, early loading
    112     is preferred, (see e.g. an explanatory comment in a kernel commit noted at
    113     <ulink url="https://lwn.net/Articles/530346/">x86/microcode: Early load
    114     microcode </ulink> on LWN.)  Indeed, it is needed to work around one
    115     particular erratum in early Intel Haswell processors which had TSX enabled.
    116     (See <ulink
    117     url="http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwellyi/">
    118     Intel Disables TSX Instructions: Erratum Found in Haswell, Haswell-E/EP,
    119     Broadwell-Y</ulink>.) Without this update glibc can do the wrong thing in
    120     uncommon situations. </para>
    121 
    122     <para>It is still possible to manually force late loading of microcode,
    123     either for testing or to prevent having to reboot. You will need to
    124     reconfigure your kernel for either method. The instructions here will
    125     create a kernel <filename>.config</filename> to suite early loading, before
    126     forcing late loading to see if there is any microcode. If there is, the
    127     instructions then show you how to create an initrd for early loading.</para>
    128 
    129     <para>To confirm what processor(s) you have (if more than one, they will be
    130     identical) look in /proc/cpuinfo.</para>
     120    <para>
     121      In general, microcode can be loaded by the BIOS or UEFI, and it might be
     122      updated by upgrading to a newer version of those. On linux, you can also
     123      load the microcode from the kernel if you are using an AMD family 10h or
     124      later processor (first introduced late 2007), or an Intel processor from
     125      1998 and later (Pentium4, Core, etc), if updated microcode has been
     126      released. These updates only last until the machine is powered off, so
     127      they need to be applied on every boot.
     128    </para>
     129
     130    <para>
     131      Intel provide updates of their microcode for SandyBridge and later
     132      processors as new vulnerabilities come to light. New versions of AMD
     133      firmware are rare and usually only apply to a few models, although
     134      motherboard manufacturers get extra updates which maybe update microcode
     135      along with the changes to support newer CPUs and faster memory.
     136    </para>
     137
     138    <para>
     139      There are two ways of loading the microcode, described as 'early' and
     140      'late'. Early loading happens before userspace has been started, late
     141      loading happens after userspace has started. Not surprisingly, early
     142      loading is preferred, (see e.g. an explanatory comment in a kernel
     143      commit noted at <ulink url="https://lwn.net/Articles/530346/">
     144        x86/microcode: Early load microcode</ulink> on LWN.)  Indeed, it
     145      is needed to work around one particular erratum in early Intel Haswell
     146      processors which had TSX enabled.  (See <ulink url=
     147      "http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwellyi/">
     148        Intel Disables TSX Instructions: Erratum Found in Haswell,
     149        Haswell-E/EP, Broadwell-Y
     150      </ulink>.) Without this update glibc can do the wrong thing in uncommon
     151      situations.
     152    </para>
     153
     154    <para>
     155      It is still possible to manually force late loading of microcode, either
     156      for testing or to prevent having to reboot. You will need to reconfigure
     157      your kernel for either method. The instructions here will create a
     158      kernel <filename>.config</filename> to suite early loading, before
     159      forcing late loading to see if there is any microcode. If there is,
     160      the instructions then show you how to create an initrd for early loading.
     161    </para>
     162
     163    <para>
     164      To confirm what processor(s) you have (if more than one, they will be
     165      identical) look in /proc/cpuinfo.
     166    </para>
    131167
    132168    <sect3 id="intel-microcode">
    133169      <title>Intel Microcode for the CPU</title>
    134170
    135      <para>The first step is to get the most recent version of the Intel
    136      microcode.  This must be done by navigating to <ulink
    137      url='https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/'/>
    138      and downloading the latest file there.  As of this writing the most recent
    139      version of the microcode is microcode-20191115.
    140      Extract this file in the normal way, the microcode is in the <filename>intel-ucode</filename>
    141      directory, containing various blobs with names in the form XX-YY-ZZ.
    142      There are also various other files, and a releasenote.</para>
    143 
    144      <para>In the past, intel did not provide any details of which blobs had
    145      changed versions, but now the release note details this.</para>
    146 
    147      <para>The recent firmware for older processors is provided to deal with
    148      vulnerabilities which have now been made public, and for some of these such
    149      as Microarchitectural Data Sampling (MDS) you might wish to increase the
    150      protection by disabling hyperthreading, or alternatively to disable the
    151      kernel's default mitigation because of its impact on compile times. Please
    152      read the online documentation at <ulink
    153      url='https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html'/>.
    154      </para>
    155 
    156      <para>To be able to use this latest microcode to provide mitigation on all
    157      the affected processors, the kernel version needs to be at least 5.3.11 (or
    158      4.19.84 if you are using the 4.19 long term support series).</para>
    159 
    160      <para>Now you need to determine your processor's identity to see if there
    161      is any microcode for it. Determine the decimal values of the cpu family,
    162      model and stepping by running the following command (it will also report
    163      the current microcode version):</para>
     171      <para>
     172        The first step is to get the most recent version of the Intel
     173        microcode.  This must be done by navigating to <ulink url=
     174         'https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/'/>
     175        and downloading the latest file there.  As of this writing the most
     176        recent version of the microcode is microcode-20191115.  Extract this
     177        file in the normal way, the microcode is in the <filename>intel-ucode
     178        </filename> directory, containing various blobs with names in the form
     179        XX-YY-ZZ. There are also various other files, and a releasenote.
     180      </para>
     181
     182      <para>
     183        In the past, intel did not provide any details of which blobs had
     184        changed versions, but now the release note details this.
     185      </para>
     186
     187      <para>
     188        The recent firmware for older processors is provided to deal with
     189        vulnerabilities which have now been made public, and for some of these
     190        such as Microarchitectural Data Sampling (MDS) you might wish to
     191        increase the protection by disabling hyperthreading, or alternatively
     192        to disable the kernel's default mitigation because of its impact on
     193        compile times. Please read the online documentation at <ulink url=
     194        'https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html'/>.
     195      </para>
     196
     197      <para>
     198        To be able to use this latest microcode to provide mitigation on all
     199        the affected processors, the kernel version needs to be at least 5.3.11
     200        (or 4.19.84 if you are using the 4.19 long term support series).
     201      </para>
     202
     203      <para>
     204        Now you need to determine your processor's identity to see if there
     205        is any microcode for it. Determine the decimal values of the cpu family,
     206        model and stepping by running the following command (it will also report
     207        the current microcode version):
     208      </para>
    164209
    165210<screen><userinput>head -n7 /proc/cpuinfo</userinput></screen>
    166211
    167       <para>Convert the cpu family, model and stepping to pairs of hexadecimal
    168       digits. For a Skylake i3 6100 (described as Intel(R) Core(TM) i3-6100
    169       CPU) the relevant values are cpu family 6, model 94, stepping 3 so in
    170       this case the required identification is 06-5e-03. A look at the blobs
    171       will show that there is one for this CPU (although for older issues it
    172       might have already been applied by the BIOS). If there is a blob for your
    173       system then test if it will be applied by copying it (replace &lt;XX-YY-ZZ&gt;
    174       by the identifier for your machine) to where the kernel can find it:</para>
     212      <para>
     213        Convert the cpu family, model and stepping to pairs of hexadecimal
     214        digits. For a Skylake i3 6100 (described as Intel(R) Core(TM) i3-6100
     215        CPU) the relevant values are cpu family 6, model 94, stepping 3 so in
     216        this case the required identification is 06-5e-03. A look at the blobs
     217        will show that there is one for this CPU (although for older issues it
     218        might have already been applied by the BIOS). If there is a blob for
     219        your system then test if it will be applied by copying it (replace
     220        &lt;XX-YY-ZZ&gt; by the identifier for your CPU) to where the
     221        kernel can find it:
     222      </para>
    175223
    176224<screen><userinput>mkdir -pv /lib/firmware/intel-ucode
    177225cp -v intel-ucode/&lt;XX-YY-ZZ&gt; /lib/firmware/intel-ucode</userinput></screen>
    178226
    179       <para>Now that the Intel microcode has been prepared, use the following
    180       options when you configure the kernel to load Intel
    181       microcode:</para>
     227      <para>
     228        Now that the Intel microcode has been prepared, use the following
     229        options when you configure the kernel to load Intel microcode:
     230      </para>
    182231
    183232<screen><literal>General Setup ---&gt;
    … …  
    187236  [y]      Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen>
    188237
    189       <para>After you have successfully booted the new system, force late loading by
    190       using the command:</para>
     238      <para>
     239        After you have successfully booted the new system, force late loading
     240        by using the command:
     241      </para>
    191242
    192243<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
    193244
    194       <para>Then use the following command to see if anything was loaded:</para>
     245      <para>
     246        Then use the following command to see if anything was loaded:
     247      </para>
    195248
    196249<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
    197250
    198       <para>This reformatted example was created by temporarily booting without
    199       microcode, to show the current Firmware Bug message, then the late load
    200       shows it being updated to revision 0xd6.</para>
     251      <para>
     252        This reformatted example was created by temporarily booting without
     253        microcode, to show the current Firmware Bug message, then the late load
     254        shows it being updated to revision 0xd6.
     255      </para>
    201256
    202257<screen><literal>[    0.000000] Linux version 5.4.2 (lfs@leshp) (gcc version 9.2.0 (GCC))
    … …  
    211266[  277.674231] x86/CPU: CPU features have changed after loading microcode, but might not take effect</literal></screen>
    212267
    213     <para>If the microcode was not updated, there is no new microcode for
    214     this system's processor. If it did get updated, you can now proceed to <xref
    215     linkend='early-microcode'/>.</para>
     268      <para>
     269        If the microcode was not updated, there is no new microcode for this
     270        system's processor. If it did get updated, you can now proceed to
     271        <xref linkend='early-microcode'/>.
     272      </para>
    216273
    217274    </sect3>
    … …  
    220277      <title>AMD Microcode for the CPU</title>
    221278
    222       <para>Begin by downloading a container of firmware for your CPU family
    223       from <ulink
    224       url='&sources-anduin-http;/linux-firmware/amd-ucode/'/>.
    225       The family is always specified in hex. Families 10h to 14h (16 to 20)
    226       are in microcode_amd.bin.  Families 15h, 16h and 17h have their own containers.
    227       Create the required directory and put the firmware you downloaded into
    228       it as the <systemitem class="username">root</systemitem> user:</para>
     279      <para>
     280        Begin by downloading a container of firmware for your CPU family
     281        from <ulink url=
     282          '&sources-anduin-http;/linux-firmware/amd-ucode/'/>.
     283        The family is always specified in hex. Families 10h to 14h (16 to 20)
     284        are in microcode_amd.bin.  Families 15h, 16h and 17h have their own
     285        containers.  Create the required directory and put the firmware you
     286        downloaded into it as the <systemitem
     287        class="username">root</systemitem> user:
     288      </para>
    229289
    230290<screen><userinput>mkdir -pv /lib/firmware/amd-ucode
    231291cp -v microcode_amd* /lib/firmware/amd-ucode</userinput></screen>
    232292
    233       <para>When you configure the kernel, use the following options
    234       to load AMD microcode:</para>
     293      <para>
     294        When you configure the kernel, use the following options
     295        to load AMD microcode:
     296      </para>
    235297
    236298<screen><literal>General Setup ---&gt;
    … …  
    240302  [y]      AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen>
    241303
    242       <para>After you have successfully booted the new system, force late loading by
    243       using the command:</para>
     304      <para>
     305        After you have successfully booted the new system, force late loading
     306        by using the command:
     307      </para>
    244308
    245309<screen><userinput>echo 1 > /sys/devices/system/cpu/microcode/reload</userinput></screen>
    246310
    247       <para>Then use the following command to see if anything was loaded:</para>
     311      <para>
     312        Then use the following command to see if anything was loaded:
     313      </para>
    248314
    249315<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
    250       <para>This historic example from an old Athlon(tm) II X2 shows it has been
    251       updated. At that time, all CPUs were still reported in the microcode details on
    252       AMD machines (the current position for AMD machines where newer microcode is
    253       available is unknown) :</para>
     316      <para>
     317        This historic example from an old Athlon(tm) II X2 shows it has been
     318        updated. At that time, all CPUs were still reported in the microcode
     319        details on AMD machines (the current position for AMD machines where
     320        newer microcode is available is unknown) :
     321      </para>
    254322
    255323<screen><literal>[    0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
    … …  
    262330[  187.928899] microcode: CPU1: new patch_level=0x010000c8</literal></screen>
    263331
    264     <para>If the microcode was not updated, there is no new microcode for
    265     this system's processor. If it did get updated, you can now proceed to <xref
    266     linkend='early-microcode'/>.</para>
     332      <para>
     333        If the microcode was not updated, there is no new microcode for
     334        this system's processor. If it did get updated, you can now proceed to
     335        <xref linkend='early-microcode'/>.
     336      </para>
    267337
    268338    </sect3>
    … …  
    271341      <title>Early loading of microcode</title>
    272342
    273       <para>If you have established that updated microcode is available for
    274       your system, it is time to prepare it for early loading. This requires
    275       an additional package, <xref linkend='cpio'/> and the creation of an
    276       initrd which will need to be added to grub.cfg.</para>
    277 
    278       <para>It does not matter where you prepare the initrd, and once it is
    279       working you can apply the same initrd to later LFS systems or newer
    280       kernels on this same machine, at least until any newer microcode is
    281       released. Use the following commands:</para>
     343      <para>
     344        If you have established that updated microcode is available for
     345        your system, it is time to prepare it for early loading. This requires
     346        an additional package, <xref linkend='cpio'/> and the creation of an
     347        initrd which will need to be added to grub.cfg.
     348      </para>
     349
     350      <para>
     351        It does not matter where you prepare the initrd, and once it is
     352        working you can apply the same initrd to later LFS systems or newer
     353        kernels on this same machine, at least until any newer microcode is
     354        released. Use the following commands:
     355      </para>
    282356
    283357<screen><userinput>mkdir -p initrd/kernel/x86/microcode
    284358cd initrd</userinput></screen>
    285359
    286       <para>For an AMD machine, use the following command (replace
    287       &lt;MYCONTAINER&gt; with the name of the container for your CPU's
    288       family):</para>
     360      <para>
     361        For an AMD machine, use the following command (replace
     362        &lt;MYCONTAINER&gt; with the name of the container for your CPU's
     363        family):
     364      </para>
    289365
    290366<screen><userinput>cp -v /lib/firmware/amd-ucode/&lt;MYCONTAINER&gt; kernel/x86/microcode/AuthenticAMD.bin</userinput></screen>
    291367
    292       <para>Or for an Intel machine copy the appropriate blob using this command:</para>
     368      <para>
     369        Or for an Intel machine copy the appropriate blob using this command:
     370      </para>
    293371
    294372<screen><userinput>cp -v /lib/firmware/intel-ucode/&lt;XX-YY-ZZ&gt; kernel/x86/microcode/GenuineIntel.bin</userinput></screen>
    295373
    296       <para>Now prepare the initrd:</para>
     374      <para>
     375        Now prepare the initrd:
     376      </para>
    297377
    298378<screen><userinput>find . | cpio -o -H newc &gt; /boot/microcode.img</userinput></screen>
    299379
    300       <para>You now need to add a new entry to /boot/grub/grub.cfg and
    301       here you should add a new line after the linux line within the stanza.
    302       If /boot is a separate mountpoint: </para>
     380      <para>
     381        You now need to add a new entry to /boot/grub/grub.cfg and
     382        here you should add a new line after the linux line within the stanza.
     383        If /boot is a separate mountpoint:
     384       </para>
    303385
    304386<screen><userinput>initrd /microcode.img</userinput></screen>
    305387
    306       <para>or this if it is not:</para>
     388      <para>
     389        or this if it is not:
     390      </para>
    307391
    308392<screen><userinput>initrd /boot/microcode.img</userinput></screen>
    309393
    310       <para>If you are already booting with an initrd (see <xref
    311       linkend="initramfs"/>), you should run <command>mkinitramfs</command>
    312       again after putting the appropriate blob or container into <filename
    313       class="directory">/lib/firmware</filename> as explained above.
    314       Alternatively, you can have both initrd on the same line, such as
    315       <userinput>initrd /microcode.img /other-initrd.img</userinput> (adapt
    316       that as above if /boot is not a separate mountpoint).</para>
    317 
    318       <para>You can now reboot with the added initrd, and then use the same
    319       command to check that the early load worked.</para>
     394      <para>
     395        If you are already booting with an initrd (see <xref
     396        linkend="initramfs"/>), you should run <command>mkinitramfs</command>
     397        again after putting the appropriate blob or container into <filename
     398        class="directory">/lib/firmware</filename> as explained above.
     399        Alternatively, you can have both initrd on the same line, such as
     400        <userinput>initrd /microcode.img /other-initrd.img</userinput> (adapt
     401        that as above if /boot is not a separate mountpoint).
     402      </para>
     403
     404      <para>
     405        You can now reboot with the added initrd, and then use the same
     406        command to check that the early load worked:
     407      </para>
    320408
    321409<screen><userinput>dmesg | grep -e 'microcode' -e 'Linux version' -e 'Command line'</userinput></screen>
    322410
    323       <para>If you updated to address vulnerabilities, you can look at <filename
    324       class="directory">/sys/devices/system/cpu/vulnerabilities/</filename> to
    325       see what is now reported.</para>
    326 
    327       <para>The places and times where early loading happens are very different
    328       in AMD and Intel machines. First, an Intel example with early loading:</para>
     411      <para>
     412        If you updated to address vulnerabilities, you can look at <filename
     413        class="directory">/sys/devices/system/cpu/vulnerabilities/</filename>
     414        to see what is now reported.
     415      </para>
     416
     417      <para>
     418        The places and times where early loading happens are very different
     419        in AMD and Intel machines. First, an Intel example with early loading:
     420      </para>
    329421
    330422<screen><literal>[    0.000000] microcode: microcode updated early to revision 0xd6, date = 2019-10-03
    … …  
    335427[    0.579961] microcode: Microcode Update Driver: v2.2.</literal></screen>
    336428
    337       <para>A historic AMD example:</para>
     429      <para>
     430        A historic AMD example:
     431      </para>
    338432
    339433<screen><literal>[    0.000000] Linux version 4.15.3 (ken@testserver) (gcc version 7.3.0 (GCC))
    … …  
    352446    <title>Firmware for Video Cards</title>
    353447
    354   <sect3 id="ati-video-firmware">
    355     <title>Firmware for ATI video chips (R600 and later)</title>
    356 
    357     <para>These instructions do NOT apply to old radeons before the R600
    358     family. For those, the firmware is in the kernel's <filename
    359     class='directory'>/lib/firmware/</filename> directory. Nor do they apply if
    360     you intend to avoid a graphical setup such as Xorg and are content to use
    361     the default 80x25 display rather than a framebuffer. </para>
    362 
    363     <para> Early radeon devices only needed a single 2K blob of firmware.
    364     Recent devices need several different blobs, and some of them are much
    365     bigger. The total size of the radeon firmware directory is over 500K &mdash; on a
    366     large modern system you can probably spare the space, but it is still
    367     redundant to install all the unused files each time you build a system.</para>
    368 
    369     <para>A better approach is to install <xref linkend='pciutils'/> and then
    370     use <userinput>lspci</userinput> to identify which VGA controller is
    371     installed.</para>
    372 
    373     <para>With that information, check the RadeonFeature page of the Xorg wiki
    374     for <ulink url="http://wiki.x.org/wiki/RadeonFeature/#index5h2">Decoder
    375     ring for engineering vs marketing names</ulink> to identify the family (you
    376     may need to know this for the Xorg driver in BLFS &mdash; Southern Islands and
    377     Sea Islands use the radeonsi driver) and the specific model.</para>
    378 
    379     <para>Now that you know which controller you are using, consult the
    380     <ulink url="https://wiki.gentoo.org/wiki/Radeon#Firmware">Radeon</ulink> page
    381     of the Gentoo wiki which has a table listing the required firmware blobs
    382     for the various chipsets. Note that Southern Islands and Sea Islands chips
    383     use different firmware for kernel 3.17 and later compared to earlier
    384     kernels. Identify and download the required blobs then install them:</para>
     448    <sect3 id="ati-video-firmware">
     449      <title>Firmware for ATI video chips (R600 and later)</title>
     450
     451      <para>
     452        These instructions do NOT apply to old radeons before the R600
     453        family. For those, the firmware is in the kernel's <filename
     454        class='directory'>/lib/firmware/</filename> directory. Nor do they
     455        apply if you intend to avoid a graphical setup such as Xorg and are
     456        content to use the default 80x25 display rather than a framebuffer.
     457      </para>
     458
     459      <para>
     460        Early radeon devices only needed a single 2K blob of firmware. Recent
     461        devices need several different blobs, and some of them are much bigger.
     462        The total size of the radeon firmware directory is over 500K &mdash;
     463        on a large modern system you can probably spare the space, but it is
     464        still redundant to install all the unused files each time you build
     465        a system.
     466      </para>
     467
     468      <para>
     469        A better approach is to install <xref linkend='pciutils'/> and then
     470        use <userinput>lspci</userinput> to identify which VGA controller is
     471        installed.
     472      </para>
     473
     474      <para>
     475        With that information, check the RadeonFeature page of the Xorg wiki
     476        for <ulink url="http://wiki.x.org/wiki/RadeonFeature/#index5h2">Decoder
     477        ring for engineering vs marketing names</ulink> to identify the family
     478        (you may need to know this for the Xorg driver in BLFS &mdash;
     479        Southern Islands and Sea Islands use the radeonsi driver) and the
     480        specific model.
     481      </para>
     482
     483      <para>
     484        Now that you know which controller you are using, consult the
     485        <ulink url="https://wiki.gentoo.org/wiki/Radeon#Firmware">
     486           Radeon</ulink> page of the Gentoo wiki which has a table listing
     487        the required firmware blobs for the various chipsets. Note that
     488        Southern Islands and Sea Islands chips use different firmware for
     489        kernel 3.17 and later compared to earlier kernels. Identify and
     490        download the required blobs then install them:
     491      </para>
    385492
    386493<screen><userinput>mkdir -pv /lib/firmware/radeon
    387494cp -v &lt;YOUR_BLOBS&gt; /lib/firmware/radeon</userinput></screen>
    388495
    389     <para>There are actually two ways of installing this firmware. BLFS, in the
    390     'Kernel Configuration for additional firmware' section part of the <xref
    391     linkend="xorg-ati-driver"/> section  gives an example of compiling the
    392     firmware into the kernel - that is slightly faster to load, but uses more
    393     kernel memory. Here we will use the alternative method of making the radeon
    394     driver a module. In your kernel config set the following: </para>
     496      <para>
     497        There are actually two ways of installing this firmware. BLFS, in the
     498        'Kernel Configuration for additional firmware' section part of the
     499        <xref linkend="xorg-ati-driver"/> section gives an example of
     500        compiling the firmware into the kernel - that is slightly faster to
     501        load, but uses more kernel memory. Here we will use the alternative
     502        method of making the radeon driver a module. In your kernel config
     503        set the following:
     504      </para>
    395505
    396506<screen><literal>Device Drivers ---&gt;
    … …  
    400510      &lt;m&gt; ATI Radeon                                        [CONFIG_DRM_RADEON]</literal></screen>
    401511
    402     <para>Loading several large blobs from /lib/firmware takes a noticeable
    403     time, during which the screen will be blank. If you do not enable the
    404     penguin framebuffer logo, or change the console size by using a bigger
    405     font, that probably does not matter. If desired, you can slightly
    406     reduce the time if you follow the alternate method of specifying 'y' for
    407     CONFIG_DRM_RADEON covered in BLFS at the link above &mdash; you must specify each
    408     needed radeon blob if you do that.</para>
    409 
    410   </sect3>
    411 
    412   <sect3 id="nvidia-video-firmware">
    413     <title>Firmware for Nvidia video chips</title>
    414 
    415     <para>Some Nvidia graphics chips need firmware updates to take advantage
    416     of all the card's capability.  These are generally the GeForce 8, 9, 9300,
    417     and 200-900 series chips.  For more exact information, see <ulink
    418     url="https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware">
    419     https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware</ulink>.</para>
     512      <para>
     513        Loading several large blobs from /lib/firmware takes a noticeable
     514        time, during which the screen will be blank. If you do not enable the
     515        penguin framebuffer logo, or change the console size by using a bigger
     516        font, that probably does not matter. If desired, you can slightly
     517        reduce the time if you follow the alternate method of specifying 'y'
     518        for CONFIG_DRM_RADEON covered in BLFS at the link above &mdash; you
     519        must specify each needed radeon blob if you do that.
     520      </para>
     521
     522    </sect3>
     523
     524    <sect3 id="nvidia-video-firmware">
     525      <title>Firmware for Nvidia video chips</title>
     526
     527      <para>
     528        Some Nvidia graphics chips need firmware updates to take advantage
     529        of all the card's capability.  These are generally the GeForce 8, 9,
     530        9300, and 200-900 series chips.  For more exact information, see
     531        <ulink url=
     532          "https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware"/>.
     533      </para>
    420534   
    421     <para>First, the kernel Nvidia driver must be activated:</para>
     535      <para>
     536        First, the kernel Nvidia driver must be activated:
     537      </para>
    422538
    423539<screen><literal>Device Drivers ---&gt;
    … …  
    427543      &lt;*/m&gt; Nouveau (NVIDIA) cards                          [CONFIG_DRM_NOUVEAU]</literal></screen>
    428544
    429     <para>The steps to install the Nvidia firmware are:</para>
     545      <para>
     546        The steps to install the Nvidia firmware are:
     547      </para>
    430548
    431549<screen><userinput>wget https://raw.github.com/imirkin/re-vp2/master/extract_firmware.py
    … …  
    436554cp -d nv* vuc-* /lib/firmware/nouveau/</userinput></screen>
    437555
    438   </sect3>
     556    </sect3>
    439557  </sect2>
    440558
    … …  
    442560    <title>Firmware for Network Interfaces</title>
    443561
    444     <para>The kernel likes to load firmware for some network drivers,
    445     particularly those from Realtek (the /lib/linux-firmware/rtl_nic/) directory,
    446     but they generally appear to work without it. Therefore, you can boot the
    447     kernel, check dmesg for messages about this missing firmware, and if
    448     necessary download the firmware and put it in the specified directory in
    449     /lib/firmware so that it will be found on subsequent boots. Note that with
    450     current kernels this works whether or not the driver is compiled in or
    451     built as a module, there is no need to build this firmware into the kernel.
    452     Here is an example where the R8169 driver has been compiled in but the
    453     firmware was not made available. Once the firmware had been provided, there
    454     was no mention of it on later boots. </para>
     562    <para>
     563      The kernel likes to load firmware for some network drivers, particularly
     564      those from Realtek (the /lib/linux-firmware/rtl_nic/) directory, but
     565      they generally appear to work without it. Therefore, you can boot the
     566      kernel, check dmesg for messages about this missing firmware, and if
     567      necessary download the firmware and put it in the specified directory in
     568      <filename class="directory">/lib/firmware</filename> so that it will
     569      be found on subsequent boots. Note that with current kernels this
     570      works whether or not the driver is compiled in or built as a module,
     571      there is no need to build this firmware into the kernel.
     572      Here is an example where the R8169 driver has been compiled in but the
     573      firmware was not made available. Once the firmware had been provided,
     574      there was no mention of it on later boots.
     575    </para>
    455576
    456577<screen><literal>dmesg | grep firmware | grep r8169
    … …  
    463584    <title>Firmware for Other Devices</title>
    464585
    465     <para> Identifying the correct firmware will typically require you to
    466     install <xref linkend='pciutils'/>, and then use
    467     <userinput>lspci</userinput> to identify the device. You should then search
    468     online to check which module it uses, which firmware, and where to obtain
    469     the firmware &mdash; not all of it is in linux-firmware.</para>
    470 
    471     <para>If possible, you should begin by using a wired connection when you
    472     first boot your LFS system. To use a wireless connection you will need to
    473     use a network tools such as <xref linkend='wireless_tools'/> and <xref
    474     linkend='wpa_supplicant'/>.</para>
    475 
    476     <para>Firmware may also be needed for other devices such as some SCSI
    477     controllers, bluetooth adaptors, or TV recorders. The same principles
    478     apply.</para>
     586    <para>
     587      Identifying the correct firmware will typically require you to install
     588      <xref linkend='pciutils'/>, and then use <userinput>lspci</userinput>
     589      to identify the device. You should then search online to check which
     590      module it uses, which firmware, and where to obtain the firmware &mdash;
     591      not all of it is in linux-firmware.
     592    </para>
     593
     594    <para>
     595      If possible, you should begin by using a wired connection when you first
     596      boot your LFS system. To use a wireless connection you will need to
     597      use a network tools such as <xref linkend='wireless_tools'/> and <xref
     598      linkend='wpa_supplicant'/>.
     599    </para>
     600
     601    <para>
     602      Firmware may also be needed for other devices such as some SCSI
     603      controllers, bluetooth adaptors, or TV recorders. The same principles
     604      apply.
     605    </para>
    479606
    480607  </sect2>
Note: See TracChangeset for help on using the changeset viewer.