Mender blog

Using build information from Yocto to deploy software updates (part 1)

When designing an embedded or IoT product, the problem of deploying software updates to the devices in the field quickly becomes a problem. The main drivers for having the ability to deploy updates are to fix bugs, security issues and add new features after the devices have left manufacturing. Not having a way to update the software or firmware puts companies at significant risk and competitive disadvantage.

In this post, we will look at some of the basic device information that needs to be in place to enable software updates.

Device types and software compatibility

As a company releases new versions of devices to the market, the hardware of the devices will change as hardware becomes more powerful, feature-rich and cheaper over time. This has great impact on the compatibility of the software running on the devices.

There could be several reasons why the hardware of two devices are incompatible and require separate software builds, and we will refer to them as different Device Types in this case. For example, the CPU architecture may be incompatible; e.g. ARM vs. Intel, or hardware floating point support may not be present. In other cases the device peripherals may be different; e.g. new network modules are added, which requires additional drivers. All these things have impact on the compatibility of the device software.

A common way to track these differences is with a "compatibility matrix", which maps which software releases a hardware is compatible with. An example is shown below.

Example Hardware-Software compatibility matrix

This is in many cases manually updated in a spreadsheet, which means that it tends to get inconsistent over time.

Obtaining the necessary information at the device

It is clear that if we can obtain the hardware 1) device type and 2) supported device type by the software update, we can check the compatibility and ensure that compatible software is being deployed to the device.

The device type is static information that will not change over the lifetime of the device. The supported device type can be included in the metadata of the software update itself, often referred to as the software manifest.

In our next post in this series, we look at how to obtain this information from Yocto, a project for creating embedded Linux builds, to detect compatibility in an automated way.

Recent articles

The scope of EU Cyber Resilience Act (CRA) compliance

The scope of EU Cyber Resilience Act (CRA) compliance

Explore the scope of the EU Cyber Resilience Act (CRA). Learn about the CRA's scope, and why secure OTA updates are essential for compliance.
An overview of EU Cyber Resilience Act (CRA) compliance

An overview of EU Cyber Resilience Act (CRA) compliance

Learn how the EU Cyber Resilience Act (CRA) enforces stringent cybersecurity requirements for PDEs. Explore compliance essentials in part 1 of a 4-part series.
Challenges in complying with the EU Cyber Resilience Act (CRA)

Challenges in complying with the EU Cyber Resilience Act (CRA)

Discover how manufacturers can achieve Cyber Resilience Act (CRA) compliance by tackling secure updates, SBOM management, and vulnerability tracking with robust OTA solutions.
View more articles

Learn why leading companies choose Mender

Discover how Mender empowers both you and your customers with secure and reliable over-the-air updates for IoT devices. Focus on your product, and benefit from specialized OTA expertise and best practices.

 
sales-pipeline_295756365