SWUpdate Integration in Yocto with meta-tegra for NVIDIA Jetson Platforms

From RidgeRun Developer Wiki

Follow Us On Twitter LinkedIn Email Share this page


SWUpdate Integration in Yocto with meta-tegra for NVIDIA Jetson Platforms

This guide explains how to integrate SWUpdate into a Yocto build based on meta-tegra for NVIDIA Jetson platforms, generate a .swu update package, deploy it to the target, and validate the update flow on an A/B root filesystem layout. In practice, this page is useful when you want a reproducible OTA-ready image for Jetson devices without leaving a Yocto workflow.

Overview

SWUpdate is an embedded Linux software update framework that can install complete system images or selected artifacts from a compound update package. In a Yocto workflow, the usual pattern is to add the meta-swupdate layer, build an image that includes the SWUpdate client, and produce a .swu package that can be copied to the Jetson target and applied locally or through a higher-level OTA workflow.

For NVIDIA Jetson platforms, this approach is especially useful when you already build your BSP and userspace with meta-tegra and Yocto and you want an update mechanism that fits naturally into that environment. If you need NVIDIA's image-based OTA tooling instead of SWUpdate, also review Extending meta-tegra for OTA Updates: The rr-nvidia-ota Layer and How to Use A/B Filesystem Redundancy and OTA with NVIDIA Jetpack.

Before you begin

This page assumes the following:

  • You already have a working Yocto build for a Jetson board based on meta-tegra.
  • You can enter the BitBake environment for that build.
  • Your target can be flashed and booted successfully before you attempt OTA packaging.
  • Your machine configuration supports or is being adapted for redundant root filesystem layout.
  • You are using a meta-swupdate branch that matches your Yocto release.

Recommended starting points:

Why use SWUpdate on Jetson with meta-tegra?

SWUpdate is a good fit when you want:

  • A Yocto-native way to generate update artifacts
  • A simple local or OTA package format based on .swu
  • A framework that works well with A/B redundancy and rollback-oriented designs
  • Flexibility to update the root filesystem and other artifacts in a controlled way

It is not the only OTA path on Jetson. RidgeRun also documents NVIDIA-focused OTA flows and related platform security options in RidgeRun Platform Security Manual/Getting Started/Over-the-Air/Main-Providers and Extending meta-tegra for OTA Updates: The rr-nvidia-ota Layer.

Add the required Yocto layers

When working with the tegra-demo-distro repository, you must include the necessary Yocto layers to enable SWUpdate support.

To integrate SWUpdate, add the required layers to your build:

  • meta-swupdate
  • meta-oe from meta-openembedded

The meta-swupdate layer must match the Yocto release you are using. Check the corresponding branch before adding it to your workspace.

Check which branch your repository is using:

cd <path-to-the-repository>
git branch --show-current

Once you have confirmed the branch, clone meta-swupdate using the same branch:

cd repos
git submodule add -b <branch-name> https://github.com/sbabic/meta-swupdate
cd ../layers
ln -s ../repos/meta-swupdate

Then add the layer from your BitBake environment:

bitbake-layers add-layer ../layers/meta-swupdate

Configure the build

In your local.conf add these lines:

IMAGE_INSTALL:append = " swupdate"
IMAGE_FSTYPES:append = " tar.gz"

In your machine configuration file:

conf/machine/<machine>.conf

enable redundant layout support:

USE_REDUNDANT_FLASH_LAYOUT = "1"

If you want to use an image other than demo-image-base as your base image, add a definition for SWUPDATE_CORE_IMAGE_NAME with the desired base image in the same file.

SWUPDATE_CORE_IMAGE_NAME = "custom-image-base"

The following Jetson boards and their corresponding JetPack / meta-tegra combinations have been validated by RidgeRun for this SWUpdate workflow.

For a complete and up-to-date list of supported platforms, refer to NVIDIA Jetpack Reference Guide - Jetson boards

Build the SWUpdate image and package

Build the update image with:

bitbake swupdate-image-tegra

After a successful build, the generated .swu package is expected in the deploy directory for the selected machine:

<meta-custom-or-meta-tegra-demo-distro>/build/tmp/deploy/images/<machine>

A typical filename looks like this:

swupdate-image-tegra-<machine>.rootfs-<timestamp>.swu

Deploy the image to the Jetson target

Before testing updates, flash the Jetson board with the image that already includes SWUpdate. Use your normal flashing flow for the selected board and meta-tegra build. If you need a refresher, review Yocto Support for NVIDIA Jetson Platforms - Flashing the Jetson Platform.

After flashing and booting the target, verify that SWUpdate is installed:

root@jetson:~# which swupdate
/usr/bin/swupdate

Copy the generated .swu package to the board. For example:

 scp swupdate-image-tegra-<machine>.rootfs-<timestamp>.swu root@<board-ip>:/root/

Apply the update

Once is complete transfer to the board, run the update with:

 cd /root/
swupdate -i swupdate-image-tegra-<machine>.rootfs-<timestamp>.swu

Once the update finishes, reboot the device so the alternate slot can be selected.

Validate A/B slot switching after reboot

After reboot, validate the result in two ways.

First, confirm that the active root partition changed as expected.

Second, inspect the boot slot information:

nvbootctrl dump-slots-info

You should see evidence that the device booted from the alternate slot and that the update status reflects a successful transition. Example output:

root@tegra-demo-distro:~# nvbootctrl dump-slots-info
Current version: 36.4.4
Capsule update status: 1
Current bootloader slot: B
Active bootloader slot: B
num_slots: 2
slot: 0,             status: normal
slot: 1,             status: normal

Common issues and troubleshooting

Build fails after adding meta-swupdate

Common causes:

  • The meta-swupdate branch does not match the Yocto release.
  • meta-oe is missing from bblayers.conf.
  • The image type required by the SWUpdate recipe is not enabled.

No .swu package is generated

Check the following:

  • The build target is swupdate-image-tegra
  • The base image selected through SWUPDATE_CORE_IMAGE_NAME exists
  • The deploy directory for the selected machine is correct

The target does not switch slots after reboot

Check the following:

  • USE_REDUNDANT_FLASH_LAYOUT = "1" is set in the machine configuration
  • The board was initially flashed with an image that supports the intended redundant layout
  • Boot control metadata is consistent with the selected Jetson platform and JetPack generation

The package transfers correctly but SWUpdate fails on target

Check the following:

  • The package filename matches the built image and machine
  • The SWUpdate client is installed on the target
  • The package was copied in full and was not truncated during transfer

Performance and operational considerations

When planning OTA on Jetson, do not treat the SWUpdate package as the whole solution. Also consider:

  • Storage overhead for A/B or redundant layouts
  • How application data is preserved across updates
  • Whether updates are local-only or orchestrated remotely
  • Whether you need artifact signing, encryption, or staged rollout behavior

For broader OTA strategy options on embedded Linux, see RidgeRun Platform Security Manual/Getting Started/Over-the-Air/Main-Providers.

Key takeaways

SWUpdate can be integrated cleanly into a meta-tegra-based Yocto build for NVIDIA Jetson platforms by adding meta-swupdate, enabling the required image artifacts, building swupdate-image-tegra, and validating the update on a target flashed with a compatible redundant layout. The most important details are branch alignment, A/B layout support, and post-reboot validation with Jetson boot control tools.

FAQ

What does this page help me do?
It shows how to add SWUpdate to a Yocto build based on meta-tegra for NVIDIA Jetson, generate a .swu package, apply it on target, and verify the update result.
Do I need meta-oe in addition to meta-swupdate?
Yes. This flow expects meta-oe from meta-openembedded because meta-swupdate depends on it.
Why is USE_REDUNDANT_FLASH_LAYOUT important?
It enables the redundant root filesystem layout needed for an A/B-style update flow on supported Jetson platforms.
Where is the generated .swu file located?
It is typically generated under tmp/deploy/images/<machine>/ inside your Yocto build directory.
How do I confirm the update really switched slots?
After reboot, inspect the active slot and related status using nvbootctrl dump-slots-info and verify that the device is running from the alternate slot.

Related pages

References



For direct inquiries, please refer to the contact information available on our Contact page. Alternatively, you may complete and submit the form provided at the same link. We will respond to your request at our earliest opportunity.


Links to RidgeRun Resources and RidgeRun Artificial Intelligence Solutions can be found in the footer below.