Sorry, you need to enable JavaScript to visit this website.

LUV your firmware -- Part II

This part two in a three-part series of blog posts.

Last time we met Gayatri Kammela from the Linux UEFI Validation (LUV) Project and learned a little bit about the work her team is doing to empower firmware developers and testers with better tools.  Today we'll walk you through a typical user test, show you how to access test results, and point you to some extra project resources that can help you use the test results to further optimize your system.

But first things first … let's boot to LUV.  The system under test boots directly to the LUV image to validate interaction with the boot-loader and Linux kernel.  Every machine has its own way of accessing the BIOS or boot menu; see this link for more info.  Common methods are to press ESC, F2, F9, or F12 immediately after power-on of a machine.   Consult your machine documentation to find out how to access it in your environment.  In any case, the menu we want to find should let us choose the device (or boot order of device) to continue booting.  

The LUV team is working to feature UEFI secure boot on LUV. However, the feature has not yet been deployed. In the meantime, we can still use LUV by disabling UEFI secure boot in the BIOS menu. Following that,  we can select the USB drive that contains our image and, once selected, we see a screen that allows us to either boot LUV or to select the test suite we want to run.

At the time of this writing, LUV has four test suites:

1.  (U)EFI variable filesystem tests / EFIvarfs

2.  Kernel-issued warnings

3.  BIOS Implementation Test Suite / BITS

4.  FirmWare Test Suite / FWTS

The execution of the test suites generally unfolds as follows within the larger system: 

Understanding the order of the test suites is important as this can help us more easily narrow down where a problem lies.  For example, BITS is the first of the test suites to run.  If this test is taking too long, we can surmise that a problem lies with the hardware.  

Kernel-efi-warnings can be generated any time during the kernel boot; LUV gathers and displays the results after boot.   

EFIvarfs test suite contains code for EFI variable handling at the firmware-level via sysfs.  It also contains a pstore backend that can help us debug problems that may arise before FWTS.   

FWTS allows us to run in-depth tests on the firmware with a default level of batch tests (for details see the link).  Again, if running this particular test suite hangs  up and takes a long time,  we can be pretty sure that the problem lies in the firmware.

So now that we have a general overview for these four suites and the order in which they're run, what can we expect to see on our target machine while running them?  BITS, as the first test shows us this:  


If we choose the “Select test suites” option and press Enter, four test suites are presented.  Each one has an option to be selected or unselected.  

To get back to the previous menu use Esc.  Now we can choose to “Boot LUV”

The following starts a process and lets you know that LUV is booting; this can sometimes take a little bit of time.  Be patient.

After this process, the following screen should appear:   

 

 

 

 

 

For more information about background processes running while “Preparing crash handler” is being displayed, you may connect or configure your test machine to support serial console.  (One way of doing this is explained here).  

Output should look something like this:

 

 

 

 

 

 

 

 

 

And finally, the Linux UEFI Validation screen appears with a progress bar indicating which test suite is currently propagating.  A configured serial console screen will display more detailed information. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

When all the tests are completed, the last message we see is this.   

Having completed the tests, now what?  

To access the results of the tests, we'll need to remove the USB drive from our target test machine, and open the USB drive (note – we don't boot from the USB drive again) on a different machine, or on the same machine when it has been booted normally.  We'll see two partitions, one named /boot and one named /luv-results.  The pass/fail results of our tests can be found in the directory called

/luv-results/parsed

and the debugging results are found in the directory called

/luv-results/raw

In Part III, we dig further into the LUV project from a developer's perspective, and show you how to prepare an environment for building an image and running more in-depth firmware tests.