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

LUV your firmware -- Part III

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

The third post in this series describes an alternate and more detailed way to set up the environment for LUV.  To keep things as simple as possible, we’ve broken the steps out into pieces:  (1) Download, (2) Build, (3a) Create a local environment and run from that, or (3b) Create a live image to run on another machine.  We've also included many screenshots to help along the way. 

Step 1 -- Download:   Clone the github repo and enter the directory where the cloned repository is present.  For example, if you cloned it into a directory named luv by running

$ git clone luv

you'd enter

$ cd luv


Step 2 -- Build:  Build the environment with the following command:

~/luv$ . oe-init-build-env

At this point, we can configure the build.  Here we'll open the config file with a text editor (gedit in this example)

~/luv$ gedit conf/bblayers.conf

and insert a line directly under BBLAYERS ?= “ \ to match the structure of our directories.  Be sure to not insert any extra spaces or blank lines, as those can yield an error.   

Now we open the local.conf file for editing, and uncomment  #MACHINE ?="qemux86-64"

In this same file, set the variable DISTRO from “poky” to “luv”

and continue to modify the local.conf file to specify, for example,  BB_NUMBER_THREADS:

In the most recent version of LUV, the variables BB_NUMBER_THREADS and PARALLEL_MAKE are not present in the local.conf file.  Thus, we can add them. This is optional, but doing so can speed-up build time dramatically.  For example, we can enter "8" provided we have at least 8 cores.  To check the number of cores in your system look under /proc/cpuinfo

The fewer threads we specify, the longer the tasks will take.   Provided we have the power, more is better.

Now are there two ways to view the results we'd normally see after booting:

a) Use the development machine as the host to run the image with qemu (this is recommended if you want to confirm the tests run locally first) Step 3a or

b) Create a custom image and flash it onto a USB drive which can be used to boot an alternate platform we wish to test (see Step 3b).  It's not necessary to do Step 3a beforehand, but we recommend testing locally first.

But first we're going to run (as part of the build on a host machine)

$ bitbake core-image-efi-initramfs    


and install any missing dependency packages output by this command.  Your results will vary depending upon the distribution of Linux you’re using.  For example, you may need to run:

$ sudo apt-get install texinfo

or if that doesn’t work:

$ sudo apt-get install makeinfo

Step 3a -- Create a local build environment, and run from that:  First we use qemu and the bitbake tool to create a build environment using initramfs as follows:

$ runqemu qemux86-64 biosdir="/usr/share/ovmf" biosfilename=”bios.bin” ramfs core-image-efi-initramfs

To view it with serial console try:

$ runqemu qemux86-64 biosdir="/usr/share/ovmf" biosfilename=”bios.bin” ramfs core-image-efi-initramfs serial


Once we’ve successfully run the tools to this point, and can confirm that our environment has been set up correctly, we can test further by creating a custom image.  The following screenshots show a little of what to expect if the environment has been set up correctly:


The username for the qemux86-64 login is root and no password is required. To monitor the processes we may use dmesg to view the results.

Now after login, we can see results in both /var/log/luv and in /tmp/luv.results

With the above steps, we can run any of the test suites except BITS; BITS runs before the kernel boot loader runs.

And if we still wish to see the output of BITS via serial console, this is one way of doing so:  

1) create a live image to run the bits via serial console

2)  return to your home directory using  cd ~

3) run

$ ./luv/build/tmp/sysroots/x86_64-linux/usr/bin/qemu-system-x86_64 -serial stdio -L ./luv/build/tmp/sysroots/x86_64-linux/usr/share/ovmf -bios bios.bin -m 256 ./luv/build/tmp/deploy/images/qemux86-64/luv-live-image.img

This is a messy-looking command, but it breaks apart as follows:  

  • ./luv/build/tmp/sysroots/x86_64-linux/usr/bin/qemu-system-x86_64 represents the path of the native target which uses qemu
  • -serial stdio -L ports the output to serial console
  • ./luv/build/tmp/sysroots/x86_64-linux/usr/share/ovmf -bios bios.bin indicates that the path to the bios .ovmf is the native bios and updates it to bios.bin
  • -m 256 indicates memory (256 MB)
  • ./luv/build/tmp/deploy/images/qemux86-64/luv-live-image.img is the path where the luv-live-image resides.

In short, results of the above command will yield something like this:

Take note of the highlighted line.  Since BITS ran all its tests, we got 5 test suites (including BITS).

Step 3b:  Create a live image, and run from that.  The other option, if we want to run LUV on another machine, is to use the bitbake tool to create the live image:

$ bitbake luv-live-image

If any errors persist, we may need to try again with optional cleanup parameters like these:

$ bitbake –c clean luv-live-image

And now we're ready to flash the live image we just created to the USB drive.  Running the df command displays any detected USB partitions; you'll likely need to be super user (root) to do this:

Now we can unmount the partition using the umount command; in our example, the partition is sdb, but in your system it may be different.  

# umount  /dev/sdb /dev/sdb2

Use the dd command to flash the image onto the USB stick where luv_image is the location of the .img file and sdx is the USB partition.   Flashing the test suite onto a USB stick will overwrite everything on your USB stick, so be especially cautious when running the dd command -- specifying the wrong device partition can wipe an entire hard disk!

# dd if=/path/to/luv_image of=/dev/sdx

Since we've built the custom image, the location of the image will generally be something like  /luv-yocto/build/tmp/deploy/images/qemux86-64/luv-live-image.img

And finally, we can confirm that our build worked when we see two partitions on the USB drive:   


Visit for the latest releases -- and for specific questions about the results from your tests, feel free to write our mailing list:  

Finally, as this is an open-source project, we welcome your contributions, feedback, and issue reporting on GitHub.


See also:  Part I, Part II