Beyond Linux® From Scratch - Version 7.9

Chapter 3. After LFS Configuration Issues

About Firmware

On some recent PCs it can be necessary, or desirable, to load firmware to make them work at their best. There is a directory, /lib/firmware, where the kernel or kernel drivers look for firmware images.

Preparing firmware for multiple different machines, as a distro would do, is outside the scope of this book.

Currently, most firmware can be found at a git repository: 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 via wget or a web browser at http://anduin.linuxfromscratch.org/BLFS/linux-firmware/.

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 git and clone that repository.

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.

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.

Firmware for PCs falls into four categories:

[Note]

Note

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: cpio-2.12, git-2.7.1, pciutils-3.4.1, and Wget-1.17.1

User Notes: http://wiki.linuxfromscratch.org/blfs/wiki/aboutfirmware

Microcode updates for CPUs

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.

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 x86/microcode: Early load microcode on LWN.) Indeed, it is needed to work around one particular erratum in early intel Haswell processors which had TSX enabled. (See Intel Disables TSX Instructions: Erratum Found in Haswell, Haswell-E/EP, Broadwell-Y.) Without this update glibc can do the wrong thing in uncommon situations.

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.

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.

To confirm what processor(s) you have (if more than one, they will be identical) look in /proc/cpuinfo.

Intel Microcode for the CPU

Required Package

http://fedorahosted.org/released/microcode_ctl/

For intel CPUs an extra package, microcode_ctl, is required. The package chosen is the version hosted at fedora — 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.

Download the latest version from the link above; when last checked this was 2.1-8 and is updated when intel releases new microcode.

This package reformats the microcode supplied by intel into a format which the kernel can apply. The program intel-microcode2ucode is built and invoked by the Makefile to create the individual firmware blobs, so there is no reason to install it.

Begin by extracting the tarball and changing to the directory it created. Then change to the source directory and run: 

make

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: 

head -n7 /proc/cpuinfo

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 <XX-YY-ZZ> by the identifier for your machine) to where the kernel can find it: 

mkdir -pv /lib/firmware/intel-ucode
cp -v <XX-YY-ZZ> /lib/firmware/intel-ucode

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: 

Processor type and features  --->
  <M> CPU microcode loading support  [CONFIG_MICROCODE]
  [*]      Intel microcode loading support [CONFIG_MICROCODE_INTEL]

After you have successfully booted the new system, use the command dmesg | grep microcode and study the results to see if the message new patch_level appears. This example from the SandyBridge i3: 

[    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 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

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 the section called “Early loading of microcode”.

AMD Microcode for the CPU

Begin by downloading a container of firmware for your CPU family from http://anduin.linuxfromscratch.org/BLFS/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 root user: 

mkdir -pv /lib/firmware/amd-ucode
cp -v microcode_amd* /lib/firmware/amd-ucode

When you configure the kernel, use the following options to try late loading of AMD microcode: 

Processor type and features  --->
  <M> CPU microcode loading support   [CONFIG_MICROCODE]
  [*]   AMD microcode loading support [CONFIG_MICROCODE_AMD]

After you have successfully booted the new system, use the command dmesg | grep microcode and study the results to see if the message new patch_level appears, as in this example from an old Athlon(tm) II X2: 

[    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 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

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 the section called “Early loading of microcode”.

Early loading of microcode

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, cpio-2.12, as well as changes to the kernel config and the creation of an initrd which will need to be added to grub.cfg.

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: 

mkdir -p initrd/kernel/x86/microcode
cd initrd

For an AMD machine, use the following command (replace <MYCONTAINER> with the name of the container for your CPU's family): 

cp -v /lib/firmware/amd_ucode/<MYCONTAINER> kernel/x86/microcode/AuthenticAMD.bin

Or for an Intel machine copy the appropriate blob using this command: 

cp -v /lib/firmware/intel-ucode/<XX-YY-ZZ> kernel/x86/microcode/GenuineIntel.bin

Now prepare the initrd: 

find . | cpio -o -H newc > /boot/microcode.img

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.

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: 

initrd /microcode.img

or this if it is not: 

initrd /boot/microcode.img

You must also change the kernel config: 

General Setup --->
  [y] Initial RAM filesystem and RAM disk (initramfs/initrd) support [CONFIG_BLK_DEV_INITRD]
  [y] CPU microcode loading support                                  [CONFIG_MICROCODE]

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.

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: 

[    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 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

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 — compare this output to the AMD late loading messages (above) from the same machine: 

[    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 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Firmware for Video Cards

Firmware for ATI video chips (R600 and later)

These instructions do NOT apply to old radeons before the R600 family. For those, the firmware is in the kernel's /lib/firmware/ 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.

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 — 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.

A better approach is to install pciutils-3.4.1 and then use lspci to identify which VGA controller is installed.

With that information, check the RadeonFeature page of the Xorg wiki for Decoder ring for engineering vs marketing names to identify the family (you may need to know this for the Xorg driver in BLFS — Southern Islands and Sea Islands use the radeonsi driver) and the specific model.

Now that you know which controller you are using, consult the Radeon 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: 

mkdir -pv /lib/firmware/radeon
cp -v <YOUR_BLOBS> /lib/firmware/radeon

There are actually two ways of installing this firmware. BLFS, in the 'Kernel Configuration for additional firmware' section part of the Xorg ATI Driver-7.6.1 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: 

Device Drivers --->
  Graphics support --->
      Direct Rendering Manager --->
        <*> Direct Rendering Manager (XFree86 ... support)  [CONFIG_DRM]
      <m> ATI Radeon                                        [CONFIG_DRM_RADEON]

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 — you must specify each needed radeon blob if you do that.

Firmware for Nvidia video chips

Some Nvidia graphics chips need firmware updates to take advantage of all the card's capability. These are generally the GeForce 8, 9, 9300, and 200-900 series chips. For more exact information, see https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware.

First, the kernel Nvidia driver must be activated: 

Device Drivers --->
  Graphics support --->
      Direct Rendering Manager --->
        <*> Direct Rendering Manager (XFree86 ... support)  [CONFIG_DRM]
      <*/m> Nouveau (NVIDIA) cards                          [CONFIG_DRM_NOUVEAU]

The steps to install the Nvidia firmware are: 

wget https://raw.github.com/imirkin/re-vp2/master/extract_firmware.py
wget http://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86-325.15.run
sh NVIDIA-Linux-x86-325.15.run --extract-only
python extract_firmware.py 
mkdir -p /lib/firmware/nouveau
cp -d nv* vuc-* /lib/firmware/nouveau/

Firmware for Network Interfaces

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. 

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)

Firmware for Other Devices

Identifying the correct firmware will typically require you to install pciutils-3.4.1, and then use lspci to identify the device. You should then search online to check which module it uses, which firmware, and where to obtain the firmware — not all of it is in linux-firmware.

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 Wireless Tools-29 and wpa_supplicant-2.5.

Firmware may also be needed for other devices such as some SCSI controllers, bluetooth adaptors, or TV recorders. The same principles apply.

Last updated on 2016-03-02 13:42:47 -0800