meta-swupdate: building with Yocto

Overview

The Yocto-Project is a community project under the umbrella of the Linux Foundation that provides tools and template to create the own custom Linux-based software for embedded systems.

Add-on features can be added using layers. meta-swupdate is the layer to cross-compile the SWUpdate application and to generate the compound SWU images containing the release of the product. It contains the required changes for mtd-utils and for generating Lua. Using meta-SWUpdate is a straightforward process. As described in Yocto’s documentation about layers, you should include it in your bblayers.conf file to use it.

Add meta-SWUpdate as usual to your bblayers.conf. You have also to add meta-oe to the list.

In meta-SWUpdate there is a recipe to generate an initrd with a rescue system with SWUpdate. Use:

MACHINE=<your machine> bitbake swupdate-image

You will find the result in your tmp/deploy/<your machine> directory. How to install and start an initrd is very target specific - please check in the documentation of your bootloader.

What about libubootenv ?

This is a common issue when SWUpdate is built. SWUpdate depends on this library, that is generated from the U-Boot’s sources. This library allows one to safe modify the U-Boot environment. It is not required if U-Boot is not used as bootloader. If SWUpdate cannot be linked, you are using an old version of U-Boot (you need at least 2016.05). If this is the case, you can add your own recipe for the package u-boot-fw-utils, adding the code for the library.

It is important that the package u-boot-fw-utils is built with the same sources of the bootloader and for the same machine. In fact, the target can have a default environment linked together with U-Boot’s code, and it is not (yet) stored into a storage. SWUpdate should be aware of it, because it cannot read it: the default environment must be linked as well to SWUpdate’s code. This is done inside the libubootenv.

If you build for a different machine, SWUpdate will destroy the environment when it tries to change it the first time. In fact, a wrong default environment is taken, and your board won’t boot again.

To avoid possible mismatch, a new library was developed to be hardware independent. A strict match with the bootloader is not required anymore. The meta-swupdate layer contains recipes to build the new library (libubootenv) and adjust SWUpdate to be linked against it. To use it as replacement for u-boot-fw-utils:

  • set PREFERRED_PROVIDER_u-boot-fw-utils = “libubootenv”

  • add to SWUpdate config:

CONFIG_UBOOT=y

With this library, you can simply pass the default environment as file (u-boot-initial-env). It is recommended for new project to switch to the new library to become independent from the bootloader.

The swupdate class

meta-swupdate contains a class specific for SWUpdate. It helps to generate the SWU image starting from images built inside the Yocto. It requires that all components, that means the artifacts that are part of the SWU image, are present in the Yocto’s deploy directory. This class should be inherited by recipes generating the SWU. The class defines new variables, all of them have the prefix SWUPDATE_ in the name.

  • SWUPDATE_IMAGES : this is a list of the artifacts to be packaged together. The list contains the name of images without any extension for MACHINE or filetype, that are added automatically. Example :

SWUPDATE_IMAGES = "core-image-full-cmdline uImage"

  • SWUPDATE_IMAGES_FSTYPES : extension of the artifact. Each artifact can have multiple extension according to the IMAGE_FSTYPES variable. For example, an image can be generated as tarball and as UBIFS for target. Setting the variable for each artifact tells the class which file must be packed into the SWU image.

SWUPDATE_IMAGES_FSTYPES[core-image-full-cmdline] = ".ubifs"

  • SWUPDATE_IMAGES_NOAPPEND_MACHINE : flag to use drop the machine name from the artifact file. Most images in deploy have the name of the Yocto’s machine in the filename. The class adds automatically the name of the MACHINE to the file, but some artifacts can be deployed without it.

SWUPDATE_IMAGES_NOAPPEND_MACHINE[my-image] = "1"

  • SWUPDATE_SIGNING : if set, the SWU is signed. There are 3 allowed values: RSA, CMS, CUSTOM. This value determines used signing mechanism.

  • SWUPDATE_SIGN_TOOL : instead of using openssl, use SWUPDATE_SIGN_TOOL to sign the image. A typical use case is together with a hardware key. It is available if SWUPDATE_SIGNING is set to CUSTOM

  • SWUPDATE_PRIVATE_KEY : this is the file with the private key used to sign the image using RSA mechanism. Is available if SWUPDATE_SIGNING is set to RSA.

  • SWUPDATE_PASSWORD_FILE : an optional file containing the password for the private key. It is available if SWUPDATE_SIGNING is set to RSA.

  • SWUPDATE_CMS_KEY : this is the file with the private key used in signing process using CMS mechanism. It is available if SWUPDATE_SIGNING is set to CMS.

  • SWUPDATE_CMS_CERT : this is the file with the certificate used in signing process using CMS method. It is available if SWUPDATE_SIGNING is set to CMS.

  • SWUPDATE_AES_FILE : this is the file with the AES password to encrypt artifact. A new fstype is supported by the class (type: enc). SWUPDATE_AES_FILE is generated as output from openssl to create a new key with

    openssl enc -aes-256-cbc -k <PASSPHRASE> -P -md sha1 -nosalt > $SWUPDATE_AES_FILE

    To use it, it is enough to add IMAGE_FSTYPES += “enc” to the artifact. SWUpdate supports decryption of compressed artifact, such as

    IMAGE_FSTYPES += ".ext4.gz.enc"

Automatic sha256 in sw-description

The swupdate class takes care of computing and inserting sha256 hashes in the sw-description file. The attribute sha256 must be set in case the image is signed. Each artifact must have the attribute:

sha256 = "$swupdate_get_sha256(artifact-file-name)"

For example, to add sha256 to the standard Yocto core-image-full-cmdline:

sha256 = "$swupdate_get_sha256(core-image-full-cmdline-machine.ubifs)";

The name of the file must be the same as in deploy directory.

BitBake variable expansion in sw-description

To insert the value of a BitBake variable into the update file, pre- and postfix the variable name with “@@”. For example, to automatically set the version tag:

version = "@@DISTRO_VERSION@@";

Automatic versions in sw-description

By setting the version tag in the update file to $swupdate_get_pkgvar(<package-name>) it is automatically replaced with PV from BitBake’s package-data-file for the package matching the name of the provided <package-name> tag. For example, to set the version tag to PV of package u-boot:

version = "$swupdate_get_pkgvar(u-boot)";

To automatically insert the value of a variable from BitBake’s package-data-file different to PV (e.g. PKGV) you can append the variable name to the tag: $swupdate_get_pkgvar(<package-name>@<package-data-variable>) For example, to set the version tag to PKGV of package u-boot:

version = "$swupdate_get_pkgvar(u-boot@PKGV)";

Using checksum for version

It is possible to use the hash of an artifact as the version in order to use “install-if-different”. This allows versionless artifacts to be skipped if the artifact in the update matches the currently installed artifact.

In order to use the hash as the version, the sha256 hash file placeholder described above in Automatic sha256 in sw-description must be used for version.

Each artifact must have the attribute:

version = "@artifact-file-name"

The name of the file must be the same as in deploy directory.

Template for recipe using the class

DESCRIPTION = "Example recipe generating SWU image"
SECTION = ""

LICENSE = ""

# Add all local files to be added to the SWU
# sw-description must always be in the list.
# You can extend with scripts or whatever you need
SRC_URI = " \
    file://sw-description \
    "

# images to build before building swupdate image
IMAGE_DEPENDS = "core-image-full-cmdline virtual/kernel"

# images and files that will be included in the .swu image
SWUPDATE_IMAGES = "core-image-full-cmdline uImage"

# a deployable image can have multiple format, choose one
SWUPDATE_IMAGES_FSTYPES[core-image-full-cmdline] = ".ubifs"
SWUPDATE_IMAGES_FSTYPES[uImage] = ".bin"

inherit swupdate

Simplified version for just image

In many cases there is a single image in the SWU. This is for example when just rootfs is updated. The generic case described above required an additional recipe that must be written and maintained. For this reason, a simplified version of the class is introduced that allowed to build the SWU from the image recipe.

Users just need to import the swupdate-image class. This already sets some variables. A sw-description must still be added into a files directory, that is automatically searched by the class. User still needs to set SWUPDATE_IMAGE_FSTYPES[your image] to the fstype that should be packed into the SWU - an error is raised if the flag is not set.

In the simple way, your recipe looks like

<your original recipe code>

SWUPDATE_IMAGES_FSTYPES[<name of your image>] = <fstype to be put into SWU>
inherit swupdate-image

What about grub ?

In order to use swupdate with grub, swupdate needs to be configured to use grub. Some of the imporatant configurations are CONFIG_GRUBENV_PATH=”/path/to/grubenv”, where “/path/to/grubenv” is thepath to grub environment. Example: “/boot/EFI/BOOT/grubenv”.

The grubenv file should be created using grub-editenv tool, because it is a 1024-byte file, therefore, any modification using nano or vim will only corrupt the file, and grub will not be able to use it.

You can create a grubenv file using these commands for instance:

GRUBENV="/path/to/grubenv"
grub-editenv $GRUBENV create
grub-editenv $GRUBENV set rootfs=2
grub-editenv $GRUBENV set kernel=2

grub-editenv is a tool that is integrated to yocto.

When the grubenv file is created, grub should be configured to use it. This configuration should be in the configuration file grub.cfg. Here is an example of grub.cfg that loads the environment file before booting:

# Take a kernel and a rootfs by default in case grubenv is corrupted
rootfs=1
kernel=1
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
default=boot
# set timeout to zero to boot without timeout
timeout=0
# load grubenv the environment file that contains the value of rootfs and kernel variables
load_env -f "/path/to/grubenv"
# detect which memory contains 5 partitions
for i in 1 2 3 4 5; do  if [ -d (hd${i},gpt5)/ ]; then drive=${i};fi ; done
# detect which rootfs should we boot with
if [ ${rootfs} = "1" ]; then rootfs_part=4 ; elif [ ${rootfs} = "2" ]; then rootfs_part=5 ; fi
# detect which kernel should we boot with
if [ ${kernel} = "1" ]; then kernel_part="(hd${drive},gpt2)" ; elif [ ${kernel} = "2" ]; then kernel_part="(hd${drive},gpt3)" ; fi

# The menuentry that is used to boot (more can be added if it is wanted)
menuentry 'boot'{
linux ${kernel_part}/bzImage root=/dev/mmcblk1p${rootfs_part} rw rootwait quiet console=ttyS2,115200 console=tty0 panic=5
}

The grub.cfg above is merely an example, and can be modified as the user wants to, as long as it loads the environment variables,and it boots correctly using these environment variables.