Index: general.ent
===================================================================
--- general.ent	(revision f78981d909d471143e5ec43faaacc499045d3cb6)
+++ general.ent	(revision 3ae81e13dd90ba72bc7d6991f8ebd9d65bff1f65)
@@ -1,5 +1,5 @@
 <!-- $LastChangedBy$ $Date$ -->
 
-<!ENTITY day          "17">                   <!-- Always 2 digits -->
+<!ENTITY day          "18">                   <!-- Always 2 digits -->
 <!ENTITY month        "04">                   <!-- Always 2 digits -->
 <!ENTITY year         "2015">
@@ -7,5 +7,5 @@
 <!ENTITY copyholder   "The BLFS Development Team">
 <!ENTITY version      "&year;-&month;-&day;">
-<!ENTITY releasedate  "April 17th, &year;">
+<!ENTITY releasedate  "April 18th, &year;">
 <!ENTITY pubdate      "&year;-&month;-&day;"> <!-- metadata req. by TLDP -->
 <!ENTITY blfs-version "svn">                  <!-- svn|[release #] -->
Index: introduction/welcome/changelog.xml
===================================================================
--- introduction/welcome/changelog.xml	(revision f78981d909d471143e5ec43faaacc499045d3cb6)
+++ introduction/welcome/changelog.xml	(revision 3ae81e13dd90ba72bc7d6991f8ebd9d65bff1f65)
@@ -45,4 +45,15 @@
 -->
     <listitem>
+      <para>April 18th, 2015</para>
+      <itemizedlist>
+        <listitem>
+          <para>[bdubbs] - Add a section on installing firmware.
+          Most of the update was done by Ken. Partially addresses 
+          <ulink url="&blfs-ticket-root;6364">#6364</ulink>.</para>
+        </listitem>
+      </itemizedlist>
+    </listitem>
+
+    <listitem>
       <para>April 17th, 2015</para>
       <itemizedlist>
@@ -95,6 +106,6 @@
           <ulink url="&blfs-ticket-root;6418">#6418</ulink>.</para>
         </listitem>
-	<listitem>
-	  <para>[renodr] - Update to xlsatoms-1.1.2. Partially fixes
+        <listitem>
+          <para>[renodr] - Update to xlsatoms-1.1.2. Partially fixes
           <ulink url="&blfs-ticket-root;6418">#6418</ulink>.</para>
         </listitem>
Index: postlfs/config/config.xml
===================================================================
--- postlfs/config/config.xml	(revision f78981d909d471143e5ec43faaacc499045d3cb6)
+++ postlfs/config/config.xml	(revision 3ae81e13dd90ba72bc7d6991f8ebd9d65bff1f65)
@@ -34,5 +34,6 @@
   <para>The first task is making a recovery boot device in
   <xref linkend="postlfs-config-bootdisk"/> because it's the most critical need.
-  Then the system is configured to ease addition of new users, because this
+  Hardware issues relevant to firmware and other devices is addressed next.
+  The system is then configured to ease addition of new users, because this
   can affect the choices you make in the two subsequent
   topics&mdash;<xref linkend="postlfs-config-profile"/> and
@@ -46,7 +47,8 @@
 
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="bootdisk.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="firmware.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="devices.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="skel.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="users.xml"/>
-  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="devices.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="profile.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="vimrc.xml"/>
Index: postlfs/config/firmware.xml
===================================================================
--- postlfs/config/firmware.xml	(revision 3ae81e13dd90ba72bc7d6991f8ebd9d65bff1f65)
+++ postlfs/config/firmware.xml	(revision 3ae81e13dd90ba72bc7d6991f8ebd9d65bff1f65)
@@ -0,0 +1,448 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+   "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+  <!ENTITY % general-entities SYSTEM "../../general.ent">
+  %general-entities;
+]>
+
+<sect1 id="postlfs-firmware" xreflabel="About Firmware">
+  <?dbhtml filename="firmware.html"?>
+
+  <sect1info>
+    <othername>$LastChangedBy: bdubbs $</othername>
+    <date>$Date: 2012-03-13 13:19:34 -0500 (Tue, 13 Mar 2012) $</date>
+  </sect1info>
+
+  <title>About Firmware</title>
+
+  <indexterm zone="postlfs-firmware">
+    <primary sortas="e-lib-firmware">/lib/firmware</primary>
+  </indexterm>
+
+  <para> On some recent PCs it can be necessary, or desirable, to load firmware
+  to make them work at their best. The kernel contains a directory, <filename
+  class="directory">/lib/firmware</filename>, where the kernel or kernel
+  drivers look for firmware images.</para> 
+  
+  <para>Preparing firmware for multiple different machines, as a distro would
+  do, is outside the scope of this book.</para>
+
+  <para>Currently, most firmware can be found at a <userinput>git</userinput>
+  repository: <ulink
+  url="http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/"/>.
+  For convenience, the LFS Project has created a mirror, updated daily, where
+  these firmware files can be accessed vau <userinput>wget</userinput> or a web
+  browser at <ulink
+  url="http://anduin.linuxfromscratch.org/sources/linux-firmware/"/>.</para>
+  
+  <para>To get the firmware either point a browser to one of the above
+  repositories and then download the item(s) which you need, or install
+  <userinput>git</userinput> and clone that repository.</para>
+  
+  <para>For some other firmware, particularly for Intel microcode and certain
+  wifi devices, the needed firmware is not available in the above repository.
+  Some of this will be addressed below, but a search of the Internet for needed
+  firmware is sometimes necessary.</para>
+
+  <para>Firmware files are conventionally referred to as blobs because you cannot
+  determine what they will do. Note that firmware is distributed under various
+  different licenses which do not permit disassembly or reverse-engineering.</para>
+
+  <para>Firmware for PCs falls into four categories:</para>
+
+  <itemizedlist spacing="compact">
+    <listitem>
+      <para>Updates to the CPU to work around errata, usually referred to as
+       microcode.</para>
+    </listitem>
+    <listitem>
+      <para>Firmware for video controllers. On x86 machines this seems to only
+      apply to ATI devices : Radeons require firmware to be able to use KMS
+      (kernel modesetting - the preferred option) as well as for Xorg. For
+      earlier radeon chips (before the R600), the firmware is still in the
+      kernel.</para>
+    </listitem>
+    <listitem>
+      <para>Firmware updates for wired network ports. Mostly they work even
+      without the updates, but one must assume that they will work better with
+      the updated firmware.</para>
+    </listitem>
+    <listitem>
+      <para>Firmware for other devices, such as wifi. These devices are not
+      required for the PC to boot, but need the firmware before these devices
+      can be used.</para>
+    </listitem>
+  </itemizedlist>
+
+  <note><para>Although not needed to load a firmware blob, the following 
+  tools may be useful for determining, obtaining, or preparing the needed 
+  firmware in order to load it into the system:
+    <xref linkend="cpio"/>,
+    <xref linkend="git"/>,
+    <xref linkend="pciutils"/>, and
+    <xref linkend="wget"/></para></note>
+
+  <para condition="html" role="usernotes">User Notes:
+  <ulink url="&blfs-wiki;/aboutfirmware"/></para>
+
+  <sect2 id="cpu-microcode">
+    <title>Microcode updates for CPUs</title>
+
+    <para>In general, microcode can be loaded by the BIOS or UEFI, and it might
+    be updated by upgrading to a newer version of those. On linux, you can also
+    load the microcode from the kernel if you are using an AMD family 10h or
+    later processor (first introduced late 2007), or an intel processor from
+    1998 and later (Pentium4, Core, etc), if updated microcode has been
+    released. These updates only last until the machine is powered off, so they
+    need to be applied on every boot.</para>
+    
+    <para>There are two ways of loading the microcode, described as 'early' and
+    'late'. Early loading happens before userspace has been started, late
+    loading happens when userspace has started. Not surprisingly, early loading
+    is preferred, (see e.g. an explanatory comment in a kernel commit noted at
+    <ulink url="https://lwn.net/Articles/530346/">x86/microcode: Early load
+    microcode </ulink> on LWN.)  Indeed, it is needed to work around one
+    particular erratum in early intel Haswell processors which had TSX enabled.
+    (See <ulink
+    url="http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwellyi/">
+    Intel Disables TSX Instructions: Erratum Found in Haswell, Haswell-E/EP,
+    Broadwell-Y</ulink>.) Without this update glibc can do the wrong thing in
+    uncommon situations.</para>
+    
+    <para>It is much simpler to begin by building a kernel which boots on
+    your hardware, try late microcode loading to see if there is an update (in
+    many cases the BIOS or UEFI will have already applied any update), and then
+    take the extra steps required for early loading.</para>
+    
+    <para>This means you will be reconfiguring your kernel if you use early
+    loading, so keep the built source around to minimise what gets rebuilt, and
+    if you are at all uncertain, add your own identifier (A,B, etc) to the end
+    of the EXTRAVERSION in the kernel configuration, e.g. "EXTRAVERSION -A" if
+    nothing was set.</para>
+    
+    <para>To confirm what processor(s) you have (if more than one, they will be
+    identical) look in /proc/cpufinfo.</para>
+
+    <sect3 id="intel-microcode">
+      <title>Intel Microcode for the CPU</title>
+
+      <bridgehead renderas="sect4">Required Package</bridgehead>
+      <para role='required'>
+         <ulink url='http://fedorahosted.org/released/microcode_ctl/'/></para>
+
+      <para>For intel CPUs an extra package, microcode_ctl, is required. The
+      package chosen is the version hosted at fedora &mdash; there is an
+      alternative version at github from the same packager, but that still
+      includes a redundant old version of an AMD microcode container, and also
+      requires the unzip package.</para>
+
+      <para>Download the latest version from the link above; when last checked,
+      this was 2.1-7 and is updated when intel releases new microcode.</para>
+
+      <para>This package reformats the microcode supplied by intel into a
+      format which the kernel can apply. The program
+      <userinput>intel-microcode2ucode</userinput> is built and invoked by the
+      Makefile to create the individual firmware blobs, so there is no reason
+      to install it.</para>
+
+      <para>Begin by extracting the tarball and changing to the directory it created. 
+      Then change to the source diirectory and run:</para>
+
+<screen><userinput>make</userinput></screen>
+
+      <para>This creates various blobs with names in the form XX-YY-ZZ. Now you
+      need to determine your processor's identity, to see if there is any
+      microcode for it. Determine the decimal values of the cpu family, model
+      and stepping by running:</para>
+
+<screen><userinput>head -n7 /proc/cpuinfo</userinput></screen>
+
+      <para>Now convert the cpu family, model and stepping to pairs of hexadecimal
+      digits. For a SandyBridge i3-2120 (described as Intel(R) Core(TM) i3-2120
+      CPU) the relevant values are cpu family 6, model 42, stepping 7 so in
+      this case the required identification is 06-2a-07. A look at the blobs
+      will show that there is one for this CPU (although it might
+      have already been applied by the BIOS). If there is a blob for your
+      system then test if it will be applied by copying it (replace &lt;XX-YY-ZZ&gt;
+      by the identifier for your machine) and then procede through Late loading
+      of microcode on Intel Processors:</para>
+
+<screen><userinput>mkdir -pv /lib/firmware/intel-ucode
+cp -v &lt;XX-YY-ZZ&gt; /lib/firmware/intel-ucode</userinput></screen>
+
+      <para>Now that the intel microcode has been prepared, use the following
+      options when you configure the kernel to try late loading of the intel
+      microcode:</para>
+
+<screen><literal>Processor type and features  ---&gt;
+  &lt;M&gt; CPU microcode loading support  [CONFIG_MICROCODE]
+  [*]      Intel microcode loading support [CONFIG_MICROCODE_INTEL]</literal></screen>
+
+      <para>After you have successfully booted the new system, use the command
+      <userinput>dmesg | grep microcode</userinput> and study the results to
+      see if the message new patch_level appears.  This example from the
+      SandyBridge i3:</para>
+
+<screen><literal>[    0.059906] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode
+[    2.603083] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x23
+[    2.669378] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x23
+[    2.669994] microcode: CPU0 updated to revision 0x29, date = 2013-06-12
+[    2.670069] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x23
+[    2.670139] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x23
+[    2.670501] microcode: CPU1 updated to revision 0x29, date = 2013-06-12
+[    2.670509] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x23
+[    2.670540] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x23
+[    2.670917] microcode: CPU2 updated to revision 0x29, date = 2013-06-12
+[    2.670955] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x23
+[    2.670988] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x23
+[    2.671348] microcode: CPU3 updated to revision 0x29, date = 2013-06-12
+[    2.671356] perf_event_intel: PEBS enabled due to microcode update
+[    2.671412] microcode: Microcode Update Driver: v2.00 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba</literal></screen>
+
+    <para>If the microcode was not updated, there is no new microcode for
+    this system's processor. If it did get updated, you can now proceed to <xref
+    linkend='early-microcode'/>.</para> 
+
+    </sect3>
+
+    <sect3 id="and-microcode">
+      <title>AMD Microcode for the CPU</title>
+
+      <para>Begin by downloading a container of firmware for your CPU family
+      from <ulink
+      url='http://anduin.linuxfromscratch.org/sources/linux-firmware/amd-ucode/'/>.
+      The family is always specified in hex. Families 10h to 14h (16 to 20)
+      are in microcode_amd.bin.  Families 15h and 16h have their own containers.
+      Create the required directory and put the firmware you downloaded into
+      it as the <systemitem class="username">root</systemitem> user:</para>
+
+<screen><userinput>mkdir -pv /lib/firmware/amd-ucode
+cp -v microcode_amd* /lib/firmware/amd-ucode</userinput></screen>
+
+      <para>When you configure the kernel, use the following options to try
+      late loading of AMD microcode:</para> 
+
+<screen><literal>Processor type and features  ---&gt;
+  &lt;M&gt; CPU microcode loading support   [CONFIG_MICROCODE]
+  [*]   AMD microcode loading support [CONFIG_MICROCODE_AMD]</literal></screen>
+
+      <para>After you have successfully booted the new system, use the command
+      <userinput>dmesg | grep microcode</userinput> and study the results to see
+      if the message new patch_level appears, as in this example from an old
+      Athlon(tm) II X2:</para>
+
+<screen><literal>[    4.183907] microcode: CPU0: patch_level=0x010000b6
+[    4.184271] microcode: CPU0: new patch_level=0x010000c8
+[    4.184278] microcode: CPU1: patch_level=0x010000b6
+[    4.184283] microcode: CPU1: new patch_level=0x010000c8
+[    4.184359] microcode: Microcode Update Driver: v2.00 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba</literal></screen>
+
+    <para>If the microcode was not updated, there is no new microcode for
+    this system's processor. If it did get updated, you can now proceed to <xref
+    linkend='early-microcode'/>.</para> 
+
+    </sect3>
+
+    <sect3 id="early-microcode">
+      <title>Early loading of microcode</title>
+
+      <para>If you have established that updated microcode is available for
+      your system, it is time to prepare it for early loading. This requires
+      an additional package, <xref linkend='cpio'/>, as well as changes to
+      the kernel config and the creation of an initrd which will need to be
+      added to grub.cfg.</para>
+
+      <para>It does not matter where you prepare the initrd, and once it is
+      working you can apply the same initrd to later LFS systems or newer
+      kernels on this same machine, at least until any newer microcode is
+      released. Use the following commands:</para> 
+
+<screen><userinput>mkdir -p initrd/kernel/x86/microcode
+cd initrd</userinput></screen>
+
+      <para>For an AMD machine, use the following command (replace
+      &lt;MYCONTAINER&gt; with the name of the container for your CPU's
+      family):</para>
+
+<screen><userinput>cp -v /lib/firmware/amd_ucode/&lt;MYCONTAINER&gt; kernel/x86/microcode/AuthenticAMD.bin</userinput></screen>
+
+      <para>Or for an Intel machine copy the appropriate blob using this command:</para>
+
+<screen><userinput>cp -v /lib/firmware/intel-ucode/&lt;XX-YY-ZZ&gt; kernel/x86/microcode/GenuineIntel.bin</userinput></screen>
+
+      <para>Now prepare the initrd:</para>
+
+<screen><userinput>find . | cpio -o -H newc &gt; /boot/microcode.img</userinput></screen>
+
+      <para>You will now need to reconfigure and rebuild your kernel. It is
+      safer to either add/change the EXTRAVERSION in the kernel's configuration
+      and install the newer kernel with a new name, or else (unless you have a
+      machine which requires an early firmware update) wait for the next
+      SUBLEVEL kernel release so that you can fall back to the existing kernel
+      in the event that something goes wrong.</para>
+
+      <para>You will also need to add a new entry to /boot/grub/grub.cfg and
+      here you should add a new line after the linux line within the stanza.
+      If /boot is a separate mountpoint: </para>
+
+<screen><userinput>initrd /microcode.img</userinput></screen>
+
+      <para>or this if it is not:</para>
+
+<screen><userinput>initrd /boot/microcode.img</userinput></screen>
+
+      <para>You must also change the kernel config:</para>
+
+<screen><literal>General Setup ---&gt;
+  [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
+  [y] CPU microcode loading support                                  [CONFIG_MICROCODE]</literal></screen>
+
+      <para>Retain the setting for INTEL or AMD microcode. When you have saved
+      the .config file, either CONFIG_MICROCODE_INTEL_EARLY=y or
+      CONFIG_MICROCODE_AMD_EARLY=y should be set, together with
+      CONFIG_MICROCODE_EARLY=y.</para>
+
+      <para>When you have installed and booted this kernel, you should check
+      the output of dmesg to confirm that the early load worked. The places and
+      times where this happens are very different in AMD and Intel machines.
+      First, an Intel example where a development kernel is being tested,
+      showing that the first notification comes before the kernel version is
+      mentioned:</para>
+
+<screen><literal>[    0.000000] CPU0 microcode updated early to revision 0x29, date = 2013-06-12
+[    0.000000] Linux version 4.0.0-rc6 (ken@jtm1) (gcc version 4.9.2 (GCC) ) 
+               #3 SMP PREEMPT Mon Mar 30 21:26:02 BST 2015
+[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.0.0-rc6-sda13 root=/dev/sda13 ro
+...
+[    0.103091] CPU1 microcode updated early to revision 0x29, date = 2013-06-12
+[    0.113241]  #2
+[    0.134631]  #3
+[    0.147821] x86: Booted up 1 node, 4 CPUs
+[    0.147936] smpboot: Total of 4 processors activated (26338.66 BogoMIPS)
+...
+[    0.272643] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x29
+[    0.272709] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x29
+[    0.272775] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x29
+[    0.272842] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x29
+[    0.272941] microcode: Microcode Update Driver: v2.00 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba</literal></screen>
+
+      <para>A second AMD example is where the machine was running a stable
+      kernel on an older version of LFS. Note that here there is no mention of
+      the previous microcode version &mdash; compare this output to the AMD
+      late loading messages (above) from the same machine:</para> 
+
+<screen><literal>[    0.000000] Linux version 3.18.11 (ken@milliways) (gcc version 4.9.1 (GCC) ) 
+               #4 SMP Thu Apr 9 21:51:05 BST 2015
+[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.18.11-sda5 root=/dev/sda5 video=800x600 ro
+...
+[    0.584009] Trying to unpack rootfs image as initramfs...
+[    0.584092] microcode: updated early to new patch_level=0x010000c8
+...
+[    0.586733] microcode: CPU0: patch_level=0x010000c8
+[    0.586778] microcode: CPU1: patch_level=0x010000c8
+[    0.586866] microcode: Microcode Update Driver: v2.00 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba</literal></screen>
+
+    </sect3>
+
+  </sect2>
+
+  <sect2 id="ati-video-firmware">
+    <title>Firmware for ATI video chips (R600 and later)</title>
+    
+    <para>These instructions do NOT apply to old radeons before the R600
+    family. For those, the firmware is in the kernel's <filename
+    class='directory'>/lib/firmware/</filename> directory. Nor do they apply if
+    you intend to avoid a graphical setup such as Xorg and are content to use
+    the default 80x25 display rather than a framebuffer. </para>
+
+    <para> Early radeon devices only needed a single 2K blob of firmware.
+    Recent devices need several different blobs, and some of them are much
+    bigger. The total size of the radeon firmware directory is over 500K &mdash; on a
+    large modern system you can probably spare the space, but it is still
+    redundant to install all the unused files each time you build a system.</para>
+
+    <para>A better approach is to install <xref linkend='pciutils'/> and then
+    use <userinput>lspci</userinput> to identify which VGA controller is
+    installed.</para>
+
+    <para>With that information, check the RadeonFeature page of the Xorg wiki
+    for <ulink url="http://wiki.x.org/wiki/RadeonFeature/#index5h2">Decoder
+    ring for engineering vs marketing names</ulink> to identify the family (you
+    may need to know this for the Xorg driver in BLFS &mdash; Southern Islands and
+    Sea Islands use the radeonsi driver) and the specific model.</para>
+
+    <para>Now that you know which controller you are using, consult the 
+    <ulink url="https://wiki.gentoo.org/wiki/Radeon#Firmware">Radeon</ulink> page
+    of the Gentoo wiki which has a table listing the required firmware blobs
+    for the various chipsets. Note that Southern Islands and Sea Islands chips
+    use different firmware for kernel 3.17 and later compared to earlier
+    kernels. Identify and download the required blobs then install them:</para>
+
+<screen><userinput>mkdir -pv /lib/firmware/radeon
+cp -v &lt;YOUR_BLOBS&gt; /lib/firmware/radeon</userinput></screen>
+
+    <para>There are actually two ways of installing this firmware. BLFS, in the
+    'Kernel Configuration for additional firmware' section part of the <xref
+    linkend="xorg-ati-driver"/> section  gives an example of compiling the
+    firmware into the kernel - that is slightly faster to load, but uses more
+    kernel memory. Here we will use the alternative method of making the radeon
+    driver a module. In your kernel config set the following: </para>
+
+<screen><literal>Device Drivers ---&gt;
+  Graphics support ---&gt;
+      Direct Rendering Manager ---&gt;
+            &lt;*&gt; Direct Rendering Manager (XFree86 ... support)  [CONFIG_DRM]
+            &lt;m&gt; ATI Radeon                                      [CONFIG_DRM_RADEON]</literal></screen>
+
+    <para>Loading several large blobs from /lib/firmware takes a noticeable
+    time, during which the screen will be blank. If you do not enable the
+    penguin framebuffer logo, or change the console size by using a bigger
+    font, that probably does not matter. If desired, you can slightly
+    reduce the time if you follow the alternate method of specifying 'y' for
+    CONFIG_DRM_RADEON covered in BLFS at the link above &mdash; you must specify each
+    needed radeon blob if you do that.</para>
+
+  </sect2>
+
+  <sect2 id="nic-firmware">
+    <title>Firmware for Network Interfaces</title>
+
+    <para>The kernel likes to load firmware for some network drivers,
+    particularly those from Realtek (the /lib/linux-firmware/rtl_nic/) directory,
+    but they generally appear to work without it. Therefore, you can boot the
+    kernel, check dmesg for messages about this missing firmware, and if
+    necessary download the firmware and put it in the specified directory in
+    /lib/firmware so that it will be found on subsequent boots. Note that with
+    current kernels this works whether or not the driver is compiled in or
+    built as a module, there is no need to build this firmware into the kernel.
+    Here is an example where the R8169 driver has been compiled in but the
+    firmware was not made available. Once the firmware had been provided, there
+    was no mention of it on later boots. </para>
+
+<screen><literal>dmesg | grep firmware | grep r8169
+[    7.018028] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168g-2.fw failed with error -2
+[    7.018036] r8169 0000:01:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168g-2.fw (-2)</literal></screen>
+
+  </sect2>
+
+  <sect2 id="other-firmware">
+    <title>Firmware for Other Devices</title>
+
+    <para> Identifying the correct firmware will typically require you to
+    install <xref linkend='pciutils'/>, and then use
+    <userinput>lspci</userinput> to identify the device. You should then search
+    online to check which module it uses, which firmware, and where to obtain
+    the firmware &mdash; not all of it is in linux-firmware.</para>
+    
+    <para>If possible, you should begin by using a wired connection when you
+    first boot your LFS system. To use a wireless connection you will need to
+    use a network tools such as <xref linkend='wireless_tools'/> and <xref
+    linkend='wpa_supplicant'/>.</para>
+    
+    <para>Firmware may also be needed for other devices such as some SCSI
+    controllers, bluetooth adaptors, or TV recorders. The same principles
+    apply.</para>
+
+  </sect2>
+
+</sect1>
