SWUpdate Integration in Yocto with meta-tegra for NVIDIA Jetson Platforms
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:
- Yocto Support for NVIDIA Jetson Platforms - Setting up Yocto
- Yocto Support for NVIDIA Jetson Platforms - Flashing the Jetson Platform
- How to Use A/B Filesystem Redundancy and OTA with NVIDIA Jetpack
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
- Yocto Support for NVIDIA Jetson Platforms - Setting up Yocto
- Yocto Support for NVIDIA Jetson Platforms - Flashing the Jetson Platform
- How to Use A/B Filesystem Redundancy and OTA with NVIDIA Jetpack
- Extending meta-tegra for OTA Updates: The rr-nvidia-ota Layer
- RidgeRun Platform Security Manual/Getting_Started/Over-the-Air/Main-Providers
- NVIDIA Jetson Software Services
References
- SWUpdate Documentation
- SWUpdate: meta-swupdate building with Yocto
- meta-swupdate GitHub repository
- OpenEmbedded Layer Index: meta-swupdate
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.