Software Packages and the Update Mechanism

NVIDIA provides additional NVIDIA® Jetson™ Linux software components and updates in APT (Debian) repositories, accessible through the apt utility.


These packages are only verified with the root filesystem shipped in this L4T BSP release.

Installing Additional Packages

NVIDIA maintains the following APT repositories:

  • For NVIDIA® Jetson AGX Xavier™ series

  • For NVIDIA® Jetson Xavier™ NX series

  • For NVIDIA® Jetson AGX Orin™

The package nvidia-l4t-apt-source is preinstalled in the Jetson Linux root file system. It identifies the platform it is running on and adds the appropriate repositories to the software source list.

The packages in the APT repositories are signed with GPG keys. The corresponding public key is preinstalled in the Jetson Linux root file system. Once the repositories are added to the source list, apt can download and install packages.


The APT repositories described here are also used to upgrade existing packages and install packages that NVIDIA adds to the set initially installed with Jetson Linux. For more information, see Updating a Jetson Device.

Repackaging Debian Packages

You can use the script to repackage the existing Jetson Linux Debian packages. The script can be found in the directory Linux_for_Tegra/tools/Debian/. See Linux_for_Tegra/tools/Debian/nvdebrepack.txt for usage and examples.

Building Kernel Debian Packages Yourself

You can customize the Jetson Linux kernel by getting the kernel source packages, making your changes, and building the Debian packages.

This section describes the package dependencies and scripts that NVIDIA uses to build the kernel packages. You may use it as a reference to create your own Debian packages.

Working with the Packages

The kernel packages are all open source. Three of the four kernel packages are in public_sources.tbz2. You can download the archive from the NVIDIA Developer Center.

This archive contains another archive named kernel_src.tbz2, which in turn contains three directories of header files:

  • nvidia-l4t-kernel/

  • nvidia-l4t-kernel-dtbs/

  • nvidia-l4t-kernel-headers/

The Guide for Debian Maintainers gives guidelines for modifying the open source files and creating new Debian packages from them.

The fourth kernel package, nvidia-l4t-jetson-io, is discussed in nvidia-l4t-jetson-io, below.

Package Dependencies

Most Jetson Linux Debian packages pre-depend on nvidia-l4t-core. This package prevents package installation on an incompatible Jetson platform, e.g., installing a Jetson software package on a non-Jetson device. nvidia-l4t-core does not perform the installation if it detects an incompatible platform.

nvidia-l4t-core also prevents a partial upgrade, in which one Jetson Linux package upgrades to a new major release, but other Jetson Linux packages that depend on it are not upgraded as well. Partial upgrades can cause compatibility issues between firmware, programs, and libraries that have been upgraded and ones that have not.


nvidia-l4t-kernel contains files for the Jetson Linux kernel itself.

Pre-Dependencies and Dependencies

This package’s pre-dependencies are:

  • nvidia-l4t-core (must match this package’s major release)

This package’s dependencies are:

  • nvidia-l4t-tools

  • nvidia-l4t-init

Package Scripts

This package has a post-installation script which you can get by extracting the .deb file. It performs these actions:

  1. Executes depmod -a.

  2. Creates a dpkg trigger file named /usr/lib/linux/triggers/<release>. The trigger invokes actions defined in /etc/kernel/postinst.d to update initramfs/grub configs/… when the kernel is updated. This conforms to the standard Ubuntu kernel update procedure.


nvidia-l4t-kernel-dtbs contains files for Jetson Linux’s device tree blobs (DTBs).

The package installs all of the .dtb files in /boot/. When you flash a board, it installs the .dtb file used by that board in /boot/dtb/ by checking the board specification against the DTBs’ compatibility information.

Pre-Dependencies and Dependencies

This package’s pre-dependencies are:

  • nvidia-l4t-core (must match this package’s major release)

This package’s dependencies are:

  • device-tree-compiler

  • nvidia-l4t-kernel

Package Scripts

This package has a post-installation script, which you can get by extracting the .deb file.

The post-installation script performs these actions:

  1. Decompiles the .dtb file used by the board in /boot/dtb/ and gets the bootargs property in the /chosen node.

  2. Decompiles the corresponding .dtb file in /boot/ and substitutes the bootargs property from step 1 in the resulting .dts file.

  3. Recompiles the .dts file to a .dtb file and puts it in /boot/dtb/.


nvidia-l4t-kernel-headers contains Jetson Linux kernel header files.

Pre-Dependencies and Dependencies

This package’s pre-dependencies are:

  • nvidia-l4t-core (must match this package’s major release)

This package’s dependencies are:

  • nvidia-l4t-kernel

  • libc6

  • libssl1.1

Package Scripts

This package has no package scripts.


nvidia-l4t-jetson-io contains Python scripts concerned with Jetson I/O functions.

Pre-Dependencies and Dependencies

This package’s pre-dependencies are:

  • nvidia-l4t-core (must match this package’s major release)

This package’s dependencies are:

  • mount

  • python3

  • util-linux

  • nvidia-l4t-kernel

  • device-tree-compiler

You can also get the dependencies by extracting the Debian file.

Package Scripts

This package has no package scripts.

Over-the-Air Update

Over-the-Air (OTA) Update enables you to update NVIDIA Jetson devices and host computers for Jetson development.

Jetson Linux supports two forms of OTA, which are used for different purposes. Debian package management-based OTA can update Jetson devices running Jetson Linux or Jetson components on a host computer. Image-based OTA lets you create OTA payload packages, and can update the full image running on a Jetson device, partition by partition. The following sections describe both forms of OTA.

Updating from the NVIDIA APT Server

The first form of OTA update uses Debian packages obtained from an NVIDIA APT server. You can use this form of OTA update to update a Jetson device running Jetson Linux or to update NVIDIA JetPack™ components installed on a host computer running Ubuntu. The APT server maintains respective groups of Debian packages for each purpose.

This section describes the tools and packages that provide basic support for Jetson Linux.


You cannot use OTA update to update a Jetson device on which JetPack is installed.

To update JetPack and Jetson Linux components to a new JetPack release on a system where both are installed, see the instructions in the JetPack documentation.

NVIDIA does not recommend installing OTA Debian packages on a Jetson Linux release earlier than release 32.3.1, or on a system that is based on Ubuntu without the customization of Jetson Linux.

Upgrading from release 32.x to release 35.x is not supported. Only release 34.x is supported right now. Please check the /etc/nv_tegra_release on your Jetson for the current software version.

Updating a Jetson Device

Use the appropriate procedure below to update your system:

To update to a new point release
  1. Enter the command:

    $ sudo apt update

    apt reads a list of packages from the remote APT repository and identifies new and upgradable packages.

  2. Enter the command:

    $ apt list --upgradable

    apt displays a list of new and upgradable packages.

  3. To install the basic packages for Jetson Linux, enter the command:

    $ sudo apt upgrade
  4. Reboot your Jetson device when the upgrade is finished.

To update to a new minor release
  1. Open the apt source configuration file in a text editor, for example:

    $ sudo vi /etc/apt/sources.list.d/nvidia-l4t-apt-source.list
  2. Change the repository name and download URL in the deb commands.

    The original commands are:

    deb <release> main
    deb<platform> <release> main


    • <release> is the release number of the minor release to which you want to update. For example, to update to minor release 35.1, replace <release> with r35.1. OTA updates to the latest point release of the specified minor release.

    • <platform> identifies the platform’s processor:

      • t234 for NVIDIA® Jetson AGX Orin™

      • t194 for Jetson Xavier NX series or Jetson AGX Xavier series

    For example, if the current release is release 35.1, and your platform is Jetson AGX Orin series, the commands are:

    deb r35.1 main
    deb r35.1 main
  3. Save and close the source configuration file.

  4. Enter the commands:

    $ sudo apt update
    $ sudo apt dist-upgrade

    If apt prompts you to choose an option to fix local modified configuration file, reply Y for yes (to use the NVIDIA updated version of the file).

    If you’re upgrading from release 34, please install the following new packages manually:

    $ sudo apt install nvidia-l4t-openwfd nvidia-l4t-vulkan-sc-dev nvidia-l4t-vulkan-sc-samples nvidia-l4t-vulkan-sc-sdk nvidia-l4t-vulkan-sc nvidia-l4t-jetsonpower-gui-tools
  5. When the upgrade is finished, reboot the Jetson device.


  • The do-release-upgrade command is disabled because Jetson Linux does not officially support Ubuntu release 22.04 at this time.

Updating a Host

NVIDIA provides a group of Debian packages that add or update Jetson Linux support components on the host computer.

To prepare the host computer to install Jetson Linux support components
  1. Enter this command to install the public key of the x86_64 repository of the public APT server:

    $ sudo apt-key adv --fetch-key
  2. Add the following x86_64 repository to the host system’s source list.

    • For an Ubuntu 18.04 host:

      deb <relno> main
    • For an Ubuntu 20.04 host:

      deb <relno> main

    Where <relno> is the current release’s full release number as specified in the Release Notes.

  3. Enter the command:

    $ sudo apt update
  4. Use apt to download and install the required packages.

    • For an Ubuntu 18.04 host:

      $ sudo apt-get install cuda-cross-aarch64-11-4 cuda-toolkit-11-4 \
            cuda-cupti-cross-aarch64-11-7 cuda-sanitizer-11-7 \
            libnvvpi2 python3.8-vpi2 vpi2-demos vpi2-cross-aarch64-l4t \
            vpi2-dev vpi2-samples nsight-systems-2022.3.3 nvsci \
            nsight-compute-2022.2.1 nsight-compute-addon-l4t-2022.2.1 \
    • For an Ubuntu 20.04 host:

      $ sudo apt-get install cuda-cross-aarch64-11-4 cuda-toolkit-11-4 \
            cuda-cupti-cross-aarch64-11-7 cuda-sanitizer-11-7 \
            libnvvpi2 python3.8-vpi2 python3.9-vpi2 vpi2-demos \
            vpi2-dev vpi2-samples vpi2-cross-aarch64-l4t \
            nsight-compute-2022.2.1 nsight-compute-addon-l4t-2022.2.1 \
            nsight-graphics-for-embeddedlinux-2022.3.0.0 \
            nsight-systems-2022.3.3 nvsci

Debian Packages on the NVIDIA APT Server

This section lists the Debian packages maintained on the NVIDIA APT server for a Jetson device or a host.

Update Packages for Jetson Devices

Here is a list of the OTA update packages for BSP on Jetson devices as of Jetson Linux release 35.1.

For a list of other OTA packages and instructions for applying them, see “List of JetPack OTA Packages” in JetPack SDK.

Component group



  • jetson-gpio-common

  • nvidia-l4t-3d-core

  • nvidia-l4t-apt-source

  • nvidia-l4t-bootloader

  • nvidia-l4t-camera

  • nvidia-l4t-configs

  • nvidia-l4t-core

  • nvidia-l4t-cuda

  • nvidia-l4t-display-kernel

  • nvidia-l4t-firmware

  • nvidia-l4t-gbm

  • nvidia-l4t-gputools

  • nvidia-l4t-graphics-demos

  • nvidia-l4t-gstreamer

  • nvidia-l4t-init

  • nvidia-l4t-initrd

  • nvidia-l4t-jetson-io

  • nvidia-l4t-jetson-multimedia-api

  • nvidia-l4t-jetsonpower-gui-tools

  • nvidia-l4t-kernel

  • nvidia-l4t-kernel-dtbs

  • nvidia-l4t-kernel-headers

  • nvidia-l4t-libvulkan

  • nvidia-l4t-multimedia

  • nvidia-l4t-multimedia-utils

  • nvidia-l4t-nvfancontrol

  • nvidia-l4t-nvpmodel

  • nvidia-l4t-nvpmodel-gui-tools

  • nvidia-l4t-nvsci

  • nvidia-l4t-oem-config

  • nvidia-l4t-openwfd

  • nvidia-l4t-optee

  • nvidia-l4t-pva

  • nvidia-l4t-tools

  • nvidia-l4t-vulkan-sc

  • nvidia-l4t-vulkan-sc-dev

  • nvidia-l4t-vulkan-sc-samples

  • nvidia-l4t-vulkan-sc-sdk

  • nvidia-l4t-wayland

  • nvidia-l4t-weston

  • nvidia-l4t-x11

  • nvidia-l4t-xusb-firmware

  • python-jetson-gpio

  • python3-jetson-gpio

Update Packages for Hosts

The following table lists Jetson Linux support components that you can install with apt on a host, and the packages that contain them.

Component group



  • cuda-11-4

  • cuda-cccl-11-4

  • cuda-command-line-tools-11-4

  • cuda-compat-11-4

  • cuda-compiler-11-4

  • cuda-cudart-11-4

  • cuda-cudart-dev-11-4

  • cuda-cuobjdump-11-4

  • cuda-cupti-11-4

  • cuda-cupti-dev-11-4

  • cuda-cuxxfilt-11-4

  • cuda-demo-suite-11-4

  • cuda-documentation-11-4

  • cuda-driver-dev-11-4

  • cuda-drivers

  • cuda-drivers-470

  • cuda-drivers-fabricmanager

  • cuda-drivers-fabricmanager-470

  • cuda-gdb-11-4

  • cuda-gdb-src-11-4

  • cuda-libraries-11-4

  • cuda-libraries-dev-11-4

  • cuda-minimal-build-11-4

  • cuda-nsight-11-4

  • cuda-nsight-compute-11-4

  • cuda-nsight-systems-11-4

  • cuda-nvcc-11-4

  • cuda-nvdisasm-11-4

  • cuda-nvml-dev-11-4

  • cuda-nvprof-11-4

  • cuda-nvprune-11-4

  • cuda-nvrtc-11-4

  • cuda-nvrtc-dev-11-4

  • cuda-nvtx-11-4

  • cuda-nvvp-11-4

  • cuda-profiler-api-11-4

  • cuda-runtime-11-4

  • cuda-samples-11-4

  • cuda-sanitizer-11-4

  • cuda-toolkit-11-4

  • cuda-toolkit-11-4-config-common

  • cuda-toolkit-11-config-common

  • cuda-toolkit-config-common

  • cuda-tools-11-4

  • cuda-visual-tools-11-4

  • libcublas-11-4

  • libcublas-dev-11-4

  • libcufft-11-4

  • libcufft-dev-11-4

  • libcurand-11-4

  • libcurand-dev-11-4

  • libcusolver-11-4

  • libcusolver-dev-11-4

  • libcusparse-11-4

  • libcusparse-dev-11-4

  • libnpp-11-4

  • libnpp-dev-11-4

  • libnvidia-cfg1-430

  • libnvidia-cfg1-470

  • libnvidia-common-430

  • libnvidia-common-470

  • libnvidia-compute-430

  • libnvidia-compute-470

  • libnvidia-decode-430

  • libnvidia-decode-470

  • libnvidia-encode-430

  • libnvidia-encode-470

  • libnvidia-extra-470

  • libnvidia-fbc1-430

  • libnvidia-fbc1-470

  • libnvidia-gl-430

  • libnvidia-gl-470

  • libnvidia-ifr1-430

  • libnvidia-ifr1-470

  • libnvidia-nscq-470

  • libnvjpeg-11-4

  • libnvjpeg-dev-11-4

  • libxnvctrl-dev

  • libxnvctrl0

  • nsight-compute-2021.2.5

  • nsight-systems-2022.1.3

  • nvidia-compute-utils-430

  • nvidia-compute-utils-470

  • nvidia-dkms-430

  • nvidia-dkms-470

  • nvidia-driver-430

  • nvidia-driver-470

  • nvidia-fabricmanager-470

  • nvidia-fabricmanager-dev-470

  • nvidia-headless-430

  • nvidia-headless-470

  • nvidia-headless-no-dkms-430

  • nvidia-headless-no-dkms-470

  • nvidia-kernel-common-430

  • nvidia-kernel-common-470

  • nvidia-kernel-source-430

  • nvidia-kernel-source-470

  • nvidia-modprobe

  • nvidia-settings

  • nvidia-utils-430

  • nvidia-utils-470

  • xserver-xorg-video-nvidia-430

  • xserver-xorg-video-nvidia-470

CUDA cross-compile

  • cuda-cccl-cross-aarch64-11-4

  • cuda-cross-aarch64

  • cuda-cross-aarch64-11-4

  • cuda-cudart-cross-aarch64-11-4

  • cuda-cupti-cross-aarch64-11-4

  • cuda-driver-cross-aarch64-11-4

  • cuda-nsight-compute-addon-l4t-11-4

  • cuda-nvcc-cross-aarch64-11-4

  • cuda-nvml-cross-aarch64-11-4

  • cuda-nvrtc-cross-aarch64-11-4

  • cuda-nvtx-cross-aarch64-11-4

  • cuda-profiler-api-cross-aarch64-11-4

  • libcublas-cross-aarch64-11-4

  • libcudla-cross-aarch64-11-4

  • libcufft-cross-aarch64-11-4

  • libcurand-cross-aarch64-11-4

  • libcusolver-cross-aarch64-11-4

  • libcusparse-cross-aarch64-11-4

  • libnpp-cross-aarch64-11-4

  • nsight-compute-addon-l4t-2021.2.5

Computer Vision

  • libnvvpi2

  • vpi2-dev

  • vpi2-cross-aarch64-l4t

  • python3-vpi2

  • python3.9-vpi2

  • vpi2-samples

  • vpi2-demos

Developer Tools

  • nsight-systems-2022.3.3

  • nsight-compute-addon-l4t-2022.2.1

  • nsight-compute-2022.2.1

  • nsight-graphics-for-embeddedlinux-2022.3.0.0

  • cuda-cupti-cross-aarch64-11-7

  • cuda-sanitizer-11-7

Customizing Debian Packages

You can customize Debian packages to help you implement your solution, for example, by adding support for your carrier board. For more information, see Repackaging Debian Packages and Building Kernel Debian Packages Yourself.

Downloading Debian Packages for Later Use

As an alternative to installing Debian packages on a Jetson device or host from the APT server, you can download packages and store them, and later install them manually.

To download packages, open the NVIDIA Jetson repository in a web browser. This page displays a list of Debian packages for each JetPack release and processor. Each package name is a hyperlink; to download a package, click its link.

Updating Jetson Linux with Image-Based Over-the-Air Update

Applies to Jetson Xavier NX series and Jetson AGX Xavier series only.

Image-Based Over-the-Air Update is a failsafe way to update BSP on a Jetson device by writing pre-generated images to the partitions.

Image-based OTA also supports updates between versions with different partition layouts that require layout changes during the update. For example, image-based OTA currently supports updates from version 32.7.x to version 35.1. Updating from releases earlier than version 32.7.x will be supported in the next release.

Updates to Jetson Linux release 35.1

Carrier board


From release

Jetson AGX Xavier

All Jetson AGX Xavier series modules

32.7.1 or 32.7.2

Jetson Xavier NX series

All Jetson Xavier NX series modules

32.7.1 or 32.7.2

Terms and Abbreviations

This section uses the following terms and abbreviations:

  • Bootloader update payload (BUP): a file that contains firmware binaries of each type needed to update a Jetson device.

  • Minimal set of images (MSI): the minimal set of images needed to boot Jetson Linux.

  • Over-the-Air Update (OTA): the Jetson Linux feature that enables you to update Jetson devices.

  • Top of tree (ToT): the latest revision of a file in a source control system such as Git.

Overall High-Level Flow

Here is the workflow for an image-based OTA update:

  1. Prepare an OTA payload package on the host machine.

  2. Trigger the OTA process on the target device.

Preparing the OTA Payload Package

The current Jetson Linux BSP provides the necessary tools to generate the OTA payload package in the OTA tool package. To download the OTA tool package, go to Jetson Linux page.

The OTA tool package can be used to create OTA payload package for:

  • Updating a full system

  • Updating Bootloader only

  • Updating the rootfs only


The ability to only update Bootloader or only update the rootfs is not supported in this release.

The generated OTA payload package is in the ota_payload_package.tar.gz archive, and the OTA payload package includes images for the partitions that need to be updated.


NVIDIA recommends applying a security mechanism, such as a signature or encryption, to this package

Upload ota_payload_package.tar.gz and the OTA tools package ota_tools_<rel>_aarch64.tbz2 to your OTA server.

Trigger the OTA Process

You are responsible for writing the OTA client service that triggers the OTA process, and the service must include the following steps:

  1. Download the ota_tools_<rel>_aarch64.tbz2 OTA tool package and the ota_payload_package.tar.gz OTA payload package from your own OTA server.

    <rel> is the current release number, for example 35.1.

  2. Validate the downloaded OTA payload package and its contents according to your own security requirements.

  3. Use the tool in the OTA tool package to trigger the OTA update. The tool decompresses the OTA payload package and prepares it for OTA update. The tool handles cases where a partition layout change is involved and not involved, and where rootfs A/B is enabled and disabled.


Image-based OTA with rootfs A/B enabled is not supported in this release.

Preparing for an Image-Based OTA Update

To prepare for an image-based OTA update, the following steps need to be completed on the host machine and the target device.

Steps Performed on the Host Machine
  1. Set the BASE_BSP environment variable to the complete pathname of the Linux_for_Tegra/ directory for base BSP. (The base BSP is the BSP release that needs to be updated, for example, release r32.7.x.). For example, set BASE_BSP by running command:

    $ export BASE_BSP=/home/username/R32.7.2/Linux_for_Tegra
  2. Get the package for the current release of Jetson Linux and unpack and apply its sample root file system.

  3. Go to the directory that contains the current BSP package and enter the following commands:

    $ tar xpf jetson_linux_<rel>_aarch64.tbz2
    $ cd Linux_for_Tegra/rootfs/
    $ sudo tar xpf ../../tegra_Linux_sample-root-filesystem_<rel>_aarch64.tbz2
    $ cd ..
    $ sudo ./
  4. Set the environment variable TARGET_BSP to the complete pathname of the Linux_for_Tegra/ directory for current BSP release. For example, set TARGET_BSP by running command:

    $ export TARGET_BSP=/home/username/R35.1/Linux_for_Tegra
  5. Install the ota_tools_<rel>_aarch64.tbz2 OTA tool package to ${TARGET_BSP}:

    $ cd ${TARGET_BSP}/../
    $ sudo tar xpf ota_tools_<rel>_aarch64.tbz2
  6. To generate the OTA update payload package, enter the following commands:

    $ cd ${TARGET_BSP}
    $ sudo -E ./tools/ota_tools/version_upgrade/ \
            [-s] [-b] [-r] [-u <PKC_key_file>] [-v <SBK_key_file>] [-o <rootfs_updater>] \
            [-f <rootfs_image>] <target_board> <bsp_version>


    • -s, -b, and -r can be used separately, as shown or be combined in one “word”, for example, -sb or -sr.

      • -s: Skip generating the rootfs image. Use this option if a rootfs image has been generated or specified with the -f option.

      • -b: Generate an OTA payload package to only update Bootloader. This option is meaningful only for an update without layout change.

      • -r: Generate an OTA payload package to only update rootfs. This option is meaningful only for an update without layout change.

    • <PKC_key_file> is an optional PKC key file, and it must be the same as the file that was used to flash images to the target board.

    • <SBK_key_file> is an optional SBK key file, and it must be the same as the file that was used to flash images to the target board.

    • <rootfs_updater> specifies the script that will be be used to update the rootfs partition. (Refer to Updating the Rootfs Partition with a Customized Updater and Image for more information.)

    • <rootfs_image> is the path of the rootfs image to be written to the rootfs partition.

      The default rootfs is built from ${TARGET_BSP}/rootfs, and this option allows you overwrite the default rootfs image with a self-generated rootfs image. An example is an image that is cloned from a Jetson device that has been completely customized with a ToT release of Jetson Linux.

    • <target_board> is the appropriate configuration name:

      • For Jetson Xavier NX P3668-0001 (production): jetson-xavier-nx-devkit-emmc

      • For Jetson AGX Xavier P2888-0001 (16GB) or P2888-0004 (32GB): jetson-agx-xavier-devkit

    • <bsp_version> is the base BSP version, in the form Rmm-n, where mm and n are the major and minor version numbers. The base BSP version is release 32.7.x in this release. For example, R32-7 specifies base BSP version 32.7.x.

The script generates the ota_payload_package.tar.gz file under the ${TARGET_BSP}/bootloader/<target_board>/ directory.

The ota_payload_package.tar.gz archive that the script generates from the default rootfs occupies about 2GB, and a self-generated rootfs might yield a larger or smaller archive. To apply the image-based OTA, and decompress the archive on the Jetson device, requires at least 6GB of free space.


Step 6 in the section Steps Performed on the Host Machine uses the Jetson Linux sample rootfs from Linux_for_Tegra/rootfs/ to build the OTA package.

If you customized the sample rootfs, for example, add required libraries and binaries into the rootfs and apply them before running this script.

To implement a complete OTA solution, place the OTA tool package and OTA payload package on your OTA server .

Steps Performed on the Jetson Device
  1. Review /boot/extlinux/extlinux.conf.

    • If the INITRD entry is not set, add this line under the LINUX /boot/Image line:

      INITRD /boot/initrd
    • If the root device is not set, add it into the APPEND line, for example:

      root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4
  2. Download the ota_tools_<rel>_aarch64.tbz2 OTA tool package and the ota_payload_package.tar.gz OTA payload package to the target board.

  3. Create a directory to hold files that were generated in the OTA update process.

  4. Set the WORKDIR environment variable to the complete pathname for this directory.

  5. Unpack ota_tools_<rel>_aarch64.tbz2 into the ${WORKDIR} directory.

  6. Create a /ota/ directory.

  7. Place the ota_payload_package.tar.gz OTA payload package in the /ota/ directory.

  8. Unpack the OTA payload package and prepare to start OTA:

    $ cd ${WORKDIR}/Linux_for_Tegra/tools/ota_tools/version_upgrade
    $ sudo ./ /dev/mmcblk0 /ota/ota_payload_package.tar.gz
  9. If no error occurred in step 8, reboot the target board.

    After executing this step, the target board boots to the recovery kernel, which runs the OTA update process. If unexpected power loss or reset occurs in OTA update process, the target device can reboot into the recovery kernel and continue the update. The maximum number of times the target device reboots and continues the update is determined by the OTA_MAX_RETRY_COUNT script variable, which defaults to 0 (zero). If the update fails more than the specified number of times, the target device boots to the recovery kernel and enters the bash shell. You can change the value of OTA_MAX_RETRY_COUNT in ${TARGET_BSP}/tools/ota_tools/version_upgrade/

    If the update process fails, logs are placed in the /ota_logs/ directory on the target device. These logs record the details of the OTA update process. At the end of a successful OTA update, the log files in this directory are deleted.


To create a complete, secure OTA update solution, you must complete the following tasks:

  • Implement an OTA client that executes this procedure on the target device.

  • Apply security mechanisms according to your security policy requirements.

Utility for Triggering OTA

The utility is used to trigger the OTA, and image-based OTA supports updates between versions with or without partition layout changes. The OTA supports updates whether rootfs A/B is enabled or disabled. You do not need to be aware of the difference because the utility handles both cases.


The utility only supports update with partition layout change and rootfs A/B disabled in this release. is included in ota_tools_<rel>_aarch64.tbz2. It determines whether layout changes are needed and executes another script to perform the appropriate type of update.

To perform an update without layout changes, the script executes

To perform an update with layout changes, the script executes Refer to Update with Partition Layout Changes for more information about how to update a version with partition layout changes.

Update with Partition Layout Changes

An update with partition layout changes is a challenging process for an image-based OTA update. If you perform the partition changes directly, an unexpected reboot during the update might fail and leave the Jetson device in an unbootable state.

BSP supports A/B update, which maintains two sets of partitions (chain A and chain B) to boot and run the operating system. It uses only one chain at a time, applies updates to the partitions on the inactive chain, and swaps the roles of the chains. For example, when chain A is active, BSP boots and runs the operating system from the partitions in chain A and applies updates to those in chain B. This ensures that an update failure cannot render the device unbootable.

For more information about the A/B update process, refer to Update and Redundancy.

To implement fail-safe update, if there is an unexpected reboot during update, the image-based OTA update process creates some intermediate partition layouts, which it uses to create alternative bootable paths. A bootable path is composed of many partitions located on the free space of the storage device. The images stored in these partitions are called MSI.

For example, an OTA update from release 32.7.x to release 35.1 on Jetson Xavier NX P3668-0001 uses three intermediate partition layouts:

  • flash_l4t_t194_spi_emmc_p3668_R32i.xml is based on the default partition layout in release 32.7.x. It is used by jetson-xavier-nx-devkit-emmc-R32i.conf.

  • flash_l4t_t194_spi_emmc_p3668_R32x_R35i.xml is based on the default partition layout in release 32.7.x. It is used by jetson-xavier-nx-devkit-emmc-R32x-R35i.conf.

  • flash_l4t_t194_spi_emmc_p3668_R35A_R35i.xml is based on the default partition layout in release 35.1. It is used by jetson-xavier-nx-devkit-emmc-R35A-R35i.conf. uses these intermediate partition layouts and their corresponding .conf files to generate the OTA payload package. By default, these layouts are created based on the default partition layout from the released BSP. If you customize anything on the default partition layout, you must apply the customization to the intermediate partition layouts. During OTA, the update script verifies these layouts with layouts on the actual board. If the layouts do not match, OTA update does not proceed.

Back Up and Restore Files on the APP Partition

The script in the ota_tools_<rel>_aarch64.tbz2 backs up and restores files on the APP partition during OTA update. It is located in the Linux_for_Tegra/tools/ota_tools/version_upgrade/ directory.

Edit the ota_backup_files_list.txt configuration file to add the pathnames of files that will be preserved after the OTA update. The distributed version of ota_backup_files_list.txt contains the following:

# All the files or directories should be listed with absolute path
# Example:
# etc/passwd
# opt/nvidia

Pathnames are written in relative form, but the names are always interpreted relative to the file system root. You can think of the names as absolute pathnames from which the leading slash is omitted.

You can add comment lines starting with a pound sign (‘#’) in column 1.


The script packs the listed files into a .tar.gz archive. You can select other ways to back up and restore these files based on your own requirements.

Complete and Secure OTA

NVIDIA provides the basic functionality of updating the system through the OTA update process. You must modify the process and create a complete and secure OTA solution. Depending on your needs, your modified process might have to meet at least one of the following requirements:

  • Encrypting OTA update payloads

  • Hosting OTA update payloads on an OTA update server

  • Triggering an OTA update when an update is found on the OTA server (a function of the OTA update client on the target device)

  • Authenticating the OTA update server

  • Decrypting OTA update payloads

  • Determining when to apply OTA update payloads


If you customized the released BSP, for example by customizing the rootfs or changing the partition layout, you must modify some files in the distributed image-based OTA update process to apply the image-based OTA update solution. The following sections provide information about the customization types and the OTA update changes that the types require.

Rootfs Customization

Rootfs customization comprises:

  • Adding or removing files in the rootfs.

  • Modifying the files in rootfs.

These changes require the following:

  • Applying changes to the rootfs.

Partition Layout Customization

Partition layout customization comprises:

  • Adding or removing partitions.

  • Changing size of partitions.

  • Changing location of partitions.

These changes require the following:

  • Modifying the provided intermediate partition layouts to accommodate the base system. For example, for a Jetson Xavier NX P3668-0001 flashed with release 32.7.x, the partition layout files are flash_l4t_t194_spi_emmc_p3668_R32i.xml and flash_l4t_t194_spi_emmc_p3668_R32x_R35i.xml.

  • Modifying the provided intermediate partition layout based on ${TARGET_BSP} the current release system. For the board above, the partition layout file is flash_l4t_t194_spi_emmc_p3668_R35A_R35i.xml.

  • Modifying the current release partition layout for ${TARGET_BSP}. For Jetson Xavier NX P3668-0001, it is flash_l4t_t194_spi_emmc_p3668.xml.

  • Modifying MSI_EMMC_OFFSET in the *.conf file if required. Make sure that the free space starting at MSI_EMMC_OFFSET is large enough to store the MSI. For the example above, the corresponding configuration files are jetson-xavier-nx-devkit-emmc-R32i.conf, jetson-xavier-nx-devkit-emmc-R32x-R35i.conf and jetson-xavier-nx-devkit-emmc-R35A-R35i.conf.

Update Process Customization

Update process customization comprises:

  • Changing the process of updating partitions.

  • Updating a newly created partition in addition to default partitions.

  • Updating only some of the default partitions.

These changes require the following:

  • Modifying the provided file upgradetasklist.txt.XXX, where “XXX” is a string that specifies the type of device and the old and new releases. For example, to update release 32.7.x to release 35.1 on a Jetson Xavier NX P3668-0001 , you must modify upgradetasklist.txt.jetson-xavier-nx-devkit-emmc.R32x_to_R35-ToT_emmc to specify the partitions to be updated.

Recovery Image Customization

Recovery image customization comprises:

  • Adding some files to the recovery initrd.

These changes require the following:

  • Editing the provided file recovery_copy_binlist.txt to specify the file systems and pathnames of any files you want to add to the recovery image. See the same file for an explanation and examples of how to make the changes.

Recovery Task Customization

In the recovery kernel, the script will be executed as a task runner. It will execute OTA tasks in a sequential order. To add a task to be run when recovery kernel is running, you must complete the following tasks:

  1. Place the script files that execute tasks into the Linux_for_Tegra/tools/ota_tools/version_upgrade/ directory. Make sure the script files have execution permission.

  2. Modify the OTA_TASKS and the OTA_TASK_NEEDED_FILES in nv_ota_customer.conf to add these script files.

    • The script files whose names are listed in the OTA_TASKS are OTA tasks which will be executed in order by the task runner. Insert the script file name at a proper position.

    • The script files whose names are listed in the OTA_TASK_NEEDED_FILES are the files needed by OTA tasks. Add the script file name into the list if any.

  3. Re-generate the OTA update payload package.

Miscellaneous Customization
  • Ethernet connectivity requirement

    If you want to ensure that no update is performed unless a stable Ethernet connection is available, enable OTA update’s Ethernet connectivity requirement by setting the property REQUIRE_ETHERNET in nv_ota_customer.conf. This setting makes Jetson device check Ethernet connectivity before starting OTA. If no connection is found, it attempts to establish one by rebooting.

    This requirement is disabled by default because a Jetson device does not use Ethernet as its primary means of connectivity.

Updating the Rootfs Partition with a Customized Updater and Image

When you generate an OTA payload package (step 6 in Steps Performed on the Host Machine), you can specify the rootfs updater with the -o option and specify the rootfs image with the -f option.

The rootfs updater is a script that writes the rootfs image to the rootfs partition. It is called with appropriate command line parameters and options by several Jetson Linux utilities and services, such as OTA update. NVIDIA provides a default rootfs updater named which is in the distribution archive ota_tools_<rel>_aarch64.tbz2.

The default rootfs updater’s usage is:

$ [-p <devnode>] [-d <workdir>] <image>


  • <devnode> is the device node path of the rootfs partition, for example, /dev/mmcblk0p1.

  • <workdir> is the path of the OTA work directory, for example, /ota_work.

  • <image> is the path of the rootfs image, for example, /ota_work/system.img.

If you create a customized rootfs image, you must specify a rootfs updater that can process that image. The rootfs updater you specify must expect the same arguments and options as Your updater may use these arguments and options or not, depending on your specific needs.