When a device is in production and deployed in the field, or there is no access to the bootloader, the preferred method of updating the firmware is via a software update (SWU) package.

The software update package must be located in the root level of the update media. (Subfolders are not yet supported.)

SWU packages are containers that enclose all the required files and metadata to update device firmware. They provide different update strategies based on the package contents. The firmware update process with SWU packages is executed from the running system. This update mechanism can be triggered:

SWU packages include only one build artifact. Digi Embedded Yocto provides support to create SWU packages based on three different strategies depending on what to update and the mechanism you want to use:

The following table summarizes the main characteristics of each SWU package strategy:

SWU package strategy

Target device characteristics

SWU package features

Storage type

Boot strategy

File system access

Target partitions

Install script

Size

MMC

MTD

Single

Dual

R/W

R/O

linux

rootfs

data

System images

Files

[1]

[2]

[3]

Binary differences

[4]

1. Update of files happen over the active system on dual boot systems and active partition is not swapped.

2. Files can only be updated on read-write partitions, such as data.

3. Update can target files in the 'linux' partition, which is mounted in /mnt/linux/.

4. 'linux' partition is updated using a full system image.

See Include bootloader in SWU packages to learn how to include the bootloader as part of the update process for any SWU package.

Devices in the field can also be updated using system images, but this mechanism requires physical access to the device.

SWU packages based on system images

The SWU package strategy based on system images consists of updating the full system to ensure a fresh run after the update. In this case, the update package contains full system images resulting from the product build.

For dual boot systems, the update process is executed from the running system and the images are installed in the corresponding partitions of the inactive bank. For single boot systems, the update is executed from the recovery partition and the images are installed in the corresponding partitions.

The scenarios for using a SWU package based on system images include:

  • A new version of the operating system is released and the full system (kernel, device trees, and rootfs) must be updated.

  • The magnitude of the required changes in the system is large. In this case, a full system update is preferred over updating the changed files or performing an update based on differences.

Pros

  • Users have a fresh new system running after the update.

  • Supported in read-write and read-only systems.

  • For dual boot systems, the update is performed in the inactive bank, ensuring a booting system after the update.

Cons

  • The SWU package size can be very large compared to other update strategies.

  • User data outside of system partitions cannot be updated.

  • For single boot systems, the update can brick the device if the delivered images are not able to boot or power is lost during the process.

Refer to Create image-based SWU package to learn how to create this type of update package.

SWU packages based on files

The SWU package strategy based on files consists of updating only specific files and directories of the active system. In this case, the update package only contains the user-selected files and folders to update.

Since write access is required to install the new files, this strategy is not suitable for read-only systems. In these systems, you can only update resources in the data partition or you must provide a way to mount read-only partitions in read-write mode before the update starts.

For dual boot systems, the active bank does not change. Updates always happen on the running system.

The scenarios for using a SWU package based on files include:

  • A fix for a specific library or system component has been released and you want to incorporate it without performing a full system update. (This is applicable only to read-write systems; read-only systems require full system update or binary differences update.)

  • A user application in the data partition must be updated without changes in the rest of the system.

Pros

  • The SWU package size can be really small as only the files to update are delivered.

  • You can update other parts of the system such as user data.

Cons

  • System components cannot be updated in read-only systems.

  • The update package is always applied in the active system (no matter if the system is single or dual boot), so special care is required while creating the update package to avoid system corruption after the update.

Refer to Create files-based SWU package to learn how to create this type of update package.

This mechanism requires the file system to be writable. For read-only partitions you must mount the partition as read-write before the update starts.

SWU packages based on binary differences

The SWU package strategy based on binary differences of firmware images consists of updating the system using the running partition image as base and applying a binary differences patch. In this case, the update package contains a delta file with the differences between a previous version of the system image and the new image version.

The update mechanism requires full knowledge of the software running on the device in order to compute a sensitive patch. For this reason, only systems without user modifications (read-only) are eligible for this type of update. Only the rootfs partition supports the read-only squashfs file system type, so it is the only partition that supports update packages based on binary differences. The linux partition (kernel, device trees) is updated as a full image.

Only dual boot systems support this update because the process requires a base partition to read the contents from and apply the delta patch on-the-fly to a different partition.

The scenarios for SWU packages based on binary differences include:

  • A fix for a specific system component has been released and you require it in your device. (This is applicable only to read-only systems.)

  • The update package must be as small as possible.

Pros

  • The SWU package size can be small since only boot image and delta files are delivered.

  • It is easier to create than a SWU package based on files.

  • Supported in read-only systems.

Cons

  • Not supported in read-write systems.

  • Not supported in single boot systems.

  • User data outside of system partitions cannot be updated.

Refer to Create binary-diff-based SWU package to learn how to create this type of update package.

This mechanism requires the filesystem to be read-only using squashfs.

Program a SWU package

You can program the SWU package from the running system or from Remote Manager.

Program a SWU package from Linux

If your Digi Embedded Yocto system is already running, you can update the firmware from the system itself.

The procedure is slightly different if you are using a dual boot partition layout or a single system partition layout. (See Storage layout for reference).

Program a SWU package from Remote Manager

You can remotely program a SWU package in your device through Remote Manager. Refer to Program SWU packages from Remote Manager.