Software Updates on i.MX8MP, Part 2: Mender & Yocto Project

/in , , /by

Software over-the-air (OTA) updates are essential for any modern embedded Linux device. In part 1, we explored A/B software updates using RAUC and qbee.io. For our demonstrations, we utilized the new open source hardware Olimex’s iMX8MPlus System on Module (SOM) and Evaluation Board (EVB). The NXP i.MX8MP is a robust microprocessor, ideal for industrial-grade applications and widely adopted across various industries. In part 2, we will use Mender to update the same hardware.

About Mender

Mender.io is an open-source platform designed for managing and deploying over-the-air (OTA) updates to embedded devices. It provides a reliable and secure method to keep devices up-to-date, minimizing downtime and reducing the risks of manual updates. Mender supports an open-source A/B update scheme and offers an optional proprietary implementation for delta updates.

As a turnkey solution, Mender features a web interface for comprehensive device management and is available as a Software-as-a-Service (SaaS) for small and medium businesses, as well as hosted or on-premise solutions for large enterprises. It supports robust update strategies, rollback mechanisms, and add-ons for configuring, monitoring, and troubleshooting devices. Mender is a state-of-the-art solution for maintaining and managing fleets of connected devices across various industries.

Building an Image with Mender

Here are the steps to build core-image-base with Mender for Olimex:

  • Install the kas tool (optional: to install it globally for all users, run the installation as root or using sudo):
pip install kas
  • Clone meta-mender-community git repository for Yocto LTS release 5.0 (scarthgap):
git clone -b scarthgap https://github.com/mendersoftware/meta-mender-community
  • Create a build directory and navigate into it:
mkdir -p meta-mender-community/mender-nxp && cd meta-mender-community/mender-nxp
  • Create a kas configuration add-on to enable passwordless root access for development purposes:
cat <<EOF > debug-image.yml
header:
  version: 14

local_conf_header:
  developer-features: |
    EXTRA_IMAGE_FEATURES = "debug-tweaks"
EOF
  • Run the following command to start the build process:
kas build ../kas/olimex-imx8mp-evb.yml:debug-image.yml

Initiating the build process from scratch is a bit of a marathon, as kas and bitbake need to download all the source code and execute a plethora of tasks. Feel free to grab a cup of tea (or maybe a whole teapot) while you wait!

Flashing the Mender Image

Using kas and BitBake will result in the production of an image file. After the build process is complete, you will find the generated image at the following relative path: build/tmp/deploy/images/olimex-imx8mp-evb/core-image-base-olimex-imx8mp-evb.sdimg. This path indicates the location within the build directory where the final image is stored, ready for deployment to Olimex iMX8MP-SOM-4GB-IND and iMX8MP-SOM-EVB-IND.

The core-image-base-olimex-imx8mp-evb.sdimg file must be flashed onto a microSD card to be used with your device. This can be accomplished using various applications such as dd or bmaptool for command-line options. If you prefer a user-friendly application with a graphical interface, you can use Balena Etcher, which simplifies the flashing process and provides a straightforward GUI.

To set up and verify your Olimex iMX8MP-SOM-EVB-IND board, follow these steps:

  • Connect the USB-to-UART adapter to the A53_DBG1 connector on the Olimex iMX8MP-SOM-EVB-IND, and insert the Ethernet cable and the microSD card.

  • Plug the 5V power supply into the power jack of the iMX8MP-SOM-EVB-IND to power up the board.
  • Ensure the system boots successfully, then log in as the root user (no password required) and check the Mender status by executing the following commands:
mender-update show-provides
mender-update show-artifact
mender-update --version

Creating a Mender Artifact

A Mender artifact refers to a package format used by the Mender update manager for over-the-air (OTA) software updates. It contains all the necessary components such as firmware, scripts, configuration files, and metadata required to update a device’s software reliably and securely. The layer meta-mender/meta-mender-core is essential for integrating Mender’s functionality into the Yocto Project and OpenEmbedded build system as it provides required classes and scripts that automate the creation of Mender artifacts as part of the build process.

Follow the steps below to build a Mender Artifact for iMX8MP-SOM-EVB-IND that extends the system with the addition of the simple text editor nano:

  • Create a kas configuration add-on to add nano:
cat <<EOF > update-image.yml
header:
  version: 14

local_conf_header:
  update-image: |
    IMAGE_INSTALL:append = " nano"
EOF
  • Build both core-image-base and its corresponding Mender Artifact using:
kas build ../kas/olimex-imx8mp-evb.yml:debug-image.yml:update-image.yml
  • This process will generate a Mender Artifact containing nano at the file path build/tmp/deploy/images/olimex-imx8mp-evb/core-image-base-olimex-imx8mp-evb.mender.

Installing the Mender Artifact

Mender serves as a comprehensive update solution, featuring a central server that acts as a hub for storing and orchestrating software updates across fleets of devices via over-the-air deployment. Using Mender’s intuitive web UI or REST APIs, you can efficiently manage devices, upload software releases, and execute seamless deployments to distribute updates across your devices. Alternatively, Mender can operate in standalone mode, independent of a server.

To perform a manual standalone deployment using Mender in the terminal, follow the steps below. In this setup, no Mender Server is involved, and updates are initiated directly on the device.

  • Start a simple HTTP server in the directory with the Mender Artifact:
python3 -m http.server

mender-update install http://<server>:8000/core-image-base-olimex-imx8mp-evb.mender

NOTE: Replace <server> with the IP address of the machine on which the Python3 HTTP server is running.

  • Reboot the embedded Linux device:
reboot
  • Login as root on the board and verify that nano text editor has been installed.
  • Ensure the new deployment becomes permanent:
mender-update commit

This example illustrates the seamless integration of Mender using the Yocto Project release Scarthgap on an embedded computer powered by the NXP i.MX8MP SoC. It demonstrates how you can effectively manage updates across fleets of devices using the Mender server. Furthermore, Mender also provides additional tools for remote troubleshooting, ensuring smooth operations in the field.

How do Mender.io and RAUC differ?

The Mender client is an application that runs on embedded devices. In a production setup, it connects to the Mender server to perform automatic updates by downloading and installing Mender Artifacts as they become available. Initially, the Mender client was developed in Go. However, a strategic decision was made to rewrite it in C++ to reduce the application’s footprint and support more platforms, including real-time operating systems (RTOS).

In comparison, RAUC, the alternative A/B open-source solution explored in part one, also has an application running on the embedded Linux device, but it is written in C. Unlike Mender, RAUC does not provide a server to manage devices, so a third-party solution such as qbee.io or Eclipse hawkBit is required.

Another notable technical difference is that RAUC integration through meta-rauc-nxp relies on a wks file where the A and B partitions are explicitly specified. In contrast, meta-mender-nxp uses classes and special variables provided by Mender to define those partitions, and BitBake generates a temporary wks file while building Mender-enabled images.

In terms of security, both Mender and RAUC support signing and verification of updates. Mender supports signing artifacts using RSA with a recommended key length of at least 3072 bits or ECDSA with curve P-256. RAUC employs X.509 cryptography for signing and verifying update bundles.

Leveraging the insights and experiences discussed in parts 1 and 2 of this article, here is a side-by-side comparison of the key features of Mender and RAUC:

FeatureMenderRAUC
A/B updatesYesYes
Roll-backYesYes
Configure add-onAvailableNo
Monitor add-onAvailableNo
Troubleshoot add-onAvailableNo
Client implementationC++C
Client licenseApache 2.0LGPL-2.1
Yocto Project integrationYesYes
Management serverYes3rd-party

Mender.io provides a comprehensive, turnkey solution that covers everything from embedded devices to cloud-based software-as-a-service for managing fleets of connected devices. It also offers convenient add-ons and proprietary delta updates. Meanwhile, RAUC reliably integrates seamlessly with both in-house and third-party device management systems. The choice of update technology should be based on your specific requirements and use cases.

About Konsulko Group

Over the years, Konsulko engineers have made significant contributions to the community and crucial embedded Linux open-source projects, including the Yocto Project, OpenEmbedded, the Linux kernel, and U-Boot. We specialize in assisting customers in developing commercial products leveraging these technologies. With expertise in BSP bring-up on diverse hardware platforms for embedded devices, our services encompass a wide range of open-source solutions for software updates. Contact us to discuss the best update strategy and technology for your embedded product requirements.

Software Updates on the i.MX8MP, Part 1: qbee and RAUC

/in , , /by

Software over-the-air (OTA) updates are essential for embedded Linux devices as they ensure timely application of security patches, fix vulnerabilities, and enhance security features to protect against threats. They offer a convenient way to deliver new features, performance improvements, and bug fixes without needing physical access to the device, keeping it up-to-date and functional.

Several high-quality open-source OTA solutions are available today, allowing developers to leverage and customize existing systems rather than creating proprietary ones, saving both time and money. In this series of articles, we will explore and compare software update strategies using the A/B scheme, where two identical copies of the root filesystem are maintained, one active and one for the next update. Popular OTA update solutions like Mender, RAUC, and Swupdate implement this approach. This article will focus on RAUC using a typical development setup. In part 2 we will implement software updates with Mender. For our demonstration, we will use the i.MX8MP, a versatile microprocessor from NXP Semiconductors known for its industrial-grade reliability and popularity in smart home devices, industrial automation, medical equipment, and multimedia systems.

Recently, Olimex launched an open-source hardware iMX8MPlus System on Module (SOM) and Evaluation Board (EVB) tailored for industrial applications. Leon Anavi, Senior Engineer at Konsulko Group, contributed support for Olimex iMX8MP-SOM-4GB-IND and iMX8MP-SOM-EVB-IND to the community-maintained Yocto and OpenEmbedded BSP layers. This effort encompassed Linux kernel and U-Boot uplift. Subsequently, leveraging his role as founder and maintainer of the meta-rauc-community layer, Leon integrated support for RAUC software updates on these boards and seamlessly integrated them with qbee cloud service.

Qbee.io is a comprehensive cloud platform for managing and maintaining IoT and edge devices. Using the qbee-agent running on the embedded devices, it offers features such as configuration management, remote accesss, monitorning, security and OTA software updates based on RAUC. These capabilities enable businesses to efficiently oversee their distributed technology infrastructure, ensuring devices remain up-to-date, secure, and perform optimally. Earlier in 2024 Tim Orling, Konsulko Group Principal Software Engineer, implemented image update with qbee and RAUC on Raspberry Pi 5.

This technical article will guide you through the exacts steps to build a basic image for Olimex iMX8MP-SOM-4GB-IND and iMX8MP-SOM-EVB-IND using Yocto Project release 5.0 LTS (scarthgap) as well as to perform a software update using qbee and RAUC.

Building an Image

  • Download the long term support (LTS) release Scarthgap reference Yocto distribution, Poky:
git clone -b scarthgap https://git.yoctoproject.org/poky poky-olimex-imx8mp
cd poky-olimex-imx8mp
  • Download BSP layers:
git clone -b scarthgap https://github.com/Freescale/meta-freescale.git
git clone -b scarthgap https://github.com/Freescale/meta-freescale-3rdparty.git
git clone -b scarthgap https://github.com/Freescale/meta-freescale-distro.git
  • Download the meta-rauc layer:
git clone -b scarthgap https://github.com/rauc/meta-rauc.git
  • Download meta-rauc-community layers, including meta-rauc-nxp:
git clone -b scarthgap https://github.com/rauc/meta-rauc-community.git
  • Download layer providing the qbee-agent and qbee.io integration:
git clone -b master https://github.com/qbee-io/meta-qbee.git
  • Download the meta-openembedded layer as it provides a recipe for nano which will be used for the demonstration:
git clone -b scarthgap git://git.openembedded.org/meta-openembedded
  • Initialize the build environment:
source oe-init-build-env
  • Include all layers in conf/bblayers.conf:
bitbake-layers add-layer ../meta-openembedded/meta-oe
bitbake-layers add-layer ../meta-freescale
bitbake-layers add-layer ../meta-freescale-3rdparty
bitbake-layers add-layer ../meta-freescale-distro
bitbake-layers add-layer ../meta-rauc
bitbake-layers add-layer ../meta-rauc-community/meta-rauc-nxp
bitbake-layers add-layer ../meta-qbee/meta-qbee
  • Adjust conf/local.conf by appending the following configurations to the end of the file:
MACHINE = "olimex-imx8mp-evb"

INIT_MANAGER = "systemd"

ACCEPT_FSL_EULA = "1"

WKS_FILE = "dual-imx-boot-bootpart.wks.in"
DISTRO_FEATURES:append = " rauc"
IMAGE_FSTYPES:append = " ext4"
IMAGE_BOOT_FILES:append = " boot.scr"

IMAGE_INSTALL:append = " rauc-grow-data-part"
  • Visit qbee.io, register and sign in
  • Click on your profile name at the top right corner and select Bootstrap keys.
  • Copy the key.
  • Replace <bootstrap_key> with the qbee bootstrap key and append to conf/local.conf:
QBEE_BOOTSTRAP_KEY = "<bootstrap_key>"
  • Build an image:
bitbake core-image-base

Creating an image from the ground up is a time-consuming process that requires numerous Yocto/OpenEmbedded recipes and configurations. Please be patient as bitbake systematically manages each step.

  • Flash tmp/deploy/images/olimex-imx8mp-evb/core-image-base-olimex-imx8mp-evb.rootfs.wic.gz to microSD card.
  • Attach the USB-to-UART adapter to connector A53_DBG1 Olimex iMX8MP-SOM-EVB-IND, plug the ethernet cable and the microSD card.
  • Plug 5V power supply to the power jack on iMX8MP-SOM-EVB-IND to turn on the board.
  • Verify that the system boots successfully, log in as user root without a password and check RAUC status:
  • Visit qbee.io, click Devices and verify that olimex-imx8mp-evb has successfully connected:

Creating a RAUC Update Bundle

A RAUC update bundle comprises the file system image(s) or archive(s) designated for system installation, accompanied by a manifest detailing the images for installation, encompassing options and meta-information. Additionally, it may include scripts designated for execution before, during or after the installation process. To sign and verify the update bundles RAUC uses SSL keys. Layer meta-rauc-beaglebone contains a keyring containing all keys and a recipe for a simple RAUC update bundle for demonstration purposes only.

Follow the steps below to create RAUC update bundle that extends the system by adding the popular text based editor nano:

  • Add to conf/local.conf:
IMAGE_INSTALL:append = " nano"
  • Build the RAUC update bundle:
bitbake update-bundle

Running RAUC Update from qbee.io

Please follow the steps below to upload the RAUC bundle to qbee.io and update the board:

  • Visit qbee.io, click File Manager and upload the RAUC bundle:
  • Select Devices, click on olimex-imx8mp-evb and go to tab Configure. From Settings > OTA enable RAUC image updates:
  • Select the RAUC bundle.
  • Click Save Changes, then click Commit Changes and enter a commit message:
  • Wait for the qbee agent to apply the RAUC update bundle. By default, the agent checks for changes every 5 minutes. To force an immediate check, click the Run agent button in the Device Overview. Allow a few minutes for the update bundle to be transferred and installed on the board.
  • After the update is finished, the board will automatically restart. You can verify that the active RAUC rootfs slot has been updated and nano is present:
  • To optionally verify the update of the embedded Linux device from the cloud service, select Devices, click on olimex-imx8mp-evb, navigate to the Logs tab, and review the logs related to the RAUC update.

With qbee.io, multiple IoT devices can be grouped together and managed as a fleet from the cloud service. In practical product development scenarios, enhancing the Yocto Project and OpenEmbedded workflow can be achieved through a few straightforward commands to streamline continuous integration (CI).

The second part of the article will detail the exact steps to build, boot, and update an image on the Olimex iMX8MP-SOM-4GB-IND and iMX8MP-SOM-EVB-IND hardware, this time using Mender instead of RAUC, with the Yocto Project release 5.0 LTS (scarthgap).

Konsulko engineers have played pivotal roles as contributors and mentors in the commercial product space from the early days of OpenEmbedded and the Yocto Project. Our team excels in utilizing RAUC, Mender, Swupdate and a range of other open-source tools to deliver comprehensive software update solutions. Contact us to discuss your specific product requirements and discover how Konsulko engineers can improve your embedded Linux development projects.

Build an image and perform updates with RAUC on Rockchip

/in , /by

Over the years Konsulko Group engineers made many upstream contributions to various open source OTA (over-the-air) update solutions for embedded Linux devices. Recently Leon Anavi, Konsulko Group Senior Engineer and maintainer of meta-rauc-community ported RAUC to Radxa Rock Pi 4 Model B. This is the first Rockchip device supported in meta-rauc-community.

RAUC is one of the popular solutions that provide OTA updates for Embedded Linux devices. RAUC is developed with focus on stability, security and flexibility and is compatible with all popular build systems.

The Radxa Rock Pi 4 Model B is a single-board computer with a Rockchip RK3399 processor, 4GB RAM, and various storage options including microSD card and NVMe SSD. It features Gigabit Ethernet, dual-band Wi-Fi, Bluetooth 5.0, USB 3.0, 4K video output via HDMI and USB-C, and a 40-pin GPIO header compatible with Raspberry Pi. This article explains how to build an image for the Radxa Rock Pi 4 Model B using the Yocto Project and OpenEmbedded, and how to perform software updates with RAUC.

Building an Image

  • Download the long term support (LTS) release Scarthgap reference Yocto distribution, Poky:
git clone -b scarthgap https://git.yoctoproject.org/poky poky-rauc-rockchip
cd poky-rauc-rockchip
  • Download the meta-arm BSP layer:
git clone -b scarthgap git://git.yoctoproject.org/meta-arm
  • Download the meta-rockchip BSP layer:
git clone -b scarthgap git://git.yoctoproject.org/meta-rockchip
  • Download the meta-rauc layer:
git clone -b scarthgap https://github.com/rauc/meta-rauc.git
  • Download meta-rauc-community layers, including meta-rauc-rockchip:
git clone -b scarthgap https://github.com/rauc/meta-rauc-community.git
  • Download the meta-openembedded layer as it provides a recipe for nano which will be used for the demonstration:
git clone -b scarthgap git://git.openembedded.org/meta-openembedded
  • Initialize the build environment:
source oe-init-build-env
  • Include all layers in conf/bblayers.conf:
bitbake-layers add-layer ../meta-arm/meta-arm-toolchain
bitbake-layers add-layer ../meta-arm/meta-arm
bitbake-layers add-layer ../meta-rockchip
bitbake-layers add-layer ../meta-openembedded/meta-oe
bitbake-layers add-layer ../meta-rauc
bitbake-layers add-layer ../meta-rauc-community/meta-rauc-rockchip
  • Adjust conf/local.conf by appending the following configurations to the end of the file:
MACHINE = "rock-pi-4b"

SERIAL_CONSOLES="115200;ttyS2"
IMAGE_FSTYPES:append = " ext4"
WKS_FILE = "rockchip-dual.wks.in"
MACHINE_FEATURES:append = " rk-u-boot-env"
UBOOT_EXTLINUX_KERNEL_IMAGE="/${KERNEL_IMAGETYPE}"
UBOOT_EXTLINUX_ROOT="root=PARTLABEL=${bootpart}"
UBOOT_EXTLINUX_KERNEL_ARGS = "rootwait rw rootfstype=ext4 rauc.slot=${raucslot}"
WIC_CREATE_EXTRA_ARGS = "--no-fstab-update"

DISTRO_FEATURES:append = " rauc"

INIT_MANAGER = "systemd"
  • Build the image:
bitbake core-image-base

Building an image from scratch is a lengthy process that involves numerous Yocto/OpenEmbedded recipes and configurations. Please be patient while bitbake methodically handles each task.

  • Flash tmp/deploy/images/rock-pi-4b/core-image-base-rock-pi-4b.rootfs.wic to microSD card.
  • Attach the USB-to-UART adapter to Raxda Rock Pi 4 Model B, plug the ethernet cable and the microSD card.
  • Plug USB-C power supply.
  • Verify that the system boots successfully, log in as user root without a password and check RAUC status:
rauc status

Creating a RAUC Update Bundle

A RAUC update bundle comprises the file system image(s) or archive(s) designated for system installation, accompanied by a manifest detailing the images for installation, encompassing options and meta-information. Additionally, it may include scripts designated for execution before, during or after the installation process. To sign and verify the update bundles RAUC uses SSL keys. Layer meta-rauc-beaglebone contains a keyring containing all keys and a recipe for a simple RAUC update bundle for demonstration purposes only.

Follow the steps below to create RAUC update bundle that extends the system by adding the popular text based editor nano:

  • Add to conf/local.conf:
IMAGE_INSTALL:append = " nano"
  • Build the RAUC update bundle:
bitbake update-bundle

Updating Radxa Rock with RAUC

Follow the steps below to update core-image-minimal running from a microSD card on Radxa Rock Pi 4 Model B:

  • Start a Python 3 web server on the build machine or another computer where the RAUC update bundle (aka update-bundle-rock-pi-4b.raucb) is available and within the same network as Radxa Rock Pi 4 Model B, for example:
cd tmp/deploy/images/rock-pi-4b/
pip3 install --user rangehttpserver
python3 -m RangeHTTPServer
  • On Radxa Rock Pi 4 Model B replace <IP> with the actual IP address of the computer on which the HTTP server is running and execute the following command to install the update:
rauc install http://<IP>:8000/update-bundle-rock-pi-4b.raucb

NOTE: As alternative, instead of using an HTTP server, you can transfer the update bundle to Rock Pi 4 Model B and install it from local storage.

  • Reboot Radxa Rock Pi 4 Model B Black to load the updated version:
reboot
  • Verify that the system boots and nano was added:
which nano

Check RAUC status to confirm the system have booted from the second partition:

rauc status

How Does It Work?

The default serial baud rate for the Radxa Rock Pi 4’s U-Boot and kernel console is 1500000. However, many USB-to-UART cables, such as those using the popular Silicon Labs CP2102 chip, cannot handle this high speed. To avoid these issues, a patch is applied to rock-pi-4-rk3399_defconfig through u-boot_%.bbappend, setting U-Boot’s baud rate to 115200. Additionally, for the kernel, we set SERIAL_CONSOLES="115200;ttyS2" in conf/local.conf. This ensures that both U-Boot and the Linux kernel operate at a baud rate of 115200 in our demonstration.

The Radxa Rock Pi 4 Model B uses U-Boot with extlinux support to boot. For RAUC integration, it employs a boot.scr script, which handles the A/B system switching and passes environment variables to extlinux/extlinux.conf. The rockchip-dual.wks.in file creates two identical partitions (A and B), a data partition, and a fixed-size 32MB boot partition. The boot.scr and extlinux/extlinux.conf files are stored in the boot partition.

In real-world product development, the Yocto Project and OpenEmbedded workflow can be improved with some simple commands to facilitate continuous integration (CI).

Since OpenEmbedded and the Yocto Project began, Konsulko engineers have been key contributors and mentors in developing commercial products. Our team excels in using RAUC, Mender, and other open-source tools for delivering superior software updates. Reach out to us to see how Konsulko engineers can support your embedded product development efforts.

Porting Mender to Raspberry Pi 5 and Yocto Project Scarthgap

/in , , /by

Overview

Mender is an open-source over-the-air (OTA) software update technology for embedded Linux devices and Internet of Things (IoT) ecosystem. It allows developers to remotely manage and update software on embedded Linux devices, ensuring that they remain secure, up-to-date, and functional throughout their lifecycle. Mender simplifies the process of launching a new project by offering official and community-supported board integrations for a wide range of devices and operating systems. These integrations include support for Debian family and the Yocto Project, making it easier for developers to get started with their projects seamlessly.

The Yocto Project is an open-source collaboration project by the Linux Foundation to create custom Linux-based systems for embedded devices. It uses the OpenEmbedded build automation framework with the build tool bitbake and provides Poky as a reference Linux distribution. The Yocto Project follows a regular release cycle, typically with a new version every six months, alongside long-term supported releases available every two years. Currently, the most recent LTS release is version 5.0, codenamed Scarthgap, which became available on April 30, 2024.

Recently, Senior Engineer Leon Anavi from Konsulko Group ported Mender to Raspberry Pi 5. This effort builds upon his previous contributions, where he added Raspberry Pi 5 support to the Yocto Project BSP (Board Support Package) layer meta-raspberrypi. This progress was made possible through sponsorship from the computer emergency response team of the Government of the Grand Duchy of Luxembourg (GOVCERT.LU). If you’re considering using Mender on Raspberry Pi or any other hardware platform for your embedded product needs, feel free to reach out to us to discuss further.

Raspberry Pi 5 introduces significant hardware differences compared to its predecessors. To enable Mender updates on this platform, we require U-Boot version v2024.04 or later. Unfortunately, the Yocto Project release Scarphgap ships with U-Boot version v2024.01, which isn’t compatible. To address this compatibility issue and obtain the necessary U-Boot version, our setup utilizes the scarthgap/u-boot branch from the meta-lts-mixins layer. Tim Orling, Principal Software Engineer at Konsulko Group, contributed the patches in meta-lts-mixins for U-Boot v2024.04.

Raspberry Pi 5 is the first model of the famous single board computers that features a dedicated UART connector is a three-pin header compatible with the Raspberry Pi Debug Connector specification. It can be used with Raspberry Pi Debug Probe, a USB device that provides both a UART serial port and a standard Arm Serial Wire Debug (SWD) interface.

The article offers a practical guide, outlining the exact steps to build a Mender-enabled image for Raspberry Pi 5 and execute an A/B update. To streamline the build setup, we’ll utilize KAS. This Python-based open-source tool effectively handles various Yocto/OpenEmbedded layers. KAS executes builds within a Docker container to ensure consistency and reliable build outcomes, regardless of the primary GNU/Linux distribution on the build machine.

Image for Raspberry Pi 5

Follow the steps below to build core-image-minimal with Mender for Raspberry Pi 5:

  • Install the kas tool (optionally, you can install globally for all users. Run as root, respectively under sudo then):
pip install kas
  • Clone this repository:
git clone -b scarthgap https://github.com/mendersoftware/meta-mender-community
  • Create a build directory and change into it:
mkdir -p meta-mender-community/mender-rpi5 && cd meta-mender-community/mender-rpi5
  • Use kas to build for the Raspberry Pi 5:
kas build ../kas/raspberrypi5.yml
  • Flash tmp/deploy/images/raspberrypi5/core-image-minimal-raspberrypi5.sdimg to a microSD card and boot it on Raspberry Pi 5.

Mender Artifact for Raspberry Pi 5

Follow the steps below to build a Mender Artifact for Raspberry Pi 5 that provides the simple text editor nano:

  • Enter KAS shell:
kas shell ../kas/raspberrypi5.yml
  • Append to the end of conf/local.conf:
IMAGE_INSTALL:append = " nano"
  • Build both core-image-minimal and a Mender Artifact for it:
bitbake core-image-minimal
  • As a result Mender Artifact containg nano will be generated as file tmp/deploy/images/raspberrypi5/core-image-minimal-raspberrypi5.mender

Update Raspberry Pi 5

As an end to end update solution, Mender provides aserver as the central hub for storing and orchestrating software updates across fleets of devices through over-the-air deployment. Through Mender’s user-friendly web UI or REST APIs, you can easily oversee device management, upload software releases, and create seamless deployments to distribute updates to your devices. However, it is also possible to use Mender in standalone mode without a server.

Follow the steps below to manually perform a standalone deployment with Mender in the terminal. In this scenario, no Mender Server is utilized, and the deployments are triggered directly at the device.

  • Start a simple HTTP server in the directory with the Mender Artifact:
python3 -m http.server
  • Login as root on Raspberry Pi 5 and install the Mender Artifact to perform an upgrade of the device:
mender-update install http://<server>:8000/core-image-minimal-raspberrypi5.mender

NOTE: Replace <server> with the IP address of the machine on which the Python3 HTTP server is running.

  • Reboot Raspberry Pi 5:
reboot
  • Login as root on Raspberry Pi 5 and verify that nano text editor has been installed.
  • Make the deployment permanent:
mender-update commit

This straightforward example showcases the seamless integration of Mender with Raspberry Pi 5 using the Yocto Project release Scarthgap. You can follow up and manage updates of fleets of Raspberry Pi 5 devices through the Mender server. Additionally, Mender offers convenient add-ons for remote troubleshooting, ensuring smooth operations in the field.

Since the earliest days of the OpenEmbedded build framework and the Yocto Project, Konsulko engineers have been active contributors to the community, aiding customers in crafting commercial products using these technologies. Our expertise extends beyond Mender, encompassing various open-source solutions for software updates. Feel free to get in touch to explore how we can assist with your embedded product requirements.

Integrating RAUC with Yocto Project on BeagleBone Black

/in , , /by

Konsulko Group has made many upstream contributions to OTA (over-the-air) update solutions for embedded Linux devices. RAUC is a popular open source option as it has been meticulously developed with a keen emphasis on stability, security, and adaptability. Notably, RAUC seamlessly integrates with major build systems such as Yocto Project/OpenEmbedded, Buildroot, and PTXdist.

Functioning across diverse usage scenarios, one of RAUC’s elementary yet impactful functionalities is the A/B update mechanism. In this setup, two identical root filesystems, denoted as A and B, are maintained. The device boots from one of these, while the other serves as the target for updates.

Post-update completion, the bootloader directs the system to boot from the freshly updated partition during the subsequent system startup. RAUC incorporates the ‘verity’ update bundle format. It extends the capabilities of RAUC by introducing built-in support for HTTP(S) network streaming, adaptive delta-like updates, and comprehensive update bundle encryption.

In previous blog posts, Konsulko Group engineers have demonstrated RAUC on Raspberry Pi and NXP devices such as SolidRun Cubox-i and HummingBoard. Recently Leon Anavi, Konsulko Group Senior Engineer and maintainer of meta-rauc-community ported RAUC to BeagleBone Black.

This article provides, as an example, the exact steps how to integrate RAUC with Yocto Project and OpenEmbedded for booting from a microSD card on BeagleBone Black.

Released in 2013, BeagleBone Black is a single-board computer (SBC) developed by the BeagleBoard.org Foundation. It was certified by the Open Source Hardware Association with OSHWA UID US000236. The chipset on BeagleBone Black is Texas Instruments Sitara AM3358 with 1GHz ARM Cortex-A8 CPU and SGX 3D graphics engine. Because of this the demonstrated integration is a suitable reference for other embedded devices equipped Texas Instruments chipsets.

Required Hardware

The hardware used for this step by step tutorial is:

Building a Linux Distribution with RAUC

RAUC, a robust and powerful open-source solution, demands advanced skills for initial integration. In general, to incorporate RAUC in a Yocto Project and OpenEmbedded image for BeagleBone Black the following actions have to be performed:

  • Use U-Boot as a bootloader
  • Enable SquashFS in the Linux kernel configuration
  • Use ext4 root file system
  • Design specific storage partitioning for the certain use case and configure RAUC accordingly
  • Provide a custom U-Boot script to properly switch between RAUC slots
  • Prepare a certificate and keyring to use for signing and verifying RAUC update bundles.

Leon Anavi has already done all these actions for core-image-minimal in Yocto/OpenEmbedded layer meta-rauc-community/meta-rauc-beaglebone. The layer is available at GitHub. Please follow the steps below to build core-image-minimal for BeagleBone Black with it:

  • Download the long term support (LTS) release Kirkstone reference Yocto distribution, Poky:
git clone -b kirkstone https://git.yoctoproject.org/poky poky-rauc-bbb
cd poky-rauc-bbb
  • Download the meta-rauc layer:
git clone -b kirkstone https://github.com/rauc/meta-rauc.git
  • Download meta-rauc-community layers, including meta-rauc-beaglebone:
git clone -b kirkstone https://github.com/rauc/meta-rauc-community.git
  • Download the meta-openembedded layer as it provides a recipe for nano which will be used for the demonstration:
git clone -b kirkstone git://git.openembedded.org/meta-openembedded

Initialize the build environment:

source oe-init-build-env
  • Include all layers in conf/bblayers.conf:
bitbake-layers add-layer ../meta-openembedded/meta-oe
bitbake-layers add-layer ../meta-rauc
bitbake-layers add-layer ../meta-rauc-community/meta-rauc-beaglebone
  • Adjust conf/local.conf by appending the following configurations to the end of the file:
MACHINE = "beaglebone-yocto"

# Use systemd as init manager
INIT_MANAGER = "systemd"

# Add RAUC to the image
IMAGE_INSTALL:append = " rauc"
DISTRO_FEATURES:append = " rauc"
  • Build a minimal bootable image:
bitbake core-image-minimal

The image creation process from scratch is time-consuming, encompassing various Yocto/OpenEmbedded recipes and configurations. Kindly await completion as bitbake diligently executes each tasks.

  • Flash tmp/deploy/images/beaglebone-yocto/core-image-minimal-beaglebone-yocto.wic.xz to microSD card.
  • Attach the USB-to-UART adapter to BeagleBone Black, plug the ethernet cable and the microSD card.

Press and hold button S2 while plugging in the 5V DC power supply to turn on BeagleBone Black and boot from microSD card.

BeagleBone black board has an onboard button labeled as S2. It is situated near the microSD card slot. Press and hold it while powering the board to boot from microSD card.

  • Verify that the system boots successfully, log in as user root without a password and check RAUC status:
rauc status

On the screenshot BeagleBone Black has been booted from RAUC slot rootfs.0 (A) on the microSD card.

NOTE: The meta-rauc-beaglebone layer includes a core-image-minimal.bbappend file, housing essential configurations for RAUC functionality. Apply these configurations similarly to other images intended for use in your embedded Linux device.

Creating a RAUC Update Bundle

A RAUC update bundle comprises the file system image(s) or archive(s) designated for system installation, accompanied by a manifest detailing the images for installation, encompassing options and meta-information. Additionally, it may include scripts designated for execution before, during or after the installation process. To sign and verify the update bundles RAUC uses SSL keys. Layer meta-rauc-beaglebone contains a keyring containing all keys and a recipe for a simple RAUC update bundle for demonstration purposes only.

Follow the steps below to create RAUC update bundle that extends the system by adding the popular text based editor nano:

  • Add to conf/local.conf:
IMAGE_INSTALL:append = " nano"
  • Build the RAUC update bundle:
bitbake update-bundle

Following a successful execution, bitbake will produce the update-bundle-beaglebone-yocto.raucb file.

Updating BeagleBone Black with RAUC

Follow the steps below to update core-image-minimal running from a microSD card on BeagleBone Black:

  • Start a Python 3 web server on the build machine or another computer where the RAUC update bundle (aka update-bundle-beaglebone-yocto.raucb) is available and within the same network as BeagleBone Black, for example:
cd tmp/deploy/images/beaglebone-yocto/
pip3 install --user rangehttpserver
python3 -m RangeHTTPServer
  • On BeagleBone Black replace <IP> with the actual IP address of the computer on which the HTTP server is running and execute the following command to install the update:
rauc install http://<IP>:8000/update-bundle-beaglebone-yocto.raucb

The screenshot show successful installation of the RAUC updated bundle on BeagleBone Black.

  • Reboot BeagleBone Black to load the updated version:
reboot

NOTE: As alternative, instead of using an HTTP server, you can transfer the update bundle to BeagleBone Black and install it from local storage.

  • Verify that nano was added to the system:
which nano
  • Check RAUC status to confirm the system have booted from the second partition:
rauc status

On the screenshot, after sucessful installation of the RAUC update bundle, BeagleBone Black has been booted from RAUC slot rootfs.1 (B) on the microSD card. This slot contains nano.

In real-world product development, the Yocto Project and OpenEmbedded workflow can be enhanced with a few commands for easy implementation of continuous integration (CI).

From the dawn of OpenEmbedded and the Yocto Project, Konsulko engineers have been community contributors and guides for crafting commercial products. Our expertise spans RAUC, Mender, and various open-source solutions for top-notch software updates. Please get in touch with us to discuss how Konsulko engineers can help your own embedded product development.

Mender Add-ons: Remote Troubleshooting Devices in the Field

/in , , /by

(This article was written by open source software enthusiast and Konsulko Group intern Atanas Bunchev, working with Konsulko Senior Engineer Leon Anavi.)

Konsulko Group often works with Mender.io to provide secure, risk tolerant and efficient Over-The-Air updates for any software on an embedded device. This includes both solutions for robust system updates as well as updates of single applications. Mender is compatible with any Linux based OS, including popular build systems such as Yocto Project/OpenEmbedded, Buildroot and OpenWrt.

Aside from OTA updates Mender also offers several add-ons. These are optional extensions that provide functionality for use cases beyond the core OTA updates features.

One such use case is remote troubleshooting. In practice deployed devices in the field are often hard to reach or retrieve. Troubleshooting individual devices becomes resource inefficient and in some cases they have to be replaced even when it’s just a small software or configuration issue. Our experience has shown in these situations Mender’s Add-ons have proven to be extremely useful.

This article provides as an example, the exact steps how to integrate Mender with The Yocto Project and OpenEmbedded for SolidRun CuBox-I and HummingBoard as well as a demonstration of the Mender Troubleshooting package, more specifically the File Transfer and Remote Terminal Add-ons. With the File Transfer add-on files can be downloaded and uploaded to any accepted device. Remote Terminal add-on allows remote interactive command execution from the Mender UI.

These add-ons are very valuable for system administration and mantainance of Internet of Things or fleets of connected industrial devices. For an example, we will troubleshoot an embedded Linux device remotely with systemd using Mender add-ons. We will upload tools to gather system boot-up performance statistics, run them on the device thanks to the Remote Terminal and download logs for further debugging.

Any Mender enabled device is suitable for this demonstration. Recently the Konsulko Senior Engineer Leon Anavi ported Mender to SolidRun CuBox-I and HummingBoard with NXP i.MX6 SoC so our current setup is based on this hardware platform and Yocto LTS release Kirkstone. Earlier we also ported RAUC, an alternative free and open source OTA update platform to the same hardware. If you are interested in software updates, please contact us to discuss your own embedded product needs in details. The hardware used in this example is:

  • HummingBoard Pro board
  • 32GB microSD card
  • Generic RJ45 network cable with Internet connection
  • Optionally UART to USB adapter for debugging the setup section

Building a Linux Distribution with Yocto/OpenEmbedded

The Mender Community provides a set of examples for integration with various hardware platforms using Yocto/OpenEmbedded in the meta-mender-community repository. Sub-layer meta-mender-nxp in this repository contains the integration for Cubox-I/HummingBoard.

The meta-mender-nxp layer uses Google Repo to provide easy and simple setup and build process for the examples:

$ mkdir mender-nxp && cd mender-nxp
$ repo init -u https://github.com/mendersoftware/meta-mender-community \
            -m meta-mender-nxp/scripts/manifest-nxp.xml \
            -b kirkstone
$ repo sync
$ source setup-environment nxp

Board configuration

To configure the build system we have to append to conf/local.conf inside the build directory.

First we are going to set the build target machine:

MACHINE = "cubox-i"

Then we have to accept the end user agreement required by the BSP layer:

ACCEPT_FSL_EULA = "1"

Note: Usually to enable Mender’s Troubleshooting features we have to add mender-connect to IMAGE_INSTALL. In our case this is already added by the meta-mender-demo layer.

Mender configuration

We have to provide our device with MENDER_SERVER_URL and MENDER_TENANT_TOKEN.
For that reason we have to register at https://mender.io/.

Mender provides a free demo profile with limitation of 1 year and up to 10 devices which can be used to experiment with all of Mender’s features.

In fact, when sourcing the setup-environment script we get most of the mender-specific configuration appended to local.conf. This includes a description of how to get our tenant token:

# Build for Hosted Mender
#
# To get your tenant token:
#    - log in to https://hosted.mender.io
#    - click your email at the top right and then "My organization"
#    - press the "COPY TO CLIPBOARD"
#    - assign content of clipboard to MENDER_TENANT_TOKEN
#
#MENDER_SERVER_URL = "https://hosted.mender.io"
#MENDER_TENANT_TOKEN = ""

Note: If using the European server one has to set MENDER_SERVER_URL = "https://eu.hosted.mender.io"

Once we assign our tenant token and remove the # in front of MENDER_SERVER_URL and MENDER_TENANT_TOKEN we’re ready to build our system.

Building and flashing the system image to a microSD card

Build an example image with Yocto:

$ bitbake core-image-base

Building an image from scratch is a long process involving a lot of tasks. Please patiently wait until bitbake completes all tasks.

Once the build is complete flash the image to the microSD card (replace /dev/sdX with the proper device path) and boot it on the HummingBoard:

$ bmaptool copy tmp/deploy/images/cubox-i/core-image-base-cubox-i.sdimg.bz2 /dev/sdX
$ sync
$ eject /dev/sdX

Connecting to Mender

Once the board finishes booting it will poll the Mender server. By design the connection has to be established from the board to the server. Mender does not open any ports on the board to provide better security therefore the device has to initiate the connection.

When the connection is established the Mender control panel will indicate one pending device.

To accept the request click on View details under Pending devices.

Select the new device and press accept in the Authorization request section.

Once the connection is accepted head over to the Troubleshooting tab in the Device information section. Here you can launch a remote terminal and transfer files.

The next part of the article will demonstrate preparing, uploading and using systemd-analyze to fetch data about the boot process.

Preparing troubleshooting software

To compile systemd-analyze we have to add it to our image in conf/local.conf:

IMAGE_INSTALL:append = " systemd-analyze"

Rebuild systemd to get the systemd-analyze binary:

$ bitbake systemd -c compile
When using the do_compile command Yocto/OpenEmbedded will preserve the compiled binaries.

Find the systemd-analyze binary and libsystemd-shared-<version>.so shared library:

$ find tmp/work -name "systemd-analyze"
$ find tmp/work -name "libsystemd-shared*.so"

Note: As of the time of writing of this article these files should reside in locations similar to ./tmp/work/cortexa9t2hf-neon-poky-linux-gnueabi/systemd/1_250.5-r0/build/systemd-analyze and ./tmp/work/cortexa9t2hf-neon-poky-linux-gnueabi/systemd/1_250.5-r0/build/src/shared/libsystemd-shared-250.so. These paths depend on the exact version of systemd as well as the build configuration and may not be correct in your case.

Uploading the troubleshooting software

Upload these files to the board using Mender’s File Transfer utility:

  • systemd-analyze into /usr/bin/
  • libsystemd-shared-<version>.so into /usr/lib/

Fetching service initialization logs

Once the troubleshooting software is uploaded we can use the Remote Terminal to execute it.

Permit execution of the systemd-analyze binary:

# chmod +x /usr/bin/systemd-analyze

Check the time it took for the system to initialize:

# systemd-analyze

Export a graphic of all enabled services and the time they took to initialize:

# systemd-analyze plot > init.svg

Download init.svg:

This graphic shows that the device needs around a minute to reach multi-user.target. The longest task is the resizing of the /data partition that runs on first boot and the second longest is the filesystem check for mmcblk1p1 that runs every time the system boots.

Here is another graphic generated after a reboot:

This article demonstrates how to use Mender’s Remote terminal and File Transfer troubleshooting utilities to upload and execute the systemd-analyze binary to profile the initialization process of systemd services. These troubleshooting utilities can be used for variety of different tasks. After debugging a single device and finding an appropriate fix, Mender is capable of performing an A/B or delta software update to all devices or specific group of devices in the field.

Since the earliest days of the OpenEmbedded build framework and the Yocto Project, Konsulko engineers have been contributing to the community and helping customers build commercial products with these technologies. We have experience with RAUC, Mender and other open source solutions for software updates. Please contact us to discuss your own embedded product needs.

Setting up RAUC on CuBox-I/HummingBoard for Software Updates

/in , , /by

(This article was written by open source software enthusiast and Konsulko Group intern Atanas Bunchev, working with Konsulko Senior Engineer Leon Anavi.)

RAUC is one of the popular solutions that provide OTA (over-the-air) updates for Embedded Linux devices. RAUC is developed with focus on stability, security and flexibility and is compatible with all popular build systems: The Yocto Project/OpenEmbedded, Buildroot and PTXdist.

RAUC is capable of covering various use cases the most simple one being A/B updates.

The A/B updates scenario consists of having 2 identical root filesystems (named A and B), booting from one of them and performing the update on the other. After the update is complete the bootloader will boot from the updated partition on the next system boot. Recently the ‘verity’ update bundle format was introduced in RAUC. This new groundbreaking feature improves the verification process and most importantly allows extending RAUC by built-in HTTP(S) network streaming support, adaptive delta-like updates, and full update bundle encryption.

This article provides an example for setting up RAUC for A/B updates scenario on a HummingBoard board. The hardware used for the example is:

  • HummingBoard Pro board
  • 32GB microSD card
  • UART to USB adapter

RAUC is a robust, powerful and flexible open source solution that requires advanced skills for initial integration. To use RAUC in an image built with the Yocto Project and OpenEmbedded for CuBox-I/HummingBoard one needs to:

  • Use U-Boot as a bootloader
  • Enable SquashFS in the Linux kernel configuration
  • Use ext4 root file system
  • Design specific storage partitioning for the certain use case and configure RAUC accordingly
  • Provide a custom U-Boot script to properly switch between RAUC slots
  • Prepare a certificate and keyring to use for signing and verifying RAUC update bundles.

Building a Linux Distribution with RAUC

I’ve recently contributed to meta-rauc-community, a repository containing minimal RAUC example layers for Yocto/OpenEmbedded.

The following steps will show how to use the meta-rauc-nxp layer from that repository to build and update a minimal Linux distribution. The update will install nano (the text editor) to the system.

Download the reference Yocto distribution, Poky.
We’ll use the latest long term support version, kirkstone.

$ git clone -b kirkstone https://git.yoctoproject.org/poky
$ cd poky

Download meta-rauc-community layers (meta-rauc-nxp):

$ git clone https://github.com/rauc/meta-rauc-community.git

Download the meta-rauc layer:

$ git clone -b kirkstone https://github.com/rauc/meta-rauc.git

Download the BSP layers for cubox-i/HumminbBoard boards:

$ git clone -b kirkstone https://git.yoctoproject.org/meta-freescale
$ git clone -b kirkstone https://github.com/Freescale/meta-fsl-arm-extra.git

Download the meta-openembedded layer (provides nano):

$ git clone -b kirkstone git://git.openembedded.org/meta-openembedded

Initialize the build environment:

$ source oe-init-build-env

Add the layers to conf/bblayers.conf:

$ bitbake-layers add-layer ../meta-openembedded/meta-oe
$ bitbake-layers add-layer ../meta-rauc
$ bitbake-layers add-layer ../meta-freescale
$ bitbake-layers add-layer ../meta-fsl-arm-extra
$ bitbake-layers add-layer ../meta-rauc-community/meta-rauc-nxp

Adjust conf/local.conf by adding the following configurations to the end of the file:

# HummingBoard specifications are very similar to Cubox-I
MACHINE = "cubox-i"

# Accept end user agreement required by the BSP layer.
ACCEPT_FSL_EULA = "1"

# Use systemd as init manager
INIT_MANAGER = "systemd"

# Add RAUC to the image
IMAGE_INSTALL:append = " rauc"
DISTRO_FEATURES:append = " rauc"

# Generate ext4 image of the filesystem
IMAGE_FSTYPES:append = " ext4"

# Use the file containing the partition table specification
WKS_FILE = "sdimage-dual-cubox-i.wks.in"
WKS_FILES:prepend = "sdimage-dual-cubox-i.wks.in "

# Add 150 000 KBytes free space to the root filesystem
# (Adding software with updates require space.)
IMAGE_ROOTFS_EXTRA_SPACE:append = " + 150000"

# Add the boot script to the boot partition
IMAGE_BOOT_FILES:append = " boot.scr"

Note that whitespace inside quotes is intentional and important.

To sign and verify the update bundles RAUC uses SSL keys. A keyring containing all keys that will be used for update bundles needs to be installed on the target.

meta-rauc-community provides a script that would generate example keys and configure the current build environment accordingly. (The script has to be called after sourcing oe-init-build-env)

$ ../meta-rauc-community/create-example-keys.sh

Build a minimal bootable image:

$ bitbake core-image-minimal

Building an image from scratch is a long process involving a lot of tasks. Please patiently wait until bitbake completes all tasks.

It’s strongly recommended to zero-fill the u-boot environment sectors before flashing the image on the microSD card (replace /dev/sdX with the proper device path):

$ dd if=/dev/zero of=/dev/sdX seek=2032 count=16

After the build is done, flash the image to a microSD card (replace /dev/sdX with the proper device path) and boot it on the HummingBoard:

$ bmaptool copy tmp/deploy/images/cubox-i/core-image-minimal-cubox-i.wic.gz /dev/sdX
$ sync
$ eject /dev/sdX

Attach the USB-to-UART adapter to the HummingBoard Pro, plug the ethernet cable and the microSD card. Turn on the board to verify that the system boots successfully.

By default one can login as root without password.

Creating an update bundle for RAUC

After sourcing the oe-init-build-env, append the following line to the build configuration conf/local.conf to add nano to the system:

# Adding nano
IMAGE_INSTALL:append = " nano"

Build the RAUC update bundle:

$ bitbake update-bundle

Start a web server:

$ cd tmp/deploy/images/cubox-i/
$ pip3 install --user rangehttpserver
$ python3 -m RangeHTTPServer

Now you can install the bundle on the board, then reboot:

# rauc install http://192.168.1.2:8000/update-bundle-cubox-i.raucb
# reboot

One of the latest RAUC features is the verity bundle format. This format allows updates to be done without storing the whole bundle on the device in advance, which is useful for devices with limited space. One of the requirements for this feature is hosting the bundle on a server that supports HTTP Range Requests.

As alternative, you can transfer the bundle to the device and install it from local storage.

Verify that nano was added to the system:

# which nano

Check RAUC status to confirm the system have booted from the second partition:

# rauc status

For real-world products, this build procedure with the Yocto Project and OpenEmbedded can be optimized further with just a few commands for easy implementation of continuous integration (CI).

Since the earliest days of the OpenEmbedded build framework and Yocto Project, Konsulko engineers have been contributing to the community and helping customers build commercial products with these technologies. We have experience with RAUC, Mender and other open source solutions for software updates. Please contact us to discuss your own embedded product development.

Using kernel config fragments to remove an unwanted feature

/in , , , /by

Adding a feature to a linux-yocto based kernel is fairly well documented. This makes sense because it is the most common thing you might want to do: “My board needs support for this sensor added to our BSP.”

Konsulko Group recently helped a customer that had exactly the opposite problem, a standard feature in linux-intel (which includes linux-yocto.inc and inherits the kernel-yocto class) needed to be removed. The SoC (in the Intel™ “Bay Trail” family) and the off-the-shelf industrial PC had a problem. When USB 3.0 (xHCI) support is enabled, the default BIOS settings (xHCI Mode = Auto) would cause the system to lock-up upon either warm reboot or shutdown. Given that these systems are deeply embedded in the field—where simply “hooking up a display, keyboard and mouse” is cost prohibitive—we needed to find an option that would not prevent OTA updates.

You might think you could apply a patch via SRC_URI to kmeta (yocto-kernel-cache), but this isn’t supported in the Yocto Project kernel tooling. Instead we can apply kernel config fragments that disable the problematic xHCI feature. The trade off is that USB 3.x devices won’t be able to run at full speed, but the systems in question have no need for USB 3.0 (they are a classic IoT gateway use case).

Determining your existing kernel configuration

The first thing you want to do in this situation is determine what your (default) kernel configuration is. In our case, Konsulko and our customer are using the ‘dunfell’ (3.1.x) branch of meta-intel with MACHINE="intel-corei7-64". Upon building an image or the kernel (e.g. bitbake virtual/kernel or bitbake linux-intel), the kernel configuration can be found at the following path:

<build>tmp/work/corei7-64-intel-common-poky-linux/linux-intel/5.4.170+gitAUTOINC+98cce1c95f_36f93ff941-r0/linux-corei7-64-intel-common-standard-build/.config

Where the kernel version is 5.4.170, the (shortened) git commit hash of the kernel cache is 98cce1c95f and the (shortened) git commit hash of the kernel source is 36f93ff941.

Modifying the kernel configuration with menuconfig

The documented way to modify the kernel configuration is with:

bitbake -c menuconfig linux-intel

This approach works fine, but you must remember to copy the resulting .config to defconfig in your recipe’s SRC_URI.

Alternatively you can create your kernel config fragments in the kernel build directory and then add them to your kernel recipe. The fragments can be created with the help of the diffconfig script in the kernel source tree.

Also note that you must have already run:

$ bitbake -c kernel_configme -f linux-intel

or previously built the kernel in order for the .config to be present.

Modifying the kernel configuration with devtool

It will come as no surprise that my preferred way to modify the kernel configuration is to run:

$ devtool menuconfig linux-intel

But you will get an error:

ERROR: No recipe named 'linux-intel' in your workspace

So first we must get the kernel recipe into our workspace:

$ devtool modify linux-intel

Now we are able to run:

$ devtool menuconfig linux-intel

One benefit of this approach is that devtool will run the required steps that need to happen before menuconfig can be run (most notably the do_kernel_configme task).

Determining the changes needed

Regardless of which method you used to run menuconfig, you will now be presented with the text UI:

Since Konsulko and our customer already knew we needed to change the xHCI enablement, we can quickly </> for Search and then enter xHCI.

This gives us several results, but the ones that we care about have [=y](built-in) next to them:

  1. CONFIG_USB_XHCI_HCD
  2. CONFIG_USB_XHCI_PCI
  3. CONFIG_USB_XHCI_PLATFORM

The top level item that needs to be disabled (set to N) is CONFIG_USB_XHCI_HCD:

After this we can spot check the other values are also disabled (by using </> for Search again):
CONFIG_USB_XHCI_PCI and CONFIG_USB_XHCI_PLATFORM:

Satisfied that we have the needed change, we can save our configuration. Press the <E> key or click on < Exit > to exit the sub-menus until you are at the top of the stack. Press the <S> key or click on < Save > to save the configuration. At they prompt, press enter or click on <Yes>.

Now, the benefit of the devtool workflow comes into play, because we are rewarded with:

INFO: Updating config fragment <build>/workspace/sources/linux-intel/oe-local-files/devtool-fragment.cfg

The contents of this file are what you might expect:

# CONFIG_USB_XHCI_HCD is not set

Applying our configuration change

If we don’t already have one, we need a layer into which to put our changes:

$ bitbake-layers create-layer ~/Projects/meta-awesome-bsp

Add the layer to our active layers:

$ bitbake-layers add-layer ~/Projects/meta-awesome-bsp

Create a directory–following the pattern in openembedded-core–for our kernel changes:

$ mkdir -p ~/Projects/meta-awesome-bsp/recipes-kernel/linux

Finish our recipe:

$ devtool finish linux-intel ~/Projects/meta-awesome-bsp

Examine the resulting directory structure:

$ tree ~/Projects/meta-awesome-bsp
/home/<user>/Projects/meta-awesome-bsp
├── conf
│&nbsp;&nbsp; └── layer.conf
├── COPYING.MIT
├── README
├── recipes-example
│&nbsp;&nbsp; └── example
│&nbsp;&nbsp;     └── example_0.1.bb
└── recipes-kernel
    └── linux
        ├── linux-intel
        │&nbsp;&nbsp; └── devtool-fragment.cfg
        └── linux-intel_%.bbappend

Since this might not be the only change to the kernel we will need to make, let us give the fragment a better name:

pushd ~/Projects/meta-awesome/recipes-kernel/linux/linux-intel
mv devtool-fragment.cfg disable-xhci-hcd.cfg

And create an .scc file to give the Yocto Project kernel tooling better hints of how to apply our change:

cat << EOF >> disable-xhci-hcd.scc
# SPDX-License-Identifier: MIT
define KFEATURE_DESCRIPTION "Disable options for xhci (USB 3.0)"
define KFEATURE_COMPATIBILITY board

kconf hardware disable-xhci-hcd.cfg
EOF

And finally make changes to our linux-intel_%.bbappend to reflect these files:

$ cd ..
$ cat linux-intel_%.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += "\
    file://disable-xhci-hcd.cfg \
    file://disable-xhci-hcd.scc \
"

Now—as long as our layer has high enough priority and no other recipes add kernel config fragments which conflict with our change—we should be able to build the kernel and inspect the resulting .config:

$ popd
$ bitbake linux-intel
$ grep -R XHCI tmp/work/corei7-64-intel-common-poky-linux/linux-intel/5.4.170+gitAUTOINC+98cce1c95f_36f93ff941-r0/linux-corei7-64-intel-common-standard-build/.config
# CONFIG_USB_XHCI_HCD is not set
# CONFIG_USB_ROLES_INTEL_XHCI is not set

We should also be able to run dmesg | grep xhci on the target and we would not expect to see any messages.

Summary

A Konsulko Group customer had a hardware problem that required us to remove a kernel feature. By using tools like devtool, we were able to fairly easily make a change to the kernel configuration and capture those changes in a persistent way with a .cfg fragment and a .bbappend. This approach solved the problem and allowed OTA updates to proceed to these deeply embedded devices in the field. Please contact us to discuss how Konsulko can help you with the unique requirements of your commercial project.

Building Platforms with Secure Over-the-Air Updating

/in , , /by

Almost every device in development today requires both over-the-air (OTA) updating capabilities, and up-to-date security with authentication of the device filesystem and encryption of application data storage.

At Konsulko Group, we find that the best approach is to build a secure platform first, starting with the hardware root of trust and establishing a chain of trust by extending the root of trust through each successive component in the system.

  • A first step is to make sure the Universal Boot Loader (U-Boot) is up-to-date. If the device is using an older version, we may port U-Boot support of a more current release. Then we enable signature-based authentication of the device using the U-Boot verified boot feature.
  • To provide authentication of the device filesystem and encryption of application data storage, we often use the Linux kernel Device-Mapper infrastructure to create virtual layers of block devices: dm-verity for root filesystem authentication, dm-crypt for data encryption, and dm-integrity for read/write data volume integrity.
  • Finally, we can integrate Mender I/O support for OTA together with dm-verity and Yocto Project so that device updates can be performed while maintaining the system’s secure chain of trust.

This step-by-step methodology ensures straight-forward and predictable development. Please contact us to discuss how we can help you build a secure platform for OTA updating on your device.

How Mender works

/in , /by

by Tom Rini, VP Engineering

Software Update solutions are a key part of our services offering. For open source over-the-air updates, we often we recommend and work with mender.io. In fact, Konsulko Group is a Mender Authorized Referral Partner. Recently, a prospective customer expressed an interest in knowing more about how Mender works. Here’s the brief, informal introduction to member.io that I prepared, and now I’m sharing with you.

—

As a high level starting point, https://mender.io/how-it-works provides a good overview of what’s supported and what it covers. In short, Mender starts off by providing support for a traditional “A/B” approach to system updates, where if the update isn’t marked as valid (and there’s hooks for the application(s) to verify the system before this is done), it’s assumed invalid and the system will roll-back automatically. While “OTA” implies over the network, it can just as easily be done by providing (and validating) a USB key that contains an update.

One of the reasons we recommend Mender is that it has very good in-depth documentation. The starting point for all of that is https://docs.mender.io/2.4/ which covers all of the topic starting from how to implement Mender support in a device and including how to create your own server infrastructure if you don’t want to use their paid service. While there are a number of important pages there, one that I like to highlight is https://docs.mender.io/2.4/artifacts/state-scripts as it shows the state machine for an update and talks about some of the common use cases that come up for user interaction or dealing with failures.

Another place I want to call out is https://docs.mender.io/2.4/devices/update-modules which is also mentioned in the first link. This is how Mender is extended to provide updates for other parts of the system that are not the rootfs itself.  Since updating a Docker container is something that has been mentioned before I want to also note https://hub.mender.io/t/docker/324 as it is a well supported module for this specific case.

I hope you find this information useful. Please contact us if you have specific questions. We’re looking forward to talking to you about your own specific OTA needs.