Index: introduction/welcome/changelog.xml
===================================================================
--- introduction/welcome/changelog.xml	(revision a01d3081c87eefd8658e4d883a55f6c79035055a)
+++ introduction/welcome/changelog.xml	(revision f2d5c26a8de29cc86fa869ed9ba8a2a5bdb125b4)
@@ -46,4 +46,8 @@
       <itemizedlist>
         <listitem>
+          <para>[ken] - Update the firmware page for intel microcode. Fixes
+          <ulink url="&blfs-ticket-root;9292">#9292</ulink>.</para>
+        </listitem>
+        <listitem>
           <para>[bdubbs] - Update to plasma-5.10.0. Includes 
           libkscreen in lxqt. Fixes
@@ -61,4 +65,8 @@
       <para>May 31st, 2017</para>
       <itemizedlist>
+        <listitem>
+          <para>[ken] - Update the firmware page for intel microcode. Fixes
+          <ulink url="&blfs-ticket-root;9292">#9292</ulink>.</para>
+        </listitem>
         <listitem>
           <para>[bdubbs] - Update to gegl-0.3.18. Fixes
Index: postlfs/config/firmware.xml
===================================================================
--- postlfs/config/firmware.xml	(revision a01d3081c87eefd8658e4d883a55f6c79035055a)
+++ postlfs/config/firmware.xml	(revision f2d5c26a8de29cc86fa869ed9ba8a2a5bdb125b4)
@@ -57,6 +57,7 @@
     </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
+      <para>Firmware for video controllers. On x86 machines this seems to mostly
+      apply to ATI devices : Radeons, the later AMD amdgpu chips, and Nvidia
+      Maxwell cards 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
@@ -115,5 +116,5 @@
 
     <para>As a result, early loading is now expected, although for the moment
-    (4.9 kernels) it is still possible to manually force late loading of
+    (4.11 kernels) it is still possible to manually force late loading of
     microcode for testing. You will need to reconfigure your kernel for either
     method. The instructions here will create a kernel
@@ -128,44 +129,16 @@
       <title>Intel Microcode for the CPU</title>
 
-      <bridgehead renderas="sect4">Required File</bridgehead>
-      <para role='required'>
-         <ulink url='&sources-anduin-http;/intel-microcode/intel-microcode2ucode.c'/>
-      </para>
-
-      <para>For Intel CPUs an extra program, intel-microcode2ucode, is required. 
-      This is done a little differently since it is only a single source
-      code file.  The reason for this is that there are different versions
-      available, but most are specific to commercial distributions.</para>
-
-      <para>This program reformats the microcode supplied by Intel into a
-      format which the kernel can apply. The program
-      <userinput>intel-microcode2ucode</userinput> is used to create the
-      individual firmware blobs </para>
-
-      <para>Create the program by downloading the source file and running:</para>
-
-<screen><userinput>gcc -g -Wall -O2 -o intel-microcode2ucode intel-microcode2ucode.c</userinput></screen>
-
-      <para>Now install the program as the <systemitem class="username">root</systemitem> user:</para>
-
-<screen><userinput>install intel-microcode2ucode /usr/bin</userinput></screen>
-
-     <para>The next step is to get the most recent version of the Intel
+     <para>The first step is to get the most recent version of the Intel
      microcode.  This must be done by navigating to 
      <ulink url='https://downloadcenter.intel.com/download/26400/Linux-Processor-Microcode-Data-File'/>
      and following the instructions there.  As of this writing the most recent
-     version of the microcode is <filename>microcode-20161104.tgz</filename>.
-     This file is a tar file, but expands to <filename>microcode.dat</filename>
-     in the current directory.</para>
-
-     <para>Next, create various blobs with names in the form XX-YY-ZZ in a
-     subdirectory named <filename class="directory">intel-ucode/</filename>:
-     </para>
-
-<screen><userinput>intel-microcode2ucode microcode.dat</userinput></screen>
+     version of the microcode is <filename>microcode-20170511.tgz</filename>.
+     Extract this file in the normal way to create an <filename>intel-ucode</filename>
+     directory, containing various blobs with names in the form XX-YY-ZZ.</para>
 
      <para>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>
+     model and stepping by running the following command (it will also report
+     the current microcode version):</para>
 
 <screen><userinput>head -n7 /proc/cpuinfo</userinput></screen>
@@ -204,13 +177,14 @@
       <para>This example from the Haswell i7 which was released in Q2 2014 and is
       not affected by the TSX errata shows it has been updated from revision 0x19
-      in the BIOS/UEFI to revision 0x20. Unlike in older kernels, the individual
+      in the BIOS/UEFI to revision 0x22. Unlike in older kernels, the individual
       CPUs are not separately reported:</para>
 
-<screen><literal>[    0.000000] Linux version 4.9.12 (ken@plexi) (gcc version 6.3.0 (GCC) )
-               #3 SMP PREEMPT Mon Mar 6 03:29:27 GMT 2017
-[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.9.12-sda8 root=/dev/sda8 ro
-[    0.913685] microcode: sig=0x306c3, pf=0x2, revision=0x19
-[    0.913905] microcode: Microcode Update Driver: v2.01 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba
-[  148.723932] microcode: updated to revision 0x20, date = 2016-03-16</literal></screen>
+<screen><literal>[    0.000000] Linux version 4.11.0 (lfs@plexi) (gcc version 7.1.0 (GCC) )
+               #1 SMP PREEMPT Sun May 14 16:00:00 BST 2017
+[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.11.0-sda6 root=/dev/sda6 ro
+[    0.913685] microcode: sig=0x306c3, pf=0x2, revision=0x22
+[    0.913905] microcode: Microcode Update Driver: v2.2.
+[  148.723932] microcode: updated to revision 0x22, date = 2017-01-27</literal></screen>
+    <para>That may be followed by individual reports for each core.</para>
 
     <para>If the microcode was not updated, there is no new microcode for
@@ -322,16 +296,16 @@
 
       <para>The places and times where early loading happens are very different
-      in AMD and Intel machines. First, an Intel example from an updated stable
+      in AMD and Intel machines. First, an Intel example from an updated
       kernel, showing that the first notification comes before the kernel version
       is mentioned:</para>
 
-<screen><literal>[    0.000000] microcode: microcode updated early to revision 0x20, date = 2016-03-16
-[    0.000000] Linux version 4.9.14 (ken@plexi) (gcc version 6.3.0 (GCC) )
-               #6 SMP PREEMPT Mon Mar 13 16:19:11 GMT 2017
-[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.9.14-sda8 root=/dev/sda8 ro
-[    0.920217] microcode: sig=0x306c3, pf=0x2, revision=0x20
-[    0.920514] microcode: Microcode Update Driver: v2.01 &lt;tigran@aivazian.fsnet.co.uk&gt;, Peter Oruba</literal></screen>
-
-      <para>An AMD example for the same kernel version:</para>
+<screen><literal>[    0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27
+[    0.000000] Linux version 4.11.0 (lfs@plexi) (gcc version 7.1.0 (GCC) )
+               #2 SMP PREEMPT Sun May 14 17:58:53 BST 2017
+[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.11.0-sda6 root=/dev/sda6 ro
+[    0.928947] microcode: sig=0x306c3, pf=0x2, revision=0x22
+[    0.929160] microcode: Microcode Update Driver: v2.2.</literal></screen>
+
+      <para>An AMD example for an earlier stable kernel version:</para>
 
 <screen><literal>[    0.000000] Linux version 4.9.14 (ken@testserver) (gcc version 6.3.0 (GCC) )
