Introduction

Welcome! Here you’ll find some useful pages and notes on using the meta-tegra layer in your project. See the linked pages to have a look around! You may want to start with this page for information on which branches support which platforms and L4T releases.

If you are a new to the platform and don’t have a specific set of layers you plan to use with meta-tegra, or if you are just interested in trying meta-tegra for the first time as quickly as possible, we highly recommend checking out tegra-demo-distro as a starting point. See the README there for instructions to build one of several demo images which demonstrate the capabilities of meta-tegra and companion layers.

For real-time communication, the OE4T project uses https://gitter.im/OE4T/community

See apps at https://gitter.im/#apps
Also available over IRC - see https://gitlab.com/gitterHQ/irc-bridge/-/wikis/Client-configuration for client configuration details

Ignore any historical references to slack as this repository is no longer available.

See the thread at https://github.com/OE4T/meta-tegra/discussions/515 for monthly meeting schedules.

Finally, see this page for information about contributing to the project as well as information about testing and test coverage. This project is built and supported by volunteers and we greatly appreciate your participation.

OpenEmbedded/Yocto BSP layer for NVIDIA Jetson Modules

Jetson Linux release: R39.2.0 JetPack release: 7.2

Boards supported:

Jetson AGX Thor development kit
Jetson AGX Orin development kit
Jetson Orin NX 16GB (p3767-0000) in Xavier NX (p3509) carrier
Jetson Orin NX 16GB (p3767-0000) in Orin Nano (p3768) carrier
Jetson Orin Nano development kit
Jetson AGX Orin Industrial 64GB (P3701-0008) in Orin AGX (P3737) carrier

This layer depends on: URI: https://git.openembedded.org/openembedded-core branch: wrynose LAYERSERIES_COMPAT: wrynose

See this page for information about changes in this release.

Getting Help

Our documentation is available here. You can also find documentation in Markdown form in the docs directory.

For general build issues or questions about getting started with your build setup please use the Discussions tab of the meta-tegra repository:

Use the Ideas category for anything you’d like to see included in the layer or the wiki content.
Use the Q&A category for questions about the layer, recipes, etc.
Use the “Show and Tell” category for any projects you’d like to share which are related to the layer.
Use the General channel for anything that doesn’t fit well into the categories above, and which doesn’t relate to a build or runtime issue with Yocto/OE builds.

Reporting Issues

Use the Issues tab in meta-tegra for reporting build or runtime issues with Tegra yocto build targets. When reporting build or runtime issues, please include as much information about your environment as you can. For example, the target hardware you are building for, branch/version information, etc. Please fill in the provided bug template when reporting issues.

We are required to provide an e-mail address, but please use GitHub as described above, instead of sending e-mail to oe4t-questions@madison.systems.

Contributing

Please see CONTRIBUTING.md for information on submitting patches to the maintainers.

Contributions are welcome!

Currently maintained branches

See this page for the most up-to-date list.

Flashing Basics

As of L4T R39.2.0, all initial flashing is performed by “RCM booting” (booting over a USB link while the device is in ReCovery Mode) a specialized Linux image that reads partition content over the USB link from the host and writes it to the correct location. The underlying mechanism is different for Orin family vs. Thor family modules, but the end result is similar.

Differences from stock Jetson Linux flashing

There are several differences between Jetson Linux and an operating system built using the OpenEmbedded/Yocto Project tools, plus there are some differences in the way flashing is implemented between the two environments.

Jetson Linux flashing

Jetson Linux is comprised of a collection of pre-built binary artifacts. The flashing process contacts the device to identify which specific binaries should be used, assembles them, then writes them to the device.
Jetson Linux flashing scripts expect you to have your current working directory at the top-level Linux_for_Tegra directory of the Jetson Linux/L4T kit, and to find the artifacts to flash under that directory.
The Jetson Linux flashing scripts are expected to be run under specific, supported Linux environments, and can, more or less, require any available package to be installed. In addition, they expect to run on a developer’s workstation, and so can make changes to the host system’s networking configuration, or other system-level changes, and expect you to run all scripts under sudo to allow that.

OE/Yocto flashing

OE/Yocto builds are configured for a specific machine (i.e., a specific model of Jetson module or dev kit). Some of the binary selection that happens during flashing with Jetson Linux instead happens at build time.
The tegraflash image type provided in the meta-tegra layer attempts to package nearly everything you need to perform the flashing of your build into a tarball that you can unpack and use anywhere.
The scripts provided by the meta-tegra layer attempt to minimize the number of additional dependencies on external packages, and should be usable with any recent-vintage Linux distribution.

Prerequisites

Before you get started, you will need:

A suitable USB cable. All Orin and Thor family development kits have a USB-C connector for the USB-OTG port. You don’t need to have USB-C on your development host, though.
A free USB port on your development host. Random failures may occur if you connect via an external hub.
The dtc command (package device-tree-compiler on Debian/Ubuntu systems)
The cpp command (from the GNU toolchain, package cpp on Debian/Ubuntu systems)
The bash shell and a recent-vintage Python 3 installation are also needed for the scripts.
The .tegraflash-tar.zst package for your target machine, generated from a Yocto build.

Additional tools for Orin flashing:

For Orin targets, you will also need:

The sgdisk command (from the gdisk/gptfdisk package)
The udisksctl command (part of the udisks2 package)
The bmaptool command (part of the bmap-tools package)

Note that bmaptool isn’t strictly required, but without it flashing even a moderately large rootfs image will take an extremely long time.

You should also disable automatic mounting of removable media in your desktop settings. On recent Ubuntu (GNOME), go to Settings -> Removable Media, and check the box next to “Never prompt or start programs on media insertion.” You may also need to update the /org/gnome/desktop/media-handling/automount setting via dconf. Check the setting with:

$ dconf read /org/gnome/desktop/media-handling/automount

If it reports true, set it with:

$ dconf write /org/gnome/desktop/media-handling/automount false

For Ubuntu 24.04, use gsettings, and also disable automount-open:

$ gsettings set org.gnome.desktop.media-handling automount false
$ gsettings set org.gnome.desktop.media-handling automount-open false

Additional tools for Thor flashing:

NVIDIA implemented a different flashing process for the Thor module family and provides tools for it in the L4T kit. This same set of tools is also used for flashing Thor-family modules with Yocto/OE builds. Note, however, that if you are flashing a module that has been fused for secure boot, the scripts currently expect the xmllint command (from package libxml2-utils).

Serial console access

While not required, having a serial console connection is very helpful for troubleshooting flashing issues.

AGX Orin development kits have a USB micro-B port that can be directly connected to your development host, exporting CDC-ACM serial connections over USB.
AGX Thor development kits have a USB type-C port hidden under the lid above the ports on the back of the unit. Serial connections are exported via CDC-ACM over USB.
The Orin Nano development kit has a “button header” connector that exposes 3.3V TTL UART signals. A USB-serial adapter can be used to connect these to a modern PC.

The initrd-based flashing process

Step 1 - Unpack the tegraflash tarball

To begin, unpack the .tegraflash-tar.zst file that was created by your image build into an empty directory. For example:

$ MACHINE=jetson-orin-nano-devkit-nvme bitbake demo-image-base
$ mkdir -p $HOME/scratch/flashing
$ cd $HOME/scratch/flashing
$ tar xf $BUILDDIR/tmp/deploy/images/jetson-orin-nano-devkit-nvme/demo-image-base-jetson-orin-nano-devkit-nvme.tegraflash-tar.zst

Step 2 - Put the target in recovery mode

Next, make sure your target device is in recovery mode, with the USB OTG port connected to your host machine. You can use the command

$ lsusb -d 0955:

to check this.

Step 3 - Run the script

$ ./initrd-flash

By default, the script flashes both the boot firmware to the QSPI flash and the rootfs to the external drive (or SDcard, for the stock Orin Nano dev kit). Flashing the boot firmware can take a long time, however, and isn’t usually needed after the first flashing, so you can save time by adding the --external-only flag to skip the boot firmware update. Alternatively, you can write just the boot firmware by specifying the --qspi-only option.

Step 4 - Reboot the device (Thor only)

For Thor-family devices, you must power cycle or reset the target after flashing is done.

SDcard/External drive writing (Orin only)

For the Orin Nano development kit where you use the SDcard slot, or any Orin target where you use either a USB or NVMe external drive for the rootfs partition, you can use initrd flashing once (to ensure the boot firmware is at the correct version), then use either the ./dosdcard.sh or ./doexternal.sh script to write to a storage device that is directly connected to your host. These scripts run the flashing helper script to assemble the partitions for the SDcard or external storage device, then runs a script to write those partitions to a storage device.

The dosdcard.sh script is created only for Orin Nano dev kit targets, since that is the only system that has an SDcard slot. To use it, insert a good-quality SDcard (preferably 32G or larger) into an SDcard reader/writer on you host, and run ./dosdcard.sh /dev/sdXXX or sudo ./dosdcard.sh /dev/sdXXX, specifying the actual name of your SDcard reader/writer device for /dev/sdXXX. The script will prompt you to confirm that you want to overwrite the contents of the card; you can add the -y option to skip the confirmation.

The doexternal.sh script is created for targets that are configured to boot off external (NVMe or USB) storage. To use this script, connect the storage device that will be used in your Jetson system to a suitable interfacde on your host, and run ./dosdcard.sh /dev/sdXXX or sudo ./dosdcard.sh /dev/sdXXX, specifying the actual name of the storage device for /dev/sdXXX. The script will prompt you to confirm that you want to overwrite the contents of the card; you can add the -y option to skip the confirmation.

WARNING Be absolutely sure that the device name you specify is correct! Do not accidentally erase/overwrite filesystems on your host system!

General Troubleshooting Tips/Suggestions

Once you have it set up properly for your target hardware, the flashing process should “just work” most of the time. Getting that initial setup right can sometimes be difficult, and the low-level tools used by the scripts often generate messages with confusing or undocumented error codes.

Where to find information about the flashing process

The initrd-flash script typically displays just high-level status. If it fails, look in the log.initrd-flash.DATE-TIME-STAMP file that it creates (the specific name is displayed when the script is finished).
For Thor-family flashing, the initrd-flash script hands off control to the NVIDIA “unified” flashing script. Adding the --debug (or -D) option to initrd-flash enables more-verbose debug logging for those scripts, which can help with troubleshooting.
Monitor your host’s kernel logs during the flashing process. USB issues can show up as kernel warnings.
If you can, monitor the serial console of the target device during the flashing process, so you can see what is happening on the device.

USB communication errors

Sometimes USB problems are transient, and just power-cycling the target device and re-running the initrd-flash script will work.
Try swapping USB cables/ports, and ensure you are using a high quality cable.
If you are flashing after a soft reboot, try power cycling the device/entering tegraflash mode from power on instead of using reboot forced-recovery. There have been issues with the boot firmware not properly setting up for recovery mode after a soft reboot.

Permissions failures

Try running the entire flashing script under sudo, especially if any error message mention permissions (although the script should be using sudo where it’s needed).

Storage layout issues

Suspect issues with partition table, especially if you’ve modified the partition table or increase sizes of partitions. Obscure errors like cp: cannot stat 'signed/*': No such file or directory typically mean you’ve got some problem with your custom partition table and/or target storage device size.

Host environment issues

Use an x86-64 Linux host system for flashing, and always run the flashing scripts natively on that host. The low-level tools that NVIDIA provides are binary-only, and may not operate on ARM or other non-x86 hosts.
Virtualization can interfere with the USB communication used by the flashing tools, so as mentioned above, run the flashing scripts natively, not in a virtual machine.
The TLP package (sometimes installed on notebooks/laptops to save battery power) can interfere with the flashing process. Use sudo apt remove tlp and reboot your host computer to remove it before flashing.
Use the tar command to unpack the tegraflash tarball, rather than a graphical file management tool. There have been issues in the past with file corruption caused by graphical tools.

Try alternative setups

The demo distro is built frequently, and images from those builds are tested often, so if you are unsure about how your custom build environment might be affecting the flashing process, try building and flashing a demo-base-image from the demo distro for comparison. You can also compare against flashing using stock Jetson Linux/JetPack/SDK Manager.

OE4T Contributor Guide

See the CONTRIBUTING.md file for details about contributing to this repository.

In addition to code and documentation contributions we greatly appreciate help in the form of testing.

Please see the Release and Validation sheet for a list of current test coverage and test cases. Request edit on this sheet if you’d like to help contribute.

CONTRIBUTING

Thank you for contributing to the OE4T project! Your contributions are greatly appreciated!

Submitting Code Changes

The OE4T project repositories follow the OpenEmbedded Guidelines. Please review these when proposing your Pull Request. A few highlights and additional requirements:

Please submit issues or pull requests through Github. Only rebase and squash commits are used for PRs, so if you have a PR that is outstanding for a long time, please keep your branch up to date by rebasing your changes, rather than merging.
Group commits based on their functionality and components changed. For the first line, use something like component: Short Summary to describe your change where component refers to a specific software component being changed.
Please try to make incremental changes with multiple commits, rather than “big bang” single commits with changes spread across multiple components.
Add a Signed-off-by: line to your commit, using git commit -s or a pre-commit hook like the one setup with this script, using your real name and e-mail address (no anonymous contributions, please). This indicates that you have the right to submit the patch per the Developer’s Certificate of Origin in the next section.
Target the master branch for pull requests unless your change is specific to an earlier branch.

Developer’s Certificate of Origin

By making a contribution to this project, I certify that:

The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
The contribution was provided directly to me by some other person who certified (1), (2) or (3) and I have not modified it.
I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

(Adapted from the Linux kernel’s certificate of origin.)

Submitting Documentation Changes

Documentation is served as an mdbook based on the content in the docs directory. Please open a PR for documentation changes on the relevant branch. Please target the master branch for docs changes unless your changes are specific to older branches. Documentation content in older branches are based on a snapshot at branch time and may be out of date.

The meta-tegra layer includes MACHINE definitions for NVIDIA’s Jetson development kits. If you are developing a custom device using one of the Jetson modules with, for example, a custom carrier board, or you just want to modify the default boot-time configuration (pinmux, etc.) for an existing development kit as a separate MACHINE in your own metadata layer, you may need to supply a MACHINE-specific file for your builds.

IMPORTANT: For any custom carrier board/hardware design, make sure you consult the appropriate Platform Adaptation and Bring-Up Guide document available at the Jetson Software Documentation Site to get all the details on how to customize the pinmux configuration and other low-level hardware configuration settings. Failing to provide the correct settings could damage your device.

Boot-time hardware configuration and boot flash programming is particularly complicated for Jetson modules, and varies substantially between models. Consult a recent version of the L4T Driver Package Documentation, particularly the “BSP Customization” and “Bootloader” chapters, for background information. As mentioned above, the Platform Adaptation documentation is also a good reference.

NOTE: Due to restrictions in the implementation of bootloader update payloads, the length of your custom MACHINE name should be 31 characters or less.

Jetson Orin

This guide is based on Jetson Linux R35.4.1 so change bbappend names accordingly if you use a different release. Occurences of ${machine} should be replaced by your machine name.

Create a new machine config

Create a new Machine configuration at conf/machine/${machine}.conf in your layer. For guidance on what it should contain look at any of the machine configurations in meta-tegra.

Create a new flash config

As of PR https://github.com/OE4T/meta-tegra/pull/1386 (first introduced in the scarthgap release branch), flashvars files are now generated by the tegra-flashvars recipe from machine configuration variables instead of being manually checked in.

Define the flash configuration in your ${machine}.conf machine configuration file using TEGRA_FLASHVAR_* variables. For example:

TEGRA_FLASHVAR_PINMUX_CONFIG ?= "tegra234-${machine}-pinmux.dtsi"
TEGRA_FLASHVAR_PMC_CONFIG ?= "tegra234-${machine}-padvoltage-default.dtsi"

Review the content of the TEGRA_FLASHVAR variables used with the MACHINE you are basing your custom machine on, and/or review the flashvars file generated by a build of the MACHINE you are basing your custom MACHINE on in order to decide which variables need customization.

The tegra-flashvars recipe will automatically generate the flashvars file from these variable settings. If you need to provide custom files referenced by these variables, use the method described in Add pinmux dtsi files.

Add pinmux dtsi files

Generate the pinmux dtsi files with the Nvidia pinmux Excel sheet (or this one for Orin AGX). Rename the resulting files to start with tegra234- (Otherwise meta-tegra has issues handling them.) and convert line endings to Unix using dos2unix. Copy the files to recipes-bsp/tegra-binaries/tegra-flashvars.

NOTE: If you manually rename your generated DTSI files, you may need to modify the #include statement on line 35 of your -pinmux.dtsi file, as it has the original filename for the -gpio-default.dtsi file hardcoded.

Install the files with following tegra-bootfiles_35.4.1.bbappend:

# Hack: The fetch task is disabled on this recipe, so the following is just for the task signature.
FILESEXTRAPATHS:prepend := "${THISDIR}/${BPN}:"
SRC_URI:append:${machine} = "\
    file://tegra234-${machine}-gpio-default.dtsi \
    file://tegra234-${machine}-padvoltage-default.dtsi \
    file://tegra234-${machine}-pinmux.dtsi \
"

# Hack: As the fetch task is disabled for this recipe, we have to directly access the files."
CUSTOM_DTSI_DIR := "${THISDIR}/${BPN}"
do_install:append:${machine}() {
    install -m 0644 ${CUSTOM_DTSI_DIR}/tegra234-${machine}-gpio-default.dtsi ${D}${datadir}/tegraflash/
    install -m 0644 ${CUSTOM_DTSI_DIR}/tegra234-${machine}-padvoltage-default.dtsi ${D}${datadir}/tegraflash/
    install -m 0644 ${CUSTOM_DTSI_DIR}/tegra234-${machine}-pinmux.dtsi ${D}${datadir}/tegraflash/
}

(Don’t forget to replace ${machine} with your machine name.)

Then update the TEGRA_FLASHVAR_* settings in your ${machine}.conf to reference your custom files:

TEGRA_FLASHVAR_PINMUX_CONFIG should reference your tegra234-${machine}-pinmux.dtsi
TEGRA_FLASHVAR_PMC_CONFIG should reference your tegra234-${machine}-padvoltage-default.dtsi

(Optionally) disable board EEPROM usage

As explained in the Platform Adaptation and Bring-Up Guide by Nvidia, you might want to disable the usage of the board EEPROM. For that, create a custom version of the file referenced by TEGRA_FLASHVAR_MB2BCT_CFG in your machine configuration and modify it according to the Nvidia guide. Include this new file in Yocto using a tegra-bootfiles_35.4.1.bbappend as described in Add pinmux dtsi files, then update TEGRA_FLASHVAR_MB2BCT_CFG in your ${machine}.conf to reference the new file name.

Use a custom device tree

See Custom Device Tree and apply the described changes to your ${machine}.conf.

Jetson AGX Thor

Thor (Tegra264) custom machine definitions follow a similar pattern to Orin (Tegra234). Replace occurrences of ${machine} below with your machine name.

Create a new machine config

Create conf/machine/${machine}.conf in your layer. Use one of the existing Thor machine configurations in meta-tegra (e.g., jetson-agx-thor-t4000.conf) as a starting point. Your config should require the appropriate agx-thor-*.inc or tegra264.inc include.

Key Thor-specific variables to be aware of:

PARTITION_LAYOUT_RCMBOOT / PARTITION_LAYOUT_RCMBOOT_DEFAULT — partition layout XML used for the RCMBoot flashing stage. Thor uses a separate UEFI image for this stage. The default is flash_l4t_t264_rcmboot.xml.
TEGRA_RCM_EDK2_CONFIGURATION — controls which EDK2 firmware build is used for RCMBoot. Defaults to "minimal". If you set this to the same value as TEGRA_EDK2_CONFIGURATION, the main UEFI build is reused and no separate RCMBoot UEFI build is required.
EMC_BCTS — a comma-separated list of EMC BCT files for the flash process. This extends EMC_BCT to support multiple entries when needed for different memory configurations.

RCMBoot UEFI

Unlike Orin, Thor requires a UEFI firmware image specifically for the RCMBoot stage. The edk2-firmware-tegra-rcmboot recipe builds this from EDK2 sources. If you cannot or do not wish to build from source, the edk2-firmware-tegra-rcmboot-prebuilt recipe provides a prebuilt binary. To use the prebuilt binary, add the following to your machine configuration or local.conf:

PREFERRED_PROVIDER_edk2-firmware-tegra-rcmboot = "edk2-firmware-tegra-rcmboot-prebuilt"

See bootloader/uefi_bins/README_uefi.txt in the L4T BSP kit for information on the UEFI sources.

Add pinmux and BCT files

Unlike Orin, which uses .dtsi kernel device tree fragments for pinmux configuration, Thor uses MB1 BCT DTS files (.dts) for all boot-time hardware configuration. These are generated from the NVIDIA pinmux spreadsheet for Thor and have a tegra264-mb1-bct- naming convention in the reference BSP.

In your machine configuration, set the relevant TEGRA_FLASHVAR_* variables to the filenames of your custom BCT DTS files. The two most commonly customized are:

TEGRA_FLASHVAR_PINMUX_CONFIG ?= "tegra264-mb1-bct-pinmux-${MACHINE}.dts"
TEGRA_FLASHVAR_PMC_CONFIG    ?= "tegra264-mb1-bct-padvoltage-${MACHINE}.dts"

Then provide those files via a tegra-bootfiles_39.2.0.bbappend in your layer:

FILESEXTRAPATHS:prepend := "${THISDIR}/${BPN}:"
SRC_URI:append:${machine} = "\
    file://tegra264-mb1-bct-pinmux-${MACHINE}.dts \
    file://tegra264-mb1-bct-padvoltage-${MACHINE}.dts \
"

CUSTOM_BCT_DIR := "${THISDIR}/${BPN}"
do_install:append:${machine}() {
    install -m 0644 ${CUSTOM_BCT_DIR}/tegra264-mb1-bct-pinmux-${MACHINE}.dts ${D}${datadir}/tegraflash/
    install -m 0644 ${CUSTOM_BCT_DIR}/tegra264-mb1-bct-padvoltage-${MACHINE}.dts ${D}${datadir}/tegraflash/
}

Other TEGRA_FLASHVAR_* variables (e.g. GPIOINT_CONFIG, MB2BCT_CFG, PMIC_CONFIG) may also require custom files depending on your carrier board design. Consult the Platform Adaptation and Bring-Up Guide for Thor for the full list of configuration files and their purpose.

Use a custom device tree

See Custom Device Tree and apply the described changes to your ${machine}.conf.

Customizing the kernel

For custom hardware, you’ll probably need to modify the kernel in at least one of the following ways:

Custom kernel configuration
Custom device tree
Adding patches

Starting with the L4T R32.3.1-based branches, you can use the Yocto Linux tools to apply patches and configuration changes during the build, although it may be simpler to fork the linux-tegra-4.9 repository to apply patches, and supply your own defconfig file for the kernel configuration. Having your own fork of the kernel sources should also be easier for creating a custom device tree. (You should also set the KERNEL_DEVICETREE variable in your machine configuration file appropriately.)

Custom MACHINE definitions for existing hardware

If you need to define an alternate MACHINE configuration for an NVIDIA Jetson development kit without altering the boot-time configuration files for hardware initialization, you can have your MACHINE reuse the existing files in meta-tegra. For example, let’s say you want to create tegraflash packages for the Jetson-TX2 development kit for both the default cboot->U-boot->Linux boot sequence as well as for booting directly from cboot to Linux, without U-Boot. In your BSP or distro layer, you could add a machine configuration file called, for example, conf/machine/jetson-tx2-cboot.conf that looks like this:

MACHINEOVERRIDES = "jetson-tx2:${MACHINE}"
require conf/machine/jetson-tx2.conf
PACKAGE_EXTRA_ARCHS_append = " jetson-tx2"
PREFERRED_PROVIDER_virtual/bootloader = "cboot-prebuilt"

This would override the bootloader settings in the default jetson-tx2 configuration to use cboot instead of U-Boot, but otherwise reuse all of the MACHINE-specific packages, files, and settings for the jetson-tx2 MACHINE in meta-tegra.

For Jetson Xavier NX based machine types - jetson-xavier-nx-devkit and jetson-xavier-nx-devkit-emmc, the conf/machine/custom-machine.conf would look like this:

require conf/machine/jetson-xavier-nx-devkit-emmc.conf
MACHINEOVERRIDES = "cuda:tegra:tegra194:xavier-nx:jetson-xavier-nx-devkit-emmc:${MACHINE}"
PACKAGE_EXTRA_ARCHS_append = " jetson-xavier-nx-devkit-emmc"

Custom Device Tree

In many cases it is desirable to avoid forking or patching the kernel sources. The devicetree bbclass can be used to create a custom dtb. There’s an example in tegra-demo-distro documented at Using-device-tree-overlays which accomplishes this for recent branches.

Custom Partitioning

See Redundant-Rootfs-A-B-Partition-Support for suggestions regarding defining partition layout files for your MACHINE.

This page describes one mechanism for enabling disk encryption on meta-tegra, using the notes from Islam Hussein in this thread on matrix.

The encryption happens as a post-process initiated manually after the build.

Yocto changes

Modify your partition xml to set ‘encrypted’ to true on the corresponding partition, as described in the NVIDIA Disk Encryption Documentation.

<partition name="data-partition" type="data" encrypted="true">

Choose a different init script to be used in initramfs which uses luks-srv-app and disable it totally after that to prevent further use. See code snippet below. For the “context”, refer to the build changes section below.

__l4t_enc_root_dm="l4t_enc_root";
__l4t_enc_root_dm_dev="/dev/mapper/${__l4t_enc_root_dm}"
eval nvluks-srv-app -g -c "<context>" | cryptsetup luksOpen /dev/nvme0n1p${current_rootfs} ${__l4t_enc_root_dm}

Build changes

Add a bash script to be called manually after finishing yocto build. The script will go to the path of the build, extract it in a temp directory. mount the rootfs and open it. Then it will make a luks-storage (And that’s why I couldn’t build it inside yocto) The problem is that when you want to open the luks using crypto you have to access device mapper which requires privileged access which yocto doesn’t have

Store the size of rootfs which is written in xml it have to be the same and then create luks drive with the same size.
To generate the password you’ll need to run gen_ekb.py
You’ll have to to write down dummy uuid which is the context used in the code snippet above. (context will be used in two places generating pass to encrypt rootfs and generating the pass access it.)
One way is to use a generic password which doesn’t need ecid. So the same key will be used for all of my devices.

GEN_LUKS_PASS_CMD="tools/gen_luks_passphrase.py"
genpass_opt=""
genpass_opt+=" -k tools/ekb.key "
genpass_opt+=" -g "
genpass_opt+=" -c '${__rootfsuuid}' "

GEN_LUKS_PASS_CMD+=" ${genpass_opt}"

truncate --size ${__rootfs_size} ${__rootfs_name}
eval ${GEN_LUKS_PASS_CMD} | sudo cryptsetup \
       --type luks2 \
       -c aes-xts-plain64 \
       -s 256 \
       --uuid "${__rootfsuuid}" \
       luksFormat \
       ${__rootfs_name}
eval ${GEN_LUKS_PASS_CMD} | sudo cryptsetup luksOpen ${__rootfs_name} ${__l4t_enc}
sudo mkfs.ext4 /dev/mapper/${__l4t_enc}
sudo mount /dev/mapper/${__l4t_enc} ${__enc_rootfs_mountpoint}
sudo mount  ${__original_rootfs} ${__rootfs_original_mountpoint}
sudo tar -cf - -C ${__rootfs_original_mountpoint} . | sudo tar -xpf - -C ${__enc_rootfs_mountpoint}
sleep 5
sudo umount ${__enc_rootfs_mountpoint}
sudo cryptsetup luksClose ${__l4t_enc}
sudo umount ${__rootfs_original_mountpoint}

Avoiding sudo

The initrd-flash script can be run normally, and will invoke the tools that absolutely require root access (specifcally bmaptool and, for Thor-family modules, the NVIDIA unified flashing script) under sudo for you if you are not already running as the root user.

This page has suggestions for configuring your system to help with keeping sudo use to a minimum.

Add yourself to some useful groups

Disk devices are usually set up such that the disk group has full access to them. Adding yourself to that group can help, particularly for formatting/partitioning storage devices.

The plugdev group, while considered “legacy,” can still be used for access to USB-connected devices. Adding yourself to that group can help with the USB flashing process.

Add udev rules to enable non-root access

Add the following udev rules to your configuration (usually to a file under /etc/udev/rules.d):

# Jetson AGX Orin main CPU
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7023", GROUP="plugdev", TAG+="uaccess"
# Jetson AGX Orin (32G) main CPU
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7223", GROUP="plugdev", TAG+="uaccess"
# Jetson AGX Orin/Thor supervisor CPU
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7045", GROUP="plugdev", TAG+="uaccess"
# Jetson Orin NX (16G)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7323", GROUP="plugdev", TAG+="uaccess"
# Jetson Orin NX (8G)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7423", GROUP="plugdev", TAG+="uaccess"
# Jetson Orin Nano
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7523", GROUP="plugdev", TAG+="uaccess"
# Jetson Orin Nano 4GB
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7623", GROUP="plugdev", TAG+="uaccess"
# Jetson AGX Thor dev kit
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7026", GROUP="plugdev", TAG+="uaccess"
# Jetson AGX Thor P3834-0001
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0955", ATTRS{idProduct}=="7326", GROUP="plugdev", TAG+="uaccess"

The GROUP assignment is for legacy plugdev-style access; the TAG addition is for the newer systemd-udevd method for granting user access.

Add polkit rules

This is for Orin-family flashing over USB, when your host system uses of the udisks2 package for mediating access to removable storage devices, such as Ubuntu. The following commands install a configuration file to enable the disk group to perform some disk operations through udisks2 that might otherwise be denied or result in prompting for your login password:

mkdir -p /var/lib/polkit-1/localauthority/50-local.d/
cat << EOF > /var/lib/polkit-1/localauthority/50-local.d/com.github.oe4t.pkla
[Allow Mounting for Disk Group]
Identity=unix-group:disk
Action=org.freedesktop.udisks2.filesystem-mount
ResultAny=yes

[Allow Power Off Drive for Disk Group]
Identity=unix-group:disk
Action=org.freedesktop.udisks2.power-off-drive
ResultAny=yes
EOF
chmod 644 /var/lib/polkit-1/localauthority/50-local.d/com.github.oe4t.pkla
systemctl restart polkit

Notes on integrating the NVIDIA container runtime on Jetson platforms.

Layers required

In addition to the OE-Core and meta-tegra layers, you will need the meta-virtualization layer and the meta-oe, meta-networking, and meta-python layers from the meta-openembedded repository.

Configuration

Add virtualization to your DISTRO_FEATURES setting.

Building

Add nvidia-container-toolkit to your image to enable GPU-accelerated containers.
See the NVIDIA Container Toolkit documentation for details on runtime configuration and usage.
The Docker containers that NVIDIA supplies do not bundle most hardware-specific libraries, but expect them to be provided by the host OS. Be sure to include TensorRT, cuDNN, and/or other JetPack components in your image if you expect to run containers that need them.
For containers that use GStreamer, include the Jetson-specific GStreamer plugins you may need. See Tegra-specific GStreamer plugins for the available plugin recipes.
Consult the documentation in the branch of meta-virtualization you are using for information on how to configure Docker to register the nvidia runtime to be available at boot time, to avoid having to run the nvidia-ctk tool and restart the Docker service on every boot.

NVIDIA provides partition layouts which support Root File System Redundancy, whereby bootloader slots and rootfs slots are paired together to support automatically selecting the associated root filesystem partition at boot to match the selected bootloader slot. The selected bootloader slot, a or b, will select the corresponding rootfs slot a or b.

When paired with the UEFI capsule update feature, a redundant root filesystem supports switching the root filesystem, kernel, and kernel dtb to match the updated bootloader slot. When paired with an update tool which can update kernel, dtb and rootfs partitions (swupdate, rauc, mender, or others) the process of performing capsule update can also switch to an updated rootfs through the redundant rootfs feature.

If you have the available root filesystem space to support redundant rootfs, using a redundant partition layout at the outset of your project might give you the option to support updates later without a repartition (or tegraflash) of the device.

Selecting Redundant Root Filesystem Partition Layout

By default, both the stock NVIDIA provided Jetpack image as well as OE4T images use the non redundant partition layouts.

To use NVIDIA provided redundant partition layouts and automatically apply the necessary dtb changes performed by NVIDIA’s flash.sh script, on branches which include https://github.com/OE4T/meta-tegra/pull/1428, you simply need to set USE_REDUNDANT_FLASH_LAYOUT_DEFAULT = "1" in your distro configuration, custom MACHINE configuration, (or local.conf). This is currently supported for most targets. See the notes below for limitations.

This configuration is set as the default for all supported targets when building with tegra-demo-distro.

Testing Root Filesystem A/B Slot Switching

See the sequence in https://github.com/OE4T/meta-tegra/pull/1428 to validate root slot and boot slot switching.

Setting Up a Custom MACHINE

Use these variables to setup a MACHINE or distro with support for redundant flash layouts:

USE_REDUNDANT_FLASH_LAYOUT_DEFAULT - Set to "1" in your distro layer to use redundant flash layouts for any supported MACHINEs. Set to "0" to use default non-redundant layouts from NVIDIA when using tegra-demo-distro (USE_REDUNDANT_FLASH_LAYOUT_DEFAULT is the default for master branch builds of tegra-demo-distro).
ROOTFSPART_SIZE_DEFAULT - Set with the size of the root filesystem partition when using the default (non-redundant) flash layout. This size will be automatically divided by 2 when USE_REDUNDANT_FLASH_LAYOUT is selected.
PARTITION_LAYOUT_TEMPLATE_DEFAULT - set with the partition layout to use with the default (non, external, non redundant) flash layout, for instance custom_layout.xml. Either provide a custom_external_layout_rootfs_ab.xml file or define PARTITION_LAYOUT_TEMPLATE_REDUNDANT with your redundant file.
PARTITION_LAYOUT_TEMPLATE_DEFAULT_SUPPORTS_REDUNDANT - Set to "1" if no PARTITION_LAYOUT_TEMPLATE_REDUNDANT is required for this MACHINE (and the same template is used for redundant or non redundant builds).
PARTITION_LAYOUT_EXTERNAL_DEFAULT - Set with the default partition layout when using an external device (sdcard or NVMe) for rootfs partition storage, for instance custom_external_layout.xml. Either provide a custom_external_layout_rootfs_ab.xml file or define PARTITION_LAYOUT_EXTERNAL_REDUNDANT with your redundant file.
HAS_REDUNDANT_PARTITION_LAYOUT_EXTERNAL - Set to "0" if your MACHINE does not support a PARTITION_LAYOUT_EXTERNAL_REDUNDANT and therefore does not support USE_REDUNDANT_FLASH_LAYOUT_DEFAULT

Overriding BSP Layer Changes

Use ROOTFSPART_SIZE, PARTITION_LAYOUT_EXTERNAL and PARTITION_LAYOUT_TEMPLATE as done before changes in https://github.com/OE4T/meta-tegra/pull/1428, to provide your own implementation outside the BSP layer and ignore the setting of USE_REDUNDANT_FLASH_LAYOUT.

Jetson secure boot support in L4T R35.2.1 implements a different chain of trust from what was present in the L4T R32 releases:

The Trusty secure OS has been replaced by OP-TEE, which allows for dynamic loading of trusted applications (TAs) from the non-secure world. TAs must be signed, and the public key used for checking the signature is compiled into the OP-TEE OS.
The cboot bootloader has been replaced by UEFI, which uses its own set of keys for validating signatures on binaries that it loads (Linux kernel, EFI applications, and EFI capsules).

NOTE NVIDIA made some changes to the UEFI bootloader in L4T R35.5.0 that require that an “authentication key” be programmed into the Encrypted Key Block on secured devices. If you are updating your secured device from an earlier R35.x release to R35.5.0, you must update the EKB on the device with the added key. See this developer forum thread for more information.

Getting started

Start by reading the Secure Boot section of the Jetson Linux Developer’s Guide.

The sections below cover specifics of how secure boot and signing are implemented for OE/Yocto builds with meta-tegra.

Bootloader signing

Setting fuses for secure boot

Follow the instructions in the NVIDIA documentation for generating keys and burning secure boot fuses for your Jetson device. Be warned that burning the fuses is a one-time operation, so be extremely careful. You could render your Jetson permanently unbootable if something goes wrong during the fuse burning process.

Build-time bootloader signing

If you have the bootloader signing and encryption key files available, you can add the following setting to your local.conf to create signed boot images and BUP packages:

TEGRA_SIGNING_ARGS = "-u /path/to/pkc-signing-key.pem -v /path/to/sbk.key --user_key /path/to/user.key"

These arguments parallel the ones used with the L4T flash.sh script for signing:

The -u option takes the path name of the RSA private key for PKC signing.
The -v option takes the path name of the SBK key used for encrypting the binaries loaded at boot time.
The --user_key option takes the path name of the encryption key you create for use with the NVIDIA sample OP-TEE TAs.

Note that with R35.2.1, the --user_key encryption key is used only for the XUSB firmware. Starting with R35.3.1, the user encryption key is not used for any of the boot firmware.

Build-time bootloader signing will be performed on the boot-related files in the tegraflash package for flashing, as well as the entries in any bootloader update payloads (BUPs).

Post-build signing

You can elect to perform bootloader signing outside of the build process by adding the -u, -v, and --user_key options when running the doflash.sh or initrd-flash script during flashing of your tegraflash package. For BUP generation, add those options when running the generate_bup_payload.sh script to have the bootloader components signed.

UEFI Secure Boot

To enable UEFI secure boot support, start by generating the PK, KEK, and DB keys and related configuration files, as described in the UEFI Secure Boot section of the Jetson Linux documentation.

It should be noted that UEFI boot is not compatible with the legacy secure boot supported on Tegra devices.

Build-time UEFI signing

During the build, signing of the EFI launcher app, the kernel, and device tree files is performed automatically when the following settings are present in your build configuration:

TEGRA_UEFI_DB_KEY = "/path/to/db.key"
TEGRA_UEFI_DB_CERT = "/path/to/db.crt"

Both settings must be present, and must point to one of the DB keys you generated (you do not need the PK or KEK keys).

Post-build UEFI signing

Post-build UEFI signing is not currently supported.

Enrolling UEFI keys at build time

To enable UEFI secure boot, the PK, KEK, and DB keys you generated must be “enrolled” at boot time. On Jetson platforms, this done by adding the needed key enrollment variable settings to the bootloader’s device tree via the UefiDefaultSecurityKeys.dts file you generated when creating the keys and configuration files. For meta-tegra builds, you can supply this file by adding a bbappend for the tegra-uefi-keys-dtb.bb recipe in one of your own metadata layers, substituting variables MY_LAYER with the path to your layer and MY_UEFI_KEYS_DIR with the path to your uefi_keys directory setup after following instructions linked above

export MY_LAYER=tegra-demo-distro/layers/meta-tegrademo
export MY_UEFI_KEYS_DIR=~/uefi_keys/
mkdir -p ${MY_LAYER}/recipes-bsp/uefi
cat > ${MY_LAYER}/recipes-bsp/uefi/tegra-uefi-keys-dtb.bbappend <<'EOF'
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
EOF
mkdir -p ${MY_LAYER}/recipes-bsp/uefi/files
cp ${MY_UEFI_KEYS_DIR}/UefiDefaultSecurityKeys.dts ${MY_LAYER}/recipes-bsp/uefi/files/
echo "Copy below is optional, only needed if you plan to update your keys with a capsule update"
cp ${MY_UEFI_KEYS_DIR}/UefiUpdateSecurityKeys.dts ${MY_LAYER}/recipes-bsp/uefi/files/

Enrolling UEFI keys at runtime

The Jetson Linux documentation describes the process for enrolling UEFI keys and enabling UEFI secure boot at runtime. You will need to add some packages to your image build to make the necessary commands available. As of this writing, runtime enrollment has not been tested.

OP-TEE Trusted Application signing

OP-TEE provides a mechanism for loading TAs from the “Rich Execution Environment” (REE, another term for the normal, non-secure OS), which must be signed with a key that is known the OP-TEE OS. Read the OP-TEE documentation on TAs for more information.

By default, a development/test key from the upstream OP-TEE source is compiled in; this configuration should not be used in any production device, since the key is publicly available. You should generate a suitable RSA keypair as described in the OP-TEE documentation. For build-time signing, add a bbappend for the optee-os recipe in one of your layers. For build-time signing, your bbappend should resemble the following:

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "file://optee-signing-key.pem"
EXTRA_OEMAKE += "TA_SIGN_KEY=${WORKDIR}/optee-signing-key.pem"

Post-build signing of TAs is more difficult, since external TAs are generally packaged and installed into the root filesystem as part of the build. For that approach, though, you would include the public key file in the optee-os bbappend, and set TA_PUBLIC_KEY instead of TA_SIGN_KEY. The OP-TEE makefiles will sign TAs with the a dummy private key, but the public key you specify will be compiled into the secure OS. You will have to figure out how to re-sign the TAs with your actual private key before they get used.

Using the NVIDIA built-in sample TAs

To make use of the encryption/decryption functions NVIDIA provides by default with their OP-TEE implementation, you will need to supply an “Encrypted Keyblob” (EKB) that corresponds to the fuses you have burned on your Jetson device. See the EKB documentation in the Jetson Linux Developer’s Guide for full details. See the note at the top of this page for information about changes in L4T R35.5.0 that require the re-generation of the EKB.

The tegra-bootfiles recipe installs the default EKB from the L4T kit. If you have burned secure boot fuses on your device, you must replace this with a custom EKB that matches your fuse keys, for example by configuring the build-time EKB generation, or adding a bbappend to include keys generated outside the build.

Build-time EKB generation

The tegra-eks-image recipe can generate your custom EKB automatically during the build. Set the following variables in your local.conf (or machine configuration) to enable this:

Variable	Platform	Description
`TEGRA_EKB_OEM_K1`	Orin (Tegra234)	Path to the `OEM_K1` fuse key file
`TEGRA_EKB_OEM_KDK1`	Thor (Tegra264)	Path to the `PSC_OEM_KDK1` fuse key file
`TEGRA_EKB_SYM2`	Both	Path to the disk encryption key file (optional but recommended)
`TEGRA_EKB_AUTH`	Both	Path to the UEFI variable authentication key file

The recipe automatically selects -chip t234 or -chip t264 based on the target SOC_FAMILY. When the platform-appropriate fuse key variable is set and points to an existing file, gen_ekb.py is invoked during the build and the resulting eks.img is used instead of the default from the L4T kit.

Example local.conf entries for Orin:

TEGRA_EKB_OEM_K1 = "/path/to/oem_k1.key"
TEGRA_EKB_SYM2   = "/path/to/sym2.key"
TEGRA_EKB_AUTH   = "/path/to/auth.key"

Example local.conf entries for Thor:

TEGRA_EKB_OEM_KDK1 = "/path/to/oem_kdk1.key"
TEGRA_EKB_SYM2     = "/path/to/sym2.key"
TEGRA_EKB_AUTH     = "/path/to/auth.key"

If the fuse key variable is not set or the file does not exist, the default EKB from the L4T kit is used — this is suitable for development only and must not be used on a production device with fuses burned.

Generating a Custom EKB manually

If you need to generate the EKB outside of the build, you can run gen_ekb.py directly. The script is available in the L4T public sources tarball or on NVIDIA’s git server (choose the branch matching your L4T version).

Jetson Orin (Tegra234)

Example:

python3 gen_ekb.py -chip t234 \
    -oem_k1_key oem_k1.key \
    -in_sym_key2 sym2_t234.key \
    -in_auth_key auth_t234.key \
    -out eks_t234.img

where

oem_k1.key is the OEM_K1 key stored in the OEM_K1 fuse.
sym2_t234.key is the disk encryption key.
auth_t234.key is the UEFI variable authentication key
eks_t234.img is the generated EKB image to be flashed to the EKS partition of the device

Kernel encryption is not currently supported in meta-tegra, so do not provide the UEFI payload encryption key (using -in_sym_key).

Jetson AGX Thor (Tegra264)

Thor uses a different fuse key (PSC_OEM_KDK1 instead of OEM_K1/OEM_K2) and a different key derivation function (NIST-SP-800-108 with HMAC-SHA256). The generated EKB image is eks_t264.img (EKB version 2.1), which is not backward-compatible with the Orin format.

Example:

python3 gen_ekb.py -chip t264 \
    -oem_kdk1_key oem_kdk1.key \
    -in_sym_key2 sym2_t264.key \
    -in_auth_key auth_t264.key \
    -out eks_t264.img

where

oem_kdk1.key is the PSC_OEM_KDK1 key burned into the Thor device fuses.
sym2_t264.key is the disk encryption key.
auth_t264.key is the UEFI variable authentication key.
eks_t264.img is the generated EKB image to be flashed to the EKS partition of the device.

See the EKB documentation for the full key derivation details and additional generation parameters.

Tegra-specific GStreamer plugins

Starting with L4T R35.x (JetPack 5), the NVIDIA-specific GStreamer plugins are built individually from source as separate recipes, rather than being delivered as a single binary blob package. Each recipe below corresponds to a Yocto package that can be added to your image.

Plugin recipes

Recipe	GStreamer element(s)	Description
`gstreamer1.0-plugins-nvarguscamerasrc`	`nvarguscamerasrc`	LibArgus-based CSI camera capture source
`gstreamer1.0-plugins-nvcompositor`	`nvcompositor`	GPU-accelerated multi-input compositor
`gstreamer1.0-plugins-nvdrmvideosink`	`nvdrmvideosink`	DRM/KMS video sink
`gstreamer1.0-plugins-nveglgles`	`nvvideosink`, `nvoverlaysink`	EGL/GLES-based render sinks
`gstreamer1.0-plugins-nvipcpipeline`	`nvipcsrc`, `nvipcsink`	Inter-process GStreamer pipeline elements
`gstreamer1.0-plugins-nvjpeg`	`nvjpegdec`, `nvjpegenc`	Hardware-accelerated JPEG decode/encode
`gstreamer1.0-plugins-nvsiplcamerasrc`	`nvsiplcamerasrc`	SIPL-based camera source (R39.2.0+, requires `jetson-sipl-api`)
`gstreamer1.0-plugins-nvtee`	`nvtee`	Tegra-specific tee element
`gstreamer1.0-plugins-nvunixfd`	`nvunixfdsrc`, `nvunixfdsink`	Unix file-descriptor buffer sharing elements
`gstreamer1.0-plugins-nvv4l2camerasrc`	`nvv4l2camerasrc`	V4L2-based camera capture source
`gstreamer1.0-plugins-nvvidconv`	`nvvidconv`	Hardware video format and color-space conversion
`gstreamer1.0-plugins-nvvideo4linux2`	`nvv4l2dec`, `nvv4l2h264enc`, `nvv4l2h265enc`, etc.	V4L2-based hardware video decode and encode
`gstreamer1.0-plugins-nvvideosinks`	`nvvideosink`	NvBuf-backed video sink

Supporting packages

libgstnvcustomhelper — shared helper library used internally by several of the plugins above; pulled in automatically as a dependency
nvgstapps — sample GStreamer applications from NVIDIA demonstrating use of these plugins

Machine configuration

The MACHINE_HWCODECS variable in each machine configuration selects the hardware codec packages for that target. The GStreamer plugins above can be included individually in your image recipe, or grouped through appropriate IMAGE_INSTALL or MACHINE_EXTRA_RRECOMMENDS settings in your layer.

Camera source plugin notes

nvarguscamerasrc is the standard CSI camera source for most Jetson platforms, using the LibArgus camera API.

nvsiplcamerasrc (available from R39.2.0/JetPack 7.2 onwards) is an alternative source for cameras attached via the SIPL framework. It is built from source and depends on the jetson-sipl-api package. SIPL is typically used with more complex camera module configurations that require an ISP tuning database.

USB Device Mode Support

On the zeus and later branches (for L4T R32.2.3 and later), the l4t-usb-device-mode recipe is available to set up USB gadgets on a Jetson device for network and serial TTY access. The setup is similar to what’s provided in the L4T/JetPack BSP, except:

the scripts in the BSP under /opt/nvidia/l4t-usb-device-mode have been replaced by a combination of systemd, udev, and libusbgx configuration files;
the USB device identifier uses the Linux Foundation vendor ID; and
no mass storage gadget is created

Note that as of this writing, support for creating both an ECM gadget and an RNDIS gadget is provided, but the RNDIS gadget has not been tested.

Prerequisites

You must have the meta-oe layer from meta-openembedded in your build for the libusbgx recipe.
You must use systemd, and include udev and networkd support in its configuration (both of which are on by default in OE-Core zeus).

Network configuration

The systemd-networkd configuration files provided automatically create an l4tbr0 bridge device that combines the usb0 ECM interface and the rndis0 RNDIS interface. The bridge is assigned the IP address 192.168.55.1 and runs a DHCP server to serve the address 192.168.55.100 to the host side of the USB connection.

Serial port configuration

The serial port is called /dev/ttyGS0 on the device, and a udev rule automatically starts serial-getty on the device when it is created. If the connecting host is running Linux, the corresponding serial TTY will be /dev/ttyACM0 (or another /dev/ttyACMx device if there are multiple such devices on your host system).

Using device mode support

To use device mode support, just include l4t-usb-device-mode in your image.

Using device tree overlays (and custom devicetrees)

For many L4T/Jetson Linux releases, NVIDIA has provided a mechanism (the jetson-io scripts) for applying device tree overlays (.dtbo files) dynamically at runtime. For OE/Yocto-based builds, device trees are built from sources, so runtime application of DTB overlays is less of an issue. The meta-tegra layer does provide some mechanisms for applying DTB overlays, through some build-time variable settings. Creating the devicetree and devicetree overlay sources is done with recipes providing either virtual/dtb or virtual/dtbo, respectively.

For out-of-tree devicetrees (virtual/dtb)

The nvidia-kernel-oot-dtb recipe is the default device tree provider for the devkit machines in OE4T, which builds devicetree binaries from the L4T sources packaged by nvidia-kernel-oot. You can also set the PREFERRED_PROVIDER_virtual/dtb variable to point to a recipe for providing your own customized device tree, and inherit the same tegra-devicetree bbclass used by the nvidia-kernel-oot-dtb recipe.

Example out-of-tree devicetree in tegra-demo-distro

See the tegra-demo-distro example at meta-tegrademo/recipes-bsp/tegrademo-devicetree which shows how to modify a base devicetree from nvidia-kernel-oot-dtb to one specific to your hardware platform. This simple example just adds a single “compatible” line to your base devicetree. To use this example:

Determine which devicetree is currently in use. One way to do this is with bitbake -e <your image> and look at the value of KERNEL_DEVICETREE.
Determine whether there’s an existing devicetree in the meta-tegrademo/recipes-bsp/tegrademo-devicetree which uses your existing devictree as a base. Current examples are:

tegra234-p3768-0000+p3767-0005-oe4t.dts: jetson-orin-nano-devkit or jetson-orin-nano-devkit-nvme builds on a p3768 (Orin Nano Devboard) carrier
tegra234-p3768-0000+p3767-0000-oe4t.dts: Nvidia Jetson Orin NX 16GB in a p3768 (Orin Nano Devboard) carrier
tegra234-p3737-0000+p3701-0000-oe4t.dts: jetson-agx-orin-devkit
tegra264-p4071-0000+p3834-0008-oe4t.dts: jetson-agx-thor-devkit (AGX Thor T5000, p3834-0008 module)
tegra264-p4071-0000+p3834-0000-oe4t.dts: jetson-agx-thor-t4000 (AGX Thor T4000, p3834-0000 module)

If there’s not an existing devicetree built from your base KERNEL_DEVICETREE, follow the examples to add one to SRC_URI and to the repo.
Modify your MACHINE conf or local conf to specify your dtb provider and KERNEL_DEVICETREE using something like this:

PREFERRED_PROVIDER_virtual/dtb = "tegrademo-devicetree"
KERNEL_DEVICETREE:jetson-orin-nano-devkit-nvme = "tegra234-p3768-0000+p3767-0005-oe4t.dtb"
KERNEL_DEVICETREE:jetson-orin-nano-devkit = "tegra234-p3768-0000+p3767-0005-oe4t.dtb"

Where KERNEL_DEVICETREE overrides the setting for your MACHINE, referencing the devicetree filename with *.dtb in the place of *.dts.

Build, flash, and boot the board, and cat /sys/firmware/devicetree/base/compatible to see the compatible string printed as configured in the devicetree. You should see a string which starts with “oe4t”, as shown here for the orin nano

root@jetson-orin-nano-devkit-nvme:~# cat /sys/firmware/devicetree/base/compatible
oe4t,p3768-0000+p3767-0005+tegrademonvidia,p3768-0000+p3767-0005-supernvidia,p3767-0005nvidia,tegra234

For out-of-tree overlays (virtual/dtbo)

Overlay files can also be built from source via a virtual/dtbo provider, analogous to virtual/dtb for device trees. The default provider is nvidia-kernel-oot-dtbo, which builds NVIDIA’s platform overlays from the nvidia-kernel-oot source tree.

To provide custom overlays built from source, create a recipe structured like tegrademo-devicetree but with PROVIDES = "virtual/dtbo" added and overlay source files in SRC_URI:

inherit tegra-devicetree

PROVIDES = "virtual/dtbo"
COMPATIBLE_MACHINE = "(tegra)"

S = "${UNPACKDIR}"

SRC_URI = "file://my-board-overlay.dtso"

Then point to it in your machine or distro configuration:

PREFERRED_PROVIDER_virtual/dtbo = "my-overlay-recipe"

The tegra-devicetree class installs built DTBO files to /boot/devicetree/ in the sysroot. The l4t-launcher-extlinux recipe picks up all .dtbo files from that directory. Any files not explicitly named in UBOOT_EXTLINUX_FDTOVERLAYS or L4T_UBOOT_EXTLINUX_EXTRA_FDTS are placed in the l4t-launcher-extlinux-dtb-extra package. See extlinux.conf-support.md for details.

Runtime application of overlays in SPI Flash

This mechanism is supported in branches based on L4T R35.x and later. Overlays are appended to the kernel DTB by the NVIDIA flashing/signing tools, and are applied by the UEFI bootloader at runtime. Overlays are stored in SPI flash and are only updated on capsule update or tegraflash.

Locating overlays

The exact list of overlays supplied by NVIDIA varies by target platform. You can find them on R35.x-based branches by building the kernel recipe (virtual/kernel or linux-tegra) and examining its output under ${BUILDDIR}/work/tmp/${MACHINE}/linux-tegra. For R36.x-based branches, device trees are built as part of the nvidia-kernel-oot recipe.

Applying overlays

Append your additional overlays to the TEGRA_PLUGIN_MANAGER_OVERLAYS variable, which consists of a blank-separate list of .dtbo file names. You can do this in your machine configuration file, or add it, for example, to the local.conf file in your build workspace. That variable is set by the layer to include overlays that NVIDIA requires for its platforms, so be sure to append to it, rather than overwriting it.

Example

For example, to configure the pins on the 40-pin expansion header of the Jetson Orin Nano development kit, you would add the following line to your $BUILDDIR/conf/local.conf file:

    TEGRA_PLUGIN_MANAGER_OVERLAYS:append:jetson-orin-nano-devkit = " tegra234-p3767-0000+p3509-a02-hdr40.dtbo"

Runtime application of overlays in the rootfs partition

With https://github.com/OE4T/meta-tegra/pull/1968 support is available to apply overlays in the rootfs partition using the OVERLAYS extlinux.conf option. This means you are able to link overlays to a rootfs slot and store/update there instead of in the SPI flash.

Only overlays which modify the kernel DTB are supported, since the overlay application happens late in the boot sequence.

See this section of the extlinux.conf wiki page for details about configuring OVERLAYS in extlinux.conf.

Wayland Weston Support on Jetson Platforms

Support for Wayland/Weston has been adapted from the open-source libraries and patches that NVIDIA has published, rather than using the binary-only libraries packaged into the L4T BSP.

DRM/KMS support

Starting with L4T R32.2.x, DRM/KMS support in the BSP is provided through a combination of a custom libdrm.so shared library and the tegra-udrm kernel module. The library intercepts some DRM API calls; any APIs it does not handle directly are passed through to the standard implementation of libdrm.

Builds that include weston will also include a configuration file (via the tegra-udrm-probeconf recipe) that loads the tegra-udrm module with the parameter modeset=1. This enables KMS support in the L4T-specific libdrm library. If your build includes a different Wayland-based compositor, you may also need to include this configuration file.

(Earlier versions of L4T used a different custom libdrm implementation that had no KMS support and was not ABI-compatible with the standard libdrm implementation.)

Mesa build changes

The Mesa build has been changed to enable libglvnd support, which creates the necessary vendor plugins of the EGL and GLX libraries and packages them as libegl-mesa and libgl-mesa.

xserver-xorg changes

The xserver-xorg build has also been changed to disable DRI and KMS support on Tegra platforms.

libglvnd

Starting with L4T R32.1, the BSP uses libglvnd rather than including pre-built copies of the OpenGL/EGL/GLES libraries.

egl-wayland

The egl-wayland extension is built from source, with an additional patch to correct an issue with detecting Wayland displays and surfaces. The recipe also installs the needed JSON file so that the extension can be found at runtime.

weston-eglstream

NVIDIA’s patches for supporting Weston using the EGLStream/EGLDevice backend are maintained in this repository. As of L4T R32.2.x, no additional Tegra-specific patches are required.

The --use-egldevice option gets added to the command line when starting Weston to activate this support.

Note that support for the EGLStream backend was dropped in Weston 10 in favor of using GBM. We supply a backend for libgbm that uses NVIDIA’s libnvgbm.so manage GBM objects, and we still patch Weston support the EGLStream protocol for Wayland clients.

XWayland

XWayland appears to work, but hardware-accelerated OpenGL (through the libGLX_nvidia provider) is not available.

Testing

The following tests are performed:

Verify that core-image-weston builds.
Verify that weston starts at boot time.
Verify that weston sample programs, such as weston-simple-egl, display appropriate output.
Verify that the nveglglessink gstreamer plugin works with the winsys=wayland parameter by running a gstreamer pipeline to display an H.264 video. Note that the DISPLAY environment variable must not be set, per the NVIDIA documentation.
Verify that the l4t-graphics-demos applications work.

Troubleshooting

The following commands work on a Jetson TX2 and probably others:

Turn off HDMI:

echo -1 > /sys/kernel/debug/tegra_hdmi/hotplug
echo 4 > /sys/class/graphics/fb0/blank

(Source)

Turn on HDMI:

echo 1 > /sys/kernel/debug/tegra_hdmi/hotplug
echo 0 > /sys/class/graphics/fb0/blank

(Source)

Reading HDMI connection state:

/sys/devices/virtual/switch/hdmi/state is 0 when disconnected and 1 when connected. (Source)

extlinux.conf support

L4T extlinux.conf support is implemented by NVIDIA’s L4TLauncher UEFI application, not the upstream UEFI specification. It is enabled by default on all Tegra machines: UBOOT_EXTLINUX = "1" is set in tegra-common.inc and causes l4t-launcher-extlinux to be added as a runtime image dependency. Set UBOOT_EXTLINUX = "0" to disable it.

L4TLauncher reads the L4TDefaultBootMode EFI variable (GUID 781e084c-a330-417c-b678-38e696380cb9) to determine the preferred boot mode. A value of 1 selects extlinux.conf-based boot. This is set at flash time and can be inspected on the target with:

efivar -p --name 781e084c-a330-417c-b678-38e696380cb9-L4TDefaultBootMode

This reflects the preferred mode. If extlinux.conf cannot be found or read, L4TLauncher falls back to partition-based boot automatically.

The ext4 implementation in L4TLauncher may have bugs or limitations that prevent it from reading extlinux.conf or other rootfs files when newer ext4 features are in use. Non-ext4 root filesystems are unlikely to work.

Configuration variables

These variables are typically set in a machine or distro configuration file (a .conf file in conf/machine/ or conf/distro/, or a layer’s layer.conf). They can also be set in local.conf for local development. Variables that control which DTB or overlays are deployed belong in machine configuration alongside KERNEL_DEVICETREE.

UBOOT_EXTLINUX_FDT

When set, adds an FDT directive to extlinux.conf pointing to the specified device tree file. The file is installed to /boot/dtb/ on the rootfs.

Defaults to the first entry in KERNEL_DEVICETREE, so the rootfs DTB tracks the kernel build by default. When unset, the devicetree for the kernel is taken from the kernel-dtb partition, which is only updated via tegraflash or capsule update.

The value is a DTB filename with no path prefix. To override or clear the default:

# Use a specific DTB
UBOOT_EXTLINUX_FDT = "tegra234-p3701-0005-p3737-0000.dtb"

# Revert to kernel-dtb partition (disable rootfs DTB)
UBOOT_EXTLINUX_FDT = ""

UBOOT_EXTLINUX_FDTOVERLAYS

A space-separated list of device tree overlay files to apply at boot time. The overlays are installed to /boot/ on the rootfs and listed in an OVERLAYS directive in extlinux.conf. L4TLauncher applies them to the kernel DTB late in the boot sequence. Only kernel DTB modifications are supported, as the UEFI DTB cannot be changed this way.

Overlays can be standard DTB overlays (applied unconditionally) or plugin-manager-format overlays (which contain conditional directives evaluated against the hardware configuration at boot time).

Note: UBOOT_EXTLINUX_FDT must be left as default or set to a valid devicetree entry for overlays to be applied. L4TLauncher only processes the OVERLAYS directive when it has loaded a DTB from the rootfs via the FDT directive.

UBOOT_EXTLINUX_FDTOVERLAYS = "my-overlay.dtbo"

Where my-overlay.dtbo is an overlay built as part of your Yocto build. See Using-device-tree-overlays for details on building overlays. An advantage of rootfs-based overlays over SPI flash overlays is that they can be updated with the rootfs, without a capsule update or tegraflash.

Note that this is a build-time setting distinct from the overlays written by jetson-io at runtime.

UBOOT_EXTLINUX_KERNEL_ARGS

Kernel command line arguments written to the APPEND line in extlinux.conf. Defaults to ${KERNEL_ARGS}, which is set in each machine configuration to provide platform-specific arguments such as console device and memory settings. Override or append to this variable to add arguments beyond what the machine configuration provides.

UBOOT_EXTLINUX_KERNEL_ARGS:append = " systemd.log_level=debug"

UBOOT_EXTLINUX_MENU_TITLE

The MENU TITLE line written to extlinux.conf. Defaults to "L4T boot options". This line is required by L4TLauncher.

UBOOT_EXTLINUX_TIMEOUT

Time in tenths of a second to display the boot menu before selecting the default entry. Not set by default, meaning the default entry is selected immediately without showing the menu. Useful during development to allow manual boot entry selection.

UBOOT_EXTLINUX_TIMEOUT = "30"

L4T_UBOOT_EXTLINUX_EXTRA_FDTS

A space-separated list of additional DTB files to install to /boot/dtb/ alongside any DTB configured via UBOOT_EXTLINUX_FDT. These are included in the base l4t-launcher-extlinux package and are not referenced in extlinux.conf. These are distinct from the files in the l4t-launcher-extlinux-dtb-extra subpackage, which contains all remaining staged DTBs and DTBOs not claimed by the base package. See Jetson expansion header configuration.

EXTERNAL_KERNEL_DEVICETREE

Path to a directory containing DTBs and DTBOs from an external device tree provider (i.e. when PREFERRED_PROVIDER_virtual/dtb is set). Defaults to ${RECIPE_SYSROOT}/boot/devicetree when a virtual/dtb provider is configured, empty otherwise. The recipe stages all .dtb and .dtbo files found here. Any not claimed by UBOOT_EXTLINUX_FDT, UBOOT_EXTLINUX_FDTOVERLAYS, or L4T_UBOOT_EXTLINUX_EXTRA_FDTS end up in the l4t-launcher-extlinux-dtb-extra subpackage. This variable does not normally need to be set manually.

L4T_EXTLINUX_BASEDIR

The root directory for all files installed by l4t-launcher-extlinux. Defaults to /boot. Changing this would require a corresponding patch to edk2-nvidia and is not recommended.

Jetson expansion header configuration (jetson-io)

NVIDIA’s jetson-io tool allows runtime reconfiguration of the Jetson expansion header pins. It generates device tree overlay files for the selected pin configuration and writes them to the rootfs, then updates extlinux.conf to reference the new overlays via the OVERLAYS directive, causing them to be applied at the next boot. The python3-jetson-io recipe packages this tool for use in meta-tegra builds.

To include it in your image:

IMAGE_INSTALL:append = " python3-jetson-io"

The recipe depends on l4t-launcher-extlinux and recommends l4t-launcher-extlinux-dtb-extra. The dtb-extra subpackage contains all available DTBs (from /boot/dtb/) and DTBOs (from /boot/) that were not explicitly configured via UBOOT_EXTLINUX_FDT or UBOOT_EXTLINUX_FDTOVERLAYS. jetson-io uses these files to enumerate available hardware configurations and generate overlay files.

For jetson-io to write the resulting overlay back into the extlinux boot configuration, UBOOT_EXTLINUX must be enabled (it is by default) and the rootfs must be accessible from the bootloader. See the NVIDIA developer guide for Configuring the Jetson Expansion Headers for instructions on running the tool on the target.

Note: jetson-io modifies the device tree configuration at runtime on the target device. Its output is not reproducible at build time and is intended for development and devkit use, not production images.

Caveats

The extlinux.conf syntax supported in L4TLauncher is not the same as U-Boot’s, and the parsing code is not particularly robust, so be careful about any modifications to avoid boot failures.
All paths in extlinux.conf must be absolute. Relative paths are not supported by L4TLauncher.
FDTDIR is not supported.
UBOOT_EXTLINUX_CONSOLE is not used. Console settings are provided via KERNEL_ARGS in the machine configuration.
The kernel image directive in the generated file uses LINUX rather than KERNEL.

UEFI Capsule Update

Rollback protection

By default the LowestSupportedVersion field in UEFI Capsule FMP Payload Header is set to the current L4T version, which prevents bootloader downgrade. TEGRA_UEFI_LOWEST_SUPPORTED_VERSION variable can be used to override this behaviour.

For example to allow downgrading to L4T 36.4.3 add the following line to your machine config:

TEGRA_UEFI_LOWEST_SUPPORTED_VERSION = "0x00240403"

Documentation Workflow

This project uses mdBook to generate documentation, with GitHub Actions for automated builds and GitHub Pages for hosting.

Repository Layout

Documentation source files live alongside the Yocto BSP layer content:

meta-tegra/
├── book.toml                      # mdBook configuration
├── docs/                          # Documentation source (markdown)
│   ├── SUMMARY.md                 # Table of contents for mdBook
│   ├── README.md                  # Introduction / landing page
│   ├── *.md                       # Documentation pages
│   └── mdbook/                    # Custom mdBook assets
│       ├── css/custom.css         # Version dropdown styling
│       └── js/version-dropdown.js # Version switching logic
└── .github/workflows/
    └── mdbook-versioned.yml       # CI/CD workflow

The book.toml in the repository root configures mdBook. The src setting points to the docs/ directory, and custom CSS and JavaScript are loaded for the version dropdown:

[book]
title = "OE4T Meta Tegra"
authors = ["Matt Madison", "Dan Walkes"]
language = "en"
src = "docs"

[output.html]
additional-css = ["docs/mdbook/css/custom.css"]
additional-js = ["docs/mdbook/js/version-dropdown.js"]

Multi-Version Support

Each tracked branch gets its own independent copy of the documentation on GitHub Pages. The list of published versions is controlled by a versions.json file in the GitHub Pages content repository (OE4T/oe4t.github.io).

Adding Pages

All documentation pages are Markdown files in the docs/ directory. To add a new page:

Create a new .md file in docs/.
Add an entry for it in docs/SUMMARY.md. The SUMMARY file defines the table of contents and sidebar navigation. Pages not listed in SUMMARY.md will not appear in the built documentation.

Page Editing Tips

Please ensure any embedded links to other documentation files are done with relative paths. For example, use [Link to another page in docs](OtherPageName.md) instead of [Link to another page in docs](https://github.com/OE4T/meta-tegra/blob/master/docs/OtherPageName.md)
You can use the trick at this stackoverflow post to add images to your markdown file without the need to check images into the repo.

Preview Locally

To preview the documentation locally with markdown, install mdBook and run:

mdbook serve

This starts a local web server with live reloading as you edit files.

Build and Deploy

The GitHub Actions workflow (.github/workflows/mdbook-versioned.yml) triggers on pushes to tracked branches:

Build — runs mdbook build inside a peaceiris/mdbook container, producing output in a per-branch directory.
Deploy — pushes the built HTML to a subdirectory in the main branch of the external GitHub Pages content repository (OE4T/oe4t.github.io) using peaceiris/actions-gh-pages.

Each branch deploys to its own directory, resulting in a structure like this in OE4T/oe4t.github.io:

<repo-root>/
├── index.html          # redirects to ./master/
├── versions.json       # lists available versions for the dropdown
├── master/             # docs built from the master branch
└── scarthgap/          # docs built from the scarthgap branch

The workflow can also be triggered manually via workflow_dispatch from the GitHub Actions UI.

Deployment credentials

The deploy step requires an SSH deploy key stored as a repository secret:

OE4T_GITHUB_DEPLOY_KEY

If the secret is missing (common in forks), the workflow will emit a warning: “The repository secret must contain the OE4T_GITHUB_DEPLOY_KEY to run this step.” Then it will skip the deploy step without failing the workflow.

A custom JavaScript file (docs/mdbook/js/version-dropdown.js) adds a version selector dropdown to the mdBook navigation bar. It fetches versions.json from the site root to populate the list, and when a different version is selected it navigates to the same page path under the new version’s directory.

The versions.json file is maintained manually in the GitHub Pages content repository (OE4T/oe4t.github.io, main branch) (not auto-generated), giving explicit control over which versions appear in the dropdown.

Adding a New Version

To add documentation for a new branch (e.g., kirkstone):

Add the branch name to the on.push.branches list in .github/workflows/mdbook-versioned.yml.
Push content to that branch. The workflow will automatically build and deploy to a new directory in OE4T/oe4t.github.io.
Update versions.json in OE4T/oe4t.github.io (on the main branch) to include the new entry so it appears in the version dropdown.

Overview

This page hosts release note links for previous releases of NVIDIA L4T/meta-tegra. If you are viewing this page in the mdbook please ensure you use the “master” branch version of documentation to ensure you are referencing the most recent source

JetPack 7.2 / R39.x

JetPack-7.2-L4T-R39.2.0-Notes

JetPack 7.0–7.1 / R38.x

JetPack-7.1-L4T-R38.4.x-Notes
JetPack-7.0-L4T-R38.2.x-Notes

Jetpack 6 / R36.x

JetPack-6.2.2-L4T-R36.5.0-Notes
JetPack-6.2.1-L4T-R36.4.4-Notes
JetPack-6.2-L4T-R36.4.3-Notes
JetPack-6.1-L4T-R36.4.0-Notes
JetPack-6.0-L4T-R36.3.0-Notes

Jetpack 5 /R35.x

JetPack-5.1.6-L4T-R35.6.4-Notes
JetPack-5.1.5-L4T-R35.6.2-Notes
JetPack-5.1.5-L4T-R35.6.1-Notes
JetPack-5.1.4-L4T-R35.6.0-Notes
JetPack-5.1.3-L4T-R35.5.0-Notes
JetPack-5.1.2-L4T-R35.4.1-Notes
JetPack-5.1.1-L4T-R35.3.1-Notes
JetPack-5.1-L4T-R35.2.1-Notes
JetPack-5.0.2-L4T-R35.1.0-Notes

Legacy releases

L4T-R32.7.6-Notes
L4T-R32.7.5-Notes
L4T-R32.7.4-Notes
L4T-R32.7.3-Notes
L4T-R32.7.2-Notes
L4T-R32.7.1-Notes
L4T-R32.6.1-Notes
L4T-R32.5.2-Notes
L4T-R32.5.1-Notes
L4T-R32.5.0-Notes
L4T-R32.4.4-Notes
L4T-R32.4.3-Notes
L4T-R32.4.2-Notes
L4T-R32.3.1-Notes
L4T-R32.2.3-Notes
L4T-R32.2.1-Notes
L4T-R32.2.0-Notes
L4T-R32.1.0-Notes
L4T-R28.3-Notes
L4T-R28.2-Notes
L4T-R28.1-notes

Changes from L4T R36.5.0/JetPack 6.2.2 and R38.4.x/JetPack 7.1

This is the first JetPack release to support both the Orin family (AGX Orin, Orin NX, Orin Nano, previously supported in JetPack 6) and AGX Thor (T4000, T5000, previously supported only in JetPack 7).

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

BSP changes

New machine configurations

Support for the AGX Thor platform is incorporated alongside Orin. New machine configurations added versus r36.x:

jetson-agx-thor-devkit — AGX Thor development kit (T5000 module, p4071 carrier)
jetson-agx-thor-t4000 — AGX Thor T4000 module installed in a p4071 carrier

Flashing process changes

Only initrd-flash is supported for flashing. See the Flashing page for more information.

Security OS changes

OP-TEE gets an update to 4.6 with L4T R39.2. Hafnium (used on Thor only) is also updated. The Orin and Thor ARM TF-A firmware remains at their same respective base versions (different between the two platforms) as prior releases.

UEFI changes

The EDK2/UEFI source base has been updated for L4T R39.2, covering both Orin and Thor targets. For Orin users that have customized their UEFI configurations, note that configuration handling for UEFI builds in this release follows the updated approach used for Thor in R38.4, providing default ‘general’, ‘minimal’, and ‘simple’ configurations in-tree.

Kernel changes

Orin (Tegra234)

The kernel for Orin has been upgraded from linux-jammy-nvidia-tegra (5.15-based) to linux-noble-nvidia-tegra (6.8.12-based). This is a significant kernel version upgrade.

A notable consequence of moving to the 6.8 kernel is that many Tegra ASoC audio drivers that were previously delivered as out-of-tree modules (in the nvidia-kernel-oot-alsa package) are now included in the mainline kernel. The following drivers have moved in-tree and are no longer provided by the OOT package:

snd-soc-tegra186-asrc
snd-soc-tegra186-dspk
snd-soc-tegra210-admaif
snd-soc-tegra210-adx
snd-soc-tegra210-ahub
snd-soc-tegra210-amx
snd-soc-tegra210-dmic
snd-soc-tegra210-i2s
snd-soc-tegra210-mixer
snd-soc-tegra210-mvc
snd-soc-tegra210-ope
snd-soc-tegra210-sfc
snd-soc-tegra-machine-driver

A smaller set of audio drivers (ADSP and virtualization-related) remains out-of-tree.

Thor (Tegra264)

Thor targets already used linux-noble-nvidia-tegra (6.8.12) in the R38.x branches. The kernel base version is unchanged, but has been updated to the R39.2.0 L4T patch series.

Out-of-tree drivers

The out-of-tree kernel module package has been updated to R39.2.0, with compatibility updates for the 6.8 kernel across both Tegra234 and Tegra264 platforms.

JetPack changes

JetPack 7.2 includes significant component upgrades from JetPack 6.2.2:

Component	JetPack 6.2.2	JetPack 7.1	JetPack 7.2
CUDA	12.6	13.0	13.2
cuDNN	9.3.0	9.12.0	9.20.0
TensorRT	10.3.0	10.13.3	10.16.2

PVA SDK and Nsight Systems have also been updated; see the NVIDIA release notes for version details.

Other new features

New recipes

SIPL/UDDF support

Recipes have been added for the SIPL API package and nvsiplcamerasrc GStreamer plug-in. Consult the “Camera Development” chapter of the Jetson Linux Developer Guide for more information.

Jetson-IO support

The python3-jetson-io recipe has been added for installing the Jetson-IO tool for runtime pin configuration. See [here](../extlinux.conf-support.md(#jetson-expansion-header-configuration-jetson-io) for more information.

Container support

The nvidia-docker recipe has been removed. The nvidia-container-toolkit recipe provides container runtime support; see NVIDIA Container Runtime Support for details.

DeepStream SDK

No information is available yet on DeepStream SDK compatibility with JetPack 7.2.

As of 23 Feb 2026, the master-l4t-r38.4.x branch supports JetPack 7.1/L4T R38.4.0.

Changes from L4T R38.2.x/JetPack 7.0

This release introduces support for the Jetson T4000 module. Like R38.2.x, only Thor targets are supported. Machine configurations for the Orin family remain in the tree, but are not usable and not supported.

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

Jetson Linux R38.4 release notes
JetPack download page (note that this link is not version-tagged)

BSP changes

The BSP supports the Jetson T4000, but a machine configuration for it is not yet present in the layer.
Note that L4T R38.4.x does not support Orin hardware. Machine definitions have not been removed from the layer, but they should not be used.

Flashing process changes

Flashing in Jetson Linux for Thor targets is performed through a “unified” flashing process that is hidden under the L4T initrd/kernel flashing scripts.

For meta-tegra builds, after unpacking your tegraflash tarball, use initrd-flash while connected via USB to your Thor device to generate/sign the binary artifacts, stage them to a unified-flash workspace, and run the unified flashing scripts to flash the device. You can use ./initrd-flash --external-only to re-flash only the external (rootfs) drive, ./initrd-flash -k NAME to re-flash just the named partition, or ./initrd-flash --qspi-only to re-flash only the boot firmware in the QSPI flash. The script also takes a --debug option for enabling more verbose logging in the unified flashing tool.

See NVIDIA release notes and documentation for more information.

Kernel changes

The Linux kernel is still taken from the Ubuntu “Noble” release, and is based on Linux 6.8.12. The kernel recipe has been changed to use NVIDIA’s GitLab repo directly, instead of the OE4T copy in GitHub.

Please note that the linux-yocto kernel (or any other kernel than the NVIDIA/Ubuntu one) is still not supported on Thor hardware.

JetPack changes

JetPack 7.1 include only minor JetPack upgrades, for the PVA SDK and for VPI.

DeepStream SDK

No DeepStream SDK update has been issued, but it is unclear whether the existing DS-8.0 SDK is compatible.

As of 12 Nov 2025, the master-l4t-r38.2.x branch supports JetPack 7.0/L4T R38.2.2. Note that R38.2.2 only updates some of the components; the rest remain at 38.2.1.

Changes from L4T R36.4.4/JetPack 6.2.1

This release introduces support for the Jetson AGX Thor development kit, and supports only AGX Thor targets. Machine configurations for the Orin family remain in the tree, but are not usable and not supported.

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

Jetson Linux R38.2 release notes
Jetson Linux R38.2.1 release notes
JetPack 7.0 download page (note that this link is not version-tagged)

Note that NVIDIA has not provided release notes for R38.2.2.

BSP changes

Many changes are present to support Thor hardware. Note that L4T R38.2.x does not support Orin hardware. Machine definitions have not been removed from the layer, but they should not be used.

Flashing process changes

Flashing in Jetson Linux for Thor targets is performed through a “unified” flashing process that is hidden under the L4T initrd/kernel flashing scripts.

See NVIDIA release notes and documentation for more information.

Kernel changes

The Linux kernel is now taken from the Ubuntu “Noble” release, and is based on Linux 6.8.12.

JetPack changes

JetPack 7.0 upgrades most of the JetPack content. See the NVIDIA documentation for more information.

CUDA 13, included in JetPack 7.0, supports the use of gcc/g++ 15 as the host toolchain, so the gcc-for-nvcc recipes, which were used for providing an older toolchain for use with nvcc, have been dropped.

DeepStream SDK

DeepStream 8.0 is available. The recipes for DeepStream in the meta-tegra-community layer have been updated.

As of 28 Feb 2026, the master and scarthgap branches support JetPack 6.2.2/L4T R36.5.0.

Changes from L4T R36.4.4/JetPack 6.2.1

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

BSP changes

This release mainly contains bugfixes.

See NVIDIA release notes for information on other changes/improvements.

Kernel changes

The Linux kernel (linux-jammy-nvidia-tegra) was updated to 5.15.185.

The NVIDIA out-of-tree drivers have been patched so they build with the NVIDIA-provided kernel as well as newer linux-yocto kernels (6.6 for scarthgap and 6.18 for master).

JetPack changes

No major updates to the JetPack SDK.

DeepStream SDK

No update to the DeepStream SDK. Version 7.1 remains compatible with JetPack 6.2.2.

As of 10 Aug 2025, the master and scarthgap branches support JetPack 6.2.1/L4T R36.4.4.

Changes from L4T R36.4.3/JetPack 6.2

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

BSP changes

Support has been added for using a Hardware Security Module (HSM) for signing the boot firmware. In the layer, our tegra-flash-helper script has been updated to support an --hsm option, which gets passed through to the NVIDIA signing scripts for this feature.

Otherwise, this release mainly contains bugfixes.

See NVIDIA release notes for information on other changes/improvements.

Kernel changes

The Linux kernel remains at 5.15.148.

JetPack changes

No major updates to the JetPack SDK.

DeepStream SDK

No update to the DeepStream SDK. Version 7.1 remains compatible with JetPack 6.2.1.

As of 02 May 2025, the master, walnascar, and scarthgap branches support JetPack 6.2/L4T R36.4.3.

Changes from L4T R36.4.0/JetPack 6.1

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

BSP changes

The main new feature in this release is the addition of “super” power modes for the P3767 series modules (Orin NX and Orin Nano).
The JetsonMinimal UEFI build configuration, instead of full UEFI, is now used for RCM booting. (RCM boot is used for initrd-based flashing.)

See NVIDIA release notes for information on other changes/improvements.

Kernel changes

The Linux kernel remains at 5.15.146.

JetPack changes

No major updates to the JetPack SDK.

DeepStream SDK

No update to the DeepStream SDK. Version 7.1 remains compatible with JetPack 6.2.

As of 27 Oct 2024, the master, styhead, and scarthgap branches support JetPack 6.1/L4T R36.4.0.

Changes from L4T R36.3.0/JetPack 6.0

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

BSP changes

NVIDIA has added an implementation of Firmware Trusted Platform Module (fTPM) as an OP-TEE TA. A recipe for building this has not yet been added to the layer.
The default kernel arguments no longer set net.ifnames=0, so network interfaces will use the newer kernel naming convention.
Source code is now provided for the nvipcpipeline and nvunixfd gstreamer plugins. Recipes have been added for these plugins, and they have been removed from the gstreamer1.0-plugins-tegra-binaryonly package.
A minimal UEFI configuration is now supported on AGX Orin series modules. See this section in the Jetson Linux Developer Guide for more information. The variable TEGRA_UEFI_MINIMAL can be set to "1" in your build configuration to use this configuration instead of the default.

See NVIDIA release notes for information on other changes/improvements.

Kernel changes

The Linux kernel has been updated to 5.15.146.

JetPack changes

Several of the JetPack packages have been updated, including CUDA (to 12.6). See the JetPack release notes for more information.

DeepStream SDK

DeepStream SDK 7.1 is compatible with JetPack 6.1. See the meta-tegra-community work-in-progress branch for the updated recipes.

As of 01 June 2024, the master and scarthgap branches support JetPack 6.0/L4T R36.3.0.

Changes from L4T R35.3.1/JetPack 5.1.1

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

Machine changes

L4T R36.x supports only Jetson Orin modules and development kits. Support for Jetson Xavier modules has been removed.

BSP changes

Updates in this release, as they apply to OE/Yocto builds, are mainly fixes and “improvements” to the existing boot firmware and low-level libraries. This includes new versions of the secure OS (TF-A and OP-TEE) and the UEFI bootloader.

Kernel changes

The 5.10+Android-based kernel has been replaced with a 5.15-based kernel from Ubuntu 22.04. Jetson-specific drivers and device trees have been moved out of the kernel source tree and are now built separately. This change allows for the replacement of the NVIDIA-provided, Ubuntu-derived base kernel with other upstream kernels; see the L4T documentation and release notes for more information.

JetPack changes

Many of the JetPack packages have been updated, including CUDA (to 12.2). See the JetPack release notes for more information.

DeepStream SDK

The DeepStream SDK has been updated to version 7.0.

Other Notes

There are several known issues documented in the release notes, which are worth reviewing. In particular, USB connectivity during flashing can sometimes be a problem. Workarounds mentioned in the release notes include swapping cables and/or USB ports on your host PC, and rebooting your host PC if you encounter flashing failures.
The NVIDIA-specific userland DRM library (libdrm-nvdc) has been removed in this release.
Vulkan support is present, but you must manually include the tegra-libraries-vulkan package in your image to install the necessary configuration file for the Vulkan dispatcher. While NVIDIA now also supports VulkanSC in Jetson Linux, recipes to install those libraries are not yet available.
Jetson-specific patches for wayland and weston are no longer needed.

As of 21 Feb 2026, the kirkstone and scarthgap-l4t-r35.x branches support JetPack 5.1.6/L4T R35.6.6.

This is a minor update to the L4T BSP only, with no JetPack changes.

Changes from L4T R35.6.2/JetPack 5.1.5

See the release notes in the NVIDIA documentation for this release for information on changes:

As of 07 Jul 2025, the kirkstone and scarthgap-l4t-r35.x branches support JetPack 5.1.5/L4T R35.6.2.

This is a minor update to the L4T BSP only, with no JetPack changes.

Changes from L4T R35.6.1/JetPack 5.1.5

See the release notes in the NVIDIA documentation for this release for information on changes, but essentially has only bug fixes over R35.6.2:

Jetson Linux R35.6.2 page
JetPack 5.1.5 page (same JetPack release as for L4T R35.6.1)

Kernel changes

No kernel update in this release; the exact same kernel sources are used as for R35.6.1. However, the default KERNEL_ARGS setting for all machines has been changed to remove the nospectre_bhb parameter. If you have a custom machine configuration, you may wish to update your KERNEL_ARGS setting accordingly, to enable Spectre-BHB mitigations in the kernel.

Other notes

While most of the BSP packages have been updated or re-issued with 35.6.2 version numbering, the Jetson Multimedia API .deb packages remain at version 35.6.1 in this release.

As of 18 May 2025, the kirkstone and scarthgap-l4t-r35.x branches support JetPack 5.1.5/L4T R35.6.1.

Changes from L4T R35.6.0/JetPack 5.1.4

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

Machine changes

No new machines in this release. Existing machines for P3767 modules (Orin Nano and NX-based) have been updated to use the new MAXN_SUPER power model configurations, which affect the kernel device tree, BPMP configuration, and NVPMODEL configuration files.

BSP changes

Other updates in this release are mainly fixes and improvements to the existing boot firmware and low-level libraries.

Kernel changes

The upstream base remains at 5.10.216. Updates include some bug fixes and the device tree updates to support MAXN_SUPER power model configurations.

As of 11 Oct 2024, the scarthgap-l4t-r35.x and kirkstone branches support JetPack 5.1.4/L4T R35.6.0.

Changes from L4T R35.5.0/JetPack 5.1.3

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

Machine changes

No new machines in this release.

BSP changes

Updates in this release, as they apply to OE/Yocto builds, are mainly fixes and improvements to the existing boot firmware and low-level libraries.

Kernel changes

The upstream base was updated to 5.10.216.

As of 01 June 2024, the scarthgap-l4t-r35.x and kirkstone branches support JetPack 5.1.3/L4T R35.5.0.

Changes from L4T R35.4.1/JetPack 5.1.2

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

Machine changes

No new machines in this release.

BSP changes

Updates in this release, as they apply to OE/Yocto builds, are mainly fixes and improvements to the existing boot firmware and low-level libraries.

Storage layouts (the flash_*.xml files) have been updated slightly over R35.4.1. If you have a custom storage layout you have derived from an earlier version of L4T, you should review the differences for any adjustments you may need to make.

Kernel changes

The upstream base was updated to 5.10.192.

UEFI changes

For secured devices, UEFI now authenticates its variables. This requires the addition of an authentication key to the EKB, without which your secured device will not boot. This also means that an OTA update from an earlier R35.x release will require that your OTA package also update the EKB, so be warned.

For more information , see this thread on the developer forum.

JetPack changes

VPI updated to version 2.4.8

Other Notes

While the NVIDIA release notes mention use of the grub loader in place of L4TLauncher for loading the OS from the UEFI bootloader, this has not been implemented or tested in the layer. Likewise for PXE booting.

As of 02 Sep 2023, the master, mickledore, and kirkstone branches support JetPack 5.1.2/L4T R35.4.1.

Changes from L4T R35.3.1/JetPack 5.1.1

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

Machine changes

L4T R35.4.1 adds support for the Jetson AGX Orin Industrial module. The machine configuration jetson-agx-orin-devkit-industrial has been added to the layer to build images for the module when installed in an AGX Orin development kit.

BSP changes

Updates in this release, as they apply to OE/Yocto builds, are mainly fixes and improvements to the existing boot firmware and low-level libraries.

For multimedia support, the deprecated nvbuf_utils library was removed in this release.

Kernel changes

No major updates. The upstream base was updated to 5.10.120.

JetPack changes

VPI updated to version 2.3.9
Nsight updated to 2023.2

DeepStream SDK

The DeepStream SDK has been updated to version 6.3-1. The recipe in the meta-tegra-community repo has been updated.

Other Notes

While the NVIDIA release notes mention use of the grub loader in place of L4TLauncher for loading the OS from the UEFI bootloader, this has not been implemented or tested in the layer. Likewise for PXE booting.

As of 16 Apr 2023, the master, mickledore, and kirkstone branches support JetPack 5.1.1/L4T R35.3.1.

Changes from L4T R35.2.1/JetPack 5.1.0

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

Machine changes

L4T R35.3.1 adds support for the Jetson Orin Nano developer kit. Machine configurations jetson-orin-nano-devkit and jetson-orin-nano-devkit-nvme have been added to the layer to build images for use of the kit with SDcard and NVMe storage, respectively. These configurations should also be usable as a starting point for a custom machine based on one of the Orin Nano production modules.

BSP changes

Other than the new hardware support, no major changes to the layer for the BSP update. The secureboot overlay that NVIDIA issued to fix problems with Orin secure boot support (specifically, using SBKPKC signing + encryption) for R35.2.1 is also applied here.

Kernel changes

There are no major updates to the kernel, which is still based on 5.10.104.

NOTE, however, that if you have a custom machine configuration based on one of the Xavier modules (tegra194), you should update your KERNEL_ARGS setting to add video=efifb:off as a kernel parameter to avoid system crashes at boot time.

JetPack changes

New versions of VPI and Nsight.

DeepStream SDK

DeepStream SDK updates usually lag new JetPack releases. Will update if/when a new version is released that supports JetPack 5.1.1.

Other Notes

The Orin Nano omits the hardware video encoder present in other Jetson models. Don’t try to use the NVIDIA-specific gstreamer plugins for video encoding on that platform; stick to the software-based plugins.

Known Issues

The nvpmodel may fail with an error on the first boot after flashing an Orin device. You can clear this problem by using the nvpmodel command to select a power model configuration, then rebooting (changing the power model may prompt you to reboot immediately). NOTE Fixed with PR #1294.
Soft reboots on the Orin Nano devkit may fail during OP-TEE startup with a Heap free list corrupted !!! error. Powering off the device for 10 seconds, then powering it back on, clears the problem. NOTE This does not occur when using the supported initrd-flash mechanism for flashing the development kit. Do not try to use the direct flashing mechanism (the doflash.sh script) when flashing an Orin NX or Nano device using an NVMe drive for its rootfs storage.
The nvfancontrol daemon on the Orin Nano devkit may raise the fan to the highest speed and log warnings about Failed to open empty file! (Bad address). This should also be fixed with PR #1294.
There are still some known issues outstanding with the JetPack 5 integration. See this issues list for the current status. Any help with resolving these issues would be appreciated!

As of 08 Feb 2023, the master, langdale, and kirkstone branches support Jetson Linux R35.2.1 and JetPack 5.1. As of 16 Apr 2023, master and kirkstone have been updated to JetPack 5.1.1/L4T R35.3.1.

Changes from L4T R35.1.0/JetPack 5.0.2

See the release notes in the NVIDIA documentation for this release for information on new and updated features:

Machine changes

L4T R35.2.1 adds support for Jetson Orin NX 16GB production modules. A machine configuration for this module mounted on a Xavier NX development kit carrier board is available in the layer: p3509-a02-p3767-0000.conf.

BSP changes

Many of the BSP components have been updated. The significant new feature in this release is support for UEFI Secure Boot.

UEFI and OP-TEE are now built from source by default, rather than using the pre-built copies from the L4T package.

Kernel changes

No major updates to the kernel, which is still based on 5.10.104.

JetPack changes

Minor updates to CUDA packages
New versions of cuDNN, TensorRT, and VPI

DeepStream SDK

With JetPack 5.1, the DeepStream SDK has been updated to version 6.2.0-1. The recipes in meta-tegra-community have been updated accordingly for the SDK itself and the Python bindings.

Known Issues

There are some known issues with the JetPack 5 integration. See this issues list for the current status. Any help with resolving these issues would be appreciated!

NVIDIA issued an “overlay” to the L4T R35.2.1 kit to fix problems with Orin secure boot support (specifically, using SBKPKC signing + encryption). That overlay was integrated in the master and kirkstone branches.

As of 18 Sep 2022, the master and kirkstone branches support Jetson Linux R35.1.0 and JetPack 5.0.2 (rev. 1).

Please note that the official name for the BSP from NVIDIA is Jetson Linux, instead of Linux for Tegra. We’ll continue to use “L4T” as an abbreviation.

Changes from L4T R32.7.2/JetPack 4.6.2

This is a major update to L4T and JetPack which adds support for the Jetson AGX Orin modules and removes support for all other Jetson modules except for the Jetson AGX Xavier and Jetson Xavier NX series.

NVIDIA documentation:

Machine changes

The only Jetson modules supported in this release (and future releases) are:

Jetson AGX Orin series
Jetson AGX Xavier series
Jetson Xavier NX series

We also have a machine configuration for the Clara AGX development kit.

BSP changes

This is a major update to the BSP and is not compatible with the R32.x series of releases.

The cboot bootloader has been replaced by UEFI. You can use either NVIDIA’s prebuilt copy, or build it from source.
Boot logos/splash screens are now built into the UEFI bootloader, rather than being separately loaded. Recipes for custom boot logos have been removed from the layer.
The device tree plugin manager, which was a cboot feature, is no longer supported. To dynamically modify the device tree (e.g., for camera configuration), you must configure a device tree overlay instead.
Bootloader updating and redundancy behaves differently than with earlier L4T releases. See the L4T documentation for details.
The Linux kernel has been updated to 5.10.104. The repository used in the layer for this new kernel is here.
The trusty trusted OS has been replaced by OP-TEE.
Open-source display driver (AGX Orin series only).
The OpenMAX gstreamer plugin (gstreamer1.0-omx-tegra), which has been deprecated since L4T R32.1.0, is no longer supported.
Improved support for Wayland/Weston via the EGL-GBM backend interface.
Container support now defaults to a smaller set of libraries passed through from the host to the container.

Kernel changes

Besides the upgrade to the Linux 5.10 LTS kernel as a base, the new default kernel configuration for Jetson devices builds far more features and drivers as modules, rather than building them into the kernel itself. If you have recipes that depend on specific kernel features/drivers, you may need to add RRECOMMENDS settings to ensure that the necessary modules get installed into your rootfs image. The kernel configuration in the layer diverges slightly from the stock Jetson Linux configuration by building in a small number of drivers, rather than leaving them as modules.

JetPack changes

CUDA updated to 11.4.
New versions of cuDNN, TensorRT, VPI.
libvisionworks is no longer supported.

DeepStream SDK

With JetPack 5.0.2 (rev. 1), the DeepStream SDK has been updated to version 6.1.1-1. The recipes in meta-tegra-community have been updated accordingly for the SDK itself and the Python bindings.

Known Issues

There are some known issues with the JetPack 5 integration. See this issues list for the current status. Any help with resolving these issues would be appreciated!

In addition, while NVIDIA supplies sources for the OP-TEE trusted OS, recipes for building OP-TEE from source are not yet ready for merging.

As of 29 Nov 2024, the kirkstone-l4t-r32.7.x and branch supports L4T R32.7.6/JetPack 4.6.6.

Changes from L4T R32.7.5/JetPack 4.6.5

NVIDIA documentation:

Content for this release is identical to L4T R32.7.5/JetPack 4.6.5, with the following updates:

Security fixes
Support for new DRAM part

Note: This is the final release of the L4T R32 series. See this NVIDIA developer forum post for the end-of-life announcement.

As of 30 Jun 2024, the kirkstone-l4t-r32.7.x and branch supports L4T R32.7.5/JetPack 4.6.5.

Changes from L4T R32.7.4/JetPack 4.6.4

NVIDIA documentation:

Content for this release is identical to L4T R32.7.4/JetPack 4.6.4, with the following updates:

Kernel and driver patches
Boot firmware updates to support SKU 3 of the TX2-NX module, as well as recent BOM changes (see PCN references in the release notes)

As of 03 Jul 2023, the kirkstone-l4t-r32.7.x and dunfell branches support L4T R32.7.4/JetPack 4.6.4.

Changes from L4T R32.7.3/JetPack 4.6.3

NVIDIA documentation:

Content for this release is identical to L4T R32.7.3/JetPack 4.6.3, with the following updates:

Security fixes: NVIDIA security bulletin
Kernel update to v4.9.337 base (the last 4.9 LTS kernel release)
Minor updates to Jetson Multimedia API

As of 21 Jan 2023, the kirkstone-l4t-r32.7.x and dunfell branches support L4T R32.7.3/JetPack 4.6.3.

Changes from L4T R32.7.2/JetPack 4.6.2

NVIDIA documentation:

Content for this release is identical to L4T R32.7.2/JetPack 4.6.2, with the following updates:

Security fixes
Support for updated Jetson TX2 modules with Hynix DRAM

As of 22 May 2022, the master, kirkstone, and dunfell branches support L4T R32.7.2/JetPack 4.6.2.

Changes from L4T R32.7.1/JetPack 4.6.1

NVIDIA documentation:

L4T R32.7.2 page Note that the release notes linked on that page are for R32.7.1 (as of 22 May 2022).
JetPack release page

Content for this release is identical to L4T R32.7.1/JetPack 4.6.1, with the following updates:

Security fixes
Support for new AGX Xavier module revisions

As of 18 Mar 2022, the master branch supports L4T R32.7.1/JetPack 4.6.1. As of 08 Apr 2022, the dunfell branch also supports L4T R32.7.1/JetPack 4.6.1.

Changes from L4T R32.6.1/JetPack 4.6

NVIDIA documentation:

Machine changes

R32.7.1 adds support for the 64GB Jetson AGX Xavier and 16GB Jetson Xavier NX modules. These should be supported without modifying any machine configuration files, although (as of this writing) that has not been tested.

Flash layout file changes for t194 (Xavier) platforms

The flash layout XML files for the Jetson AGX Xavier Industrial module has been changed to add a second badpage partition. Since there is no support yet for that module in meta-tegra, that should not affect any current users.

Kernel updates

The security engine driver has been enhanced to provide hwrng device to the kernel, which can be used with the rng-tools entropy gatherer (for t186/t194 only). Recipes to enable this on TX2 and Xavier platforms have been added to the meta-tegra-community repo.

Firmware loading issue

NVIDIA modified the kernel firmware loader in a way that causes significant delays with the default kernel configuration, which enables the long-deprecated userland helper interface for firmware loading. Disabling CONFIG_FW_LOADER_USER_HELPER and CONFIG_FW_LOADER_USER_HELPER_FALLBACK fixes the delay, and this is done by default in the kernel recipe.

U-Boot updates

The U-Boot in L4T R32.7.1 remains at U-Boot v2020.04, with added patches from NVIDIA. In this layer we continue to track the upstream OE-Core U-Boot recipes in each branch, porting NVIDIA patches to our fork of the upstream U-Boot repository.

Note that unlike NVIDIA, our U-Boot fork uses a separate build configuration for the SDcard-based Nano (sku 0000) and the eMMC production Nano (sku 0002), so patches related to supporting both in the same build have not been applied.

On t210 platforms, U-Boot is now responsible for loading the XUSB controller firmware; it is not loaded by cboot.

cboot updates

cboot on the t186/t194 platforms added a new “unified” A/B redundancy mode that associates a bootloader slot with a rootfs slot. For OE4T, this is equivalent to the “user” redundancy mode that we were already using.

JetPack updates

JetPack 4.6.1 includes the following updates:

VPI 1.2.3
TensorRT 8.2.1

DeepStream update

The DeepStream SDK has been updated from 6.0.0 to 6.0.1 for compatibility with the updated L4T/JetPack. The DeepStream recipes are in the meta-tegra-community repo.

As of 10 Aug 2021, the dunfell branch supports L4T R32.6.1/JetPack 4.6. Users of dunfell that wish to remain at L4T R32.3.1 should switch to the dunfell-l4t-r32.3.1 branch. As of 11 Aug 2021, the master branch was also updated to R32.6.1.

As of 15 Nov 2021, the dunfell, honister, and master branches have all been updated to R32.6.1 with the updated nvidia-l4t-multimedia and nvidia-l4t-multimedia-utils libraries that were released as part of JetPack 4.6 (rev 2) in October 2021. As of 17 Nov 2021, all JetPack 4.6 (rev 2) updates have been applied to the branches.

Changes from L4T R32.5.x/JetPack 4.5

NVIDIA documentation:

Machine changes

R32.6.1 adds support for the Jetson AGX Xavier industrial module. No machine .conf is present in the layer yet for this module.
Support for the Jetson AGX Xavier 8GB module has been removed.

Note that NVIDIA has announced that this L4T release will be the last to support the t210 (TX1/Nano) and t186 (TX2) platforms.

Flash layout file changes for t194 (Xavier) platforms

The flash layout XML files for the Xavier platforms in the L4T BSP have been modified to include new attributes (but no location/size changes). In particular, the xusb-fw partition is now marked oem_signed="true", as cboot now performs signature validation on the USB controller firmware.

Kernel updated to 4.9.253

The Linux kernel in R32.6.1 has been updated to a 4.9.253 base.

U-Boot updates

The U-Boot in L4T R32.6.1 remains at U-Boot v2020.04, with added patches from NVIDIA. In this layer we continue to track the upstream OE-Core U-Boot recipes in each branch, porting NVIDIA patches to our fork of the upstream U-Boot repository.

cboot updates

Flashing/signing tools updates

As mentioned above, the USB controller firmware is now signed on t194 platforms.
The PT (Tegra partition table) partition on t210 platforms now gets a 16-byte trailer added.
Bootloader update payloads (BUPs) have been changed to include more version information in the header.

Container support

The Jetson-specific container runtime (libnvidia-container-tools) was updated to version 0.10, which adds a mechanism for filtering out some of the pass-through mounts.

JetPack updates

JetPack 4.6 includes the following updates:

VPI 1.1
CUDA 10.2.300
TensorRT 8.0.1
cuDNN 8.2.1

JetPack 4.6 (rev2) was released in October 2021 with updates to support the DeepStream 6.0 SDK. (The DeepStream 6.0 SDK recipe has been integrated into the meta-tegra-community layer.)

As of 15 Jul 2021, the master branch supports L4T R32.5.2/JetPack 4.5.1 content for all current Jetson platforms.

Changes from L4T R32.5.1

This minor release includes fixes for issues mentioned in this security bulletin

NVIDIA documentation:

L4T R32.5.2 release notes

See also the notes on L4T R32.5.1 and L4T R32.5.0.

As of 28 Feb 2021, the master branch supports L4T R32.5.1/JetPack 4.5.1 content for all current Jetson platforms.

Changes from L4T R32.5.0/JetPack 4.5

This minor release mainly adds support for the Jetson TX2-NX module.

NVIDIA documentation:

Jetson TX2-NX Module support

Support for the Jetson TX2-NX module, installed in the P3509 carrier board from a Jetson Xavier NX development kit, is added. The MACHINE name is jetson-xavier-nx-devkit-tx2-nx.

JetPack updates

JetPack 4.5.1 is mostly identical to 4.5.0. VPI (Vision Programing Interface) was updated to version 1.0.15.

SDK Manager no longer required

As of 24 Apr 2021, the host-side (x86-64) CUDA recipes have been updated to use package feeds that NVIDIA has added for them as well. SDK Manager is no longer required.

As of 03 Feb 2021, the master branch supports L4T R32.5.0/JetPack 4.5 content for all current Jetson platforms. This support was then ported to the dunfell-l4t-r32.5.0 branch as of 10 Feb 2021.

Changes from L4T R32.4.4/JetPack 4.4.1

NVIDIA documentation:

Machine name changes

Names of machine configuration files have change to match the updated naming convention in L4T R32.5.0. The main change is that all of the machine names now include devkit, to make it clearer that they correspond to developer kits rather than bare modules. Machine names unchanged from the last release are jetson-nano-2gb-devkit, jetson-xavier-nx-devkit, and jetson-xavier-nx-devkit-emmc.

Old name	New name
jetson-tx1	jetson-tx1-devkit
jetson-tx2	jetson-tx2-devkit
jetson-tx2i	jetson-tx2-devkit-tx2i
jetson-tx2-4gb	jetson-tx2-devkit-4gb
jetson-nano-qspi-sd	jetson-nano-devkit
jetson-nano-emmc	jetson-nano-devkit-emmc
jetson-xavier	jetson-agx-xavier-devkit
jetson-xavier-8gb	jetson-agx-xavier-devkit-8gb

Flash layout file changes for Jetson Nano Developer Kit

On the Nano developer kit, all boot-related partitions have been relocated to the QSPI flash in R32.5.0. Only the rootfs partition gets written to the SDcard.

Kernel updated to 4.9.201

The Linux kernel in R32.5.0 has changed from being based on 4.9.140 to 4.9.201.

U-Boot updates

The U-Boot in L4T R32.5.0 changed from a base of U-Boot v2016.07 to U-Boot v2020.04. The meta-tegra layer switched to upstream U-Boot starting with the dunfell-l4t-r32.4.3 branch (and is at v2020.07 in gatesgarth and v2020.10 in master), but relevant patches added by NVIDIA for the L4T release have been ported to our branches.

JetPack updates

Only minor updates were made in JetPack 4.5, with little impact on recipes in meta-tegra.

VPI 1.0

VPI (Vision Programing Interface) went from “developer preview” to general release with version 1.0.12.

SDK Manager no longer required

As of 24 Apr 2021, the host-side (x86-64) CUDA recipes have been updated to use package feeds that NVIDIA has added for them as well. SDK Manager is no longer required.

New Features not implemented in meta-tegra

The following features have been added in L4T R32.5.0/JetPack 4.5 but have not (yet) been implemented in meta-tegra.

A/B rootfs redundancy

R32.5.0 introduced rootfs A/B redundancy for L4T, decoupled from the bootloader A/B redundancy feature (which was only available on TX2 and Xavier platforms).

Encrypted rootfs support

R32.5.0 added a mechanism for setting up the Ubuntu distribution to use LUKS to encrypt the rootfs (on TX2 and Xavier). The implementation is specific to the Ubuntu distro used for L4T/JetPack and the sample Trusty image NVIDIA provides. It was already possible to implement this feature with an OE/Yocto-based distro, so it’s unlikely to be needed in meta-tegra.

As of 30 Oct 2020, the master branch supports L4T R32.4.4/JetPack 4.4.1 content for Jetson TX1, Jetson TX2, Jetson Nano (including Nano 2GB devkit), and Jetson AGX Xavier, and Jetson Xavier NX.

Changes from L4T R32.4.3/JetPack 4.4

NVIDIA documentation:

Flash layout file changes for Tegra210 platforms

NVIDIA has updated their flashing tools in the Tegra210 BSP package so the id= field in the flash layout XML file is used as the partition number in the GPT of the eMMC/SDcard. They have updated their flash layouts to reflect that, with the APP partition appearing at the end of the file with id="1". Bear this in mind if you have customized flash layouts for your TX1 or Nano devices.

Kernel recipe using new branch

The kernel update into the patches-l4t-r32.4 branch did not merge cleanly, so a the linux-tegra_4.9.bb recipe now points to a new oe4t-patches-l4t-r32.4 branch which has our patches rebased on top of the R32.4.4 release from NVIDIA.

JetPack updates

None of the JetPack packages have changed in 4.4.1, except for a minor update to the Tegra MultiMedia API SDK. The update obsoletes a patch for an issue that was present in the R32.4.3/4.4 version of the SDK.

SDK Manager no longer required

As of 24 Apr 2021, the host-side (x86-64) CUDA recipes have been updated to use package feeds that NVIDIA has added for them as well. SDK Manager is no longer required.

As of 13 Jul 2020, the master and dunfell-l4t-r32.4.3 branches support L4T R32.4.3/JetPack 4.4 (GA) content for Jetson TX1, Jetson TX2, Jetson Nano, and Jetson AGX Xavier, and Jetson Xavier NX.

Notable changes from R32.3.1 / JetPack 4.3

NVIDIA documentation:

U-Boot updated to v2020.04

NVIDIA has upstreamed all of their U-Boot changes, so the u-boot-tegra recipe is now based off the upstream U-Boot repository, instead of NVIDIA’s. NVIDIA has not yet created a separate U-Boot configuration for the Nano eMMC (sku 0002) module, so patches have been added for it, as was done for R32.3.1.

Note that with L4T R32.4.3, NVIDIA has defined a region of the eMMC boot1 block (or QSPI flash on platforms that use it) for storing the U-Boot environment block. The u-boot-tegra sources have been changed to use the NVIDIA-defined location and size for that region, which differs from prior versions.

CUDA 10.2

JetPack 4.4 updates CUDA to version 10.2, which is compatible with GCC 8. Recipes for building the GCC 8 toolchain have been added to the meta-tegra/contrib layer.

Fewer SDK Manager downloads required

With NVIDIA now providing direct package feeds for their L4T/JetPack OTA updates, recipes have been updated to use those feeds where possible. ~~The host-side CUDA toolkit must still be downloaded using the SDK Manager, as before.~~ As of 24 Apr 2021, the host-side (x86-64) CUDA recipes have been updated to use package feeds that NVIDIA has added for them as well. SDK Manager is no longer required.

Other Notes

CUDA host tools

If you ran the SDK Manager on Ubuntu 16.04 to download the CUDA host-side tools, you should add the following setting to your build configuration:

CUDA_BINARIES_x86-64 = "cuda-binaries-ubuntu1604"

By default, the recipes assume you used Ubuntu 18.04 and reference that version of the CUDA host-side tools.

Kernel `defconfig` file removed

The kernel (linux-tegra) recipe has been changed to generate the default configuration from the arch/arm64/configs/tegra_defconfig file in the source tree, rather than including the full kernel configuration as a defconfig file. If you have a customized kernel configuration and were overriding the default configuration by supplying your own defconfig file, you will either need to convert your modifications into config fragment files (see the YP Linux Kernel Dev Manual for documentation), or use a .bbappend file to add your defconfig file back into the SRC_URI.

Tegraflash default packaging change

The tegraflash image type now generates a compressed tarball (.tegraflash.tar.gz) by default instead of a ZIP package (.tegraflash.zip), to better utilize sparse file support. See this page for more information.

As of 30 Apr 2020, the master and dunfell-l4t-r32.4.2 branches support L4T R32.4.2/JetPack 4.4 Developer Preview content for Jetson TX1, Jetson TX2, Jetson Nano, and Jetson AGX Xavier. Experimental support for Jetson Xavier NX (eMMC module in Jetson Nano B01 carrier) is also present.

As of 12 Jul 2020, L4T R32.4.3/JetPack 4.4 GA is available on the master branch. R32.4.2/4.4 DP should not be used for new development.

Notable changes from R32.3.1 / JetPack 4.3

U-Boot updated to v2020.04

CUDA 10.2

JetPack 4.4 DP updates CUDA to version 10.2, which is compatible with GCC 8. Recipes for building the GCC 8 toolchain have been added to the meta-tegra/contrib layer.

Fewer SDK Manager downloads required

With NVIDIA now providing direct package feeds for their L4T/JetPack OTA updates, recipes have been updated to use those feeds where possible. The host-side CUDA toolkit must still be downloaded using the SDK Manager, as before.

Other Notes

CUDA host tools

If you ran the SDK Manager on Ubuntu 16.04 to download the CUDA host-side tools, you should add the following setting to your build configuration:

CUDA_BINARIES_x86-64 = "cuda-binaries-ubuntu1604"

By default, the recipes assume you used Ubuntu 18.04 and reference that version of the CUDA host-side tools.

Kernel `defconfig` file removed

As of 01 Aug 2021, the dunfell-l4t-r32.3.1 branch was created off the last L4T R32.3.1-based commit into the dunfell branch, for users wishing to continue with the older BSP. The dunfell branch has been updated with L4T R32.6.1/JetPack 4.6.

As of 26 Apr 2020, the dunfell and zeus-l4t-r32.3.1 branches support L4T R32.3.1/JetPack 4.3 content for Jetson TX1, Jetson TX2, Jetson Nano, and Jetson AGX Xavier. (There is also thud-l4t-r32.3.1, but it is not actively maintained.)

Notable changes from R32.2.x

There are several changes in this version of L4T that required updates to Tegra platform support in this layer.

Bootloader update support

Support for bootloader updates has been added to tegra210 (Jetson-TX1 and Jetson Nano) platforms. The tegra186-redundant-boot recipe has been renamed to tegra-redundant-boot, which installs the l4t_payloader_updater_t210 script on tegra210 platforms. Note that bootloader redundancy on tegra210 is different from tegra186/tegra194 (for example, no A/B slots with failover). See the Bootloader chapter of the L4T documentation for details.

With the wider support for bootloader updates and more module variants that may need different boot-time configuration files, BUP payload packages now support all variants for a MACHINE. Also added is a service that runs at boot time to populate the TNSPEC field of the /etc/nv_boot_control.conf file based on the contents of the EEPROM on the module, so the update tools can select the correct files out of the BUP payload for the specific module in the system. This differs from stock L4T, where the configuration file is written into the rootfs after the module’s EEPROM has been read during the flashing process, but should result in the same TNSPEC as would be present after using L4T’s flash.sh.

Tegra Multimedia API

As of L4T R32.3.1, NVIDIA has stopped providing the Tegra Multimedia API kit with the BSP, so if you need the Multimedia API in your builds, you must download the kit to your NVIDIA_DEVNET_MIRROR directory.

The NVIDIA-specific OpenGL extension header files that used to be extracted from the Multimedia API kit are now obtained from the graphics demos source package in the L4T BSP.

Jetson Nano MACHINE rename

The MACHINE name for the original Jetson Nano developer kit (using SPI flash and an SDcard) has been changed from jetson-nano to jetson-nano-qspi-sd. This aligns with NVIDIA’s naming and will make it easier to distinguish between the older kit and the upcoming newer kit based on the 0002 SKU that uses eMMC.

Single flash layout file for Jetson Nano

Builds for jetson-nano-qspi-sd now use only the unified SPI+SDcard flash layout XML file (flash_l4t_t210_spi_sd_p3448.xml), as this layout file has been updated for compatibility with bootloader updates.

Also changed are the workflows for flashing and creating SDcard images for the Nano. The tegraflash.zip package now includes two shell scripts: doflash.sh for flashing via USB (which now flashes both the QSPI flash and and an SDcard mounted on the device), and dosdcard.sh for creating either a file containing SDcard image or for writing directly to an SDcard mounted on your development host.

TensorRT packaging change

TensorRT 6.0.1 has a more complicated packaging layout than prior versions, but has the same issue as prior versions where NVIDIA uses the exact same .deb package names for the Xavier-specific packages and the non-Xavier packages. To make it clearer which packages are which, the tensorrt recipe looks for the Xavier-specific packages in ${NVIDIA_DEVNET_MIRROR}/DLA and the non-Xavier packages in ${NVIDIA_DEVNET_MIRROR}/NoDLA. You must move the packages yourself once you have downloaded them using SDK Manager.

Example, for Xavier:

  $ cd ~/Downloads/nvidia/sdkm_downloads
  $ mkdir DLA
  $ mv tensorrt*.deb *libnvinfer*.deb libnv*parsers*.deb uff*.deb graphsurgeon*.deb DLA/

Example, for all other platforms:

  $ cd ~/Downloads/nvidia/sdkm_downloads
  $ mkdir NoDLA
  $ mv tensorrt*.deb *libnvinfer*.deb libnv*parsers*.deb uff*.deb graphsurgeon*.deb NoDLA/

Other notes

The following notes from prior releases also apply.

SDK Manager downloads required

JetPack 4.3 content cannot be downloaded anonymously from NVIDIA’s servers. You must use NVIDIA SDK Manager to download the JetPack 4.3 Debian packages to your build host, then add this setting to your build configuration (e.g., in conf/local.conf under your build directory):

NVIDIA_DEVNET_MIRROR = "file://path/to/downloads"

By default, the SDK Manager downloads to a directory called Downloads/nvidia/sdkm_downloads under your $HOME directory, so use that path in the above setting.

CUDA host tools

If you ran the SDK Manager on Ubuntu 16.04 to download the JetPack packages, you should add the following setting to your build configuration:

CUDA_BINARIES_NATIVE = "cuda-binaries-ubuntu1604-native"

By default, the recipes assume you used Ubuntu 18.04 and reference that version of the CUDA host-side tools.

L4T-R32.2.3-Notes

As of 23 Nov 2019, the master and zeus branches support L4T R32.2.3/JetPack 4.2.3 content for Jetson TX1, Jetson TX2, Jetson Nano, and Jetson AGX Xavier.

Please Note

The JetPack 4.2.3 content cannot be downloaded anonymously from NVIDIA’s servers. You must use NVIDIA SDK Manager to download the JetPack 4.2.3 Debian packages to your build host, then add this setting to your build configuration (e.g., in conf/local.conf under your build directory):

NVIDIA_DEVNET_MIRROR = "file://path/to/downloads"

By default, the SDK Manager downloads to a directory called Downloads/nvidia/sdkm_downloads under your $HOME directory, so use that path in the above setting.

If you are building TensorRT for Jetson AGX Xavier, you must create a subdirectory called P2888 under your ${NVIDIA_DEVNET_MIRROR} directory and copy the Xavier-specific tensorrt deb files there. The TensorRT deb files for Jetson TX1/TX2 should remain in the main ${NVIDIA_DEVNET_MIRROR} directory. NVIDIA uses the exact same names for the two sets of deb packages, even though the content for Xavier is different from the other platforms.

If you ran the SDK Manager on Ubuntu 16.04 to download the JetPack packages, you should add the following setting to your build configuration:

CUDA_BINARIES_NATIVE = "cuda-binaries-ubuntu1604-native"

By default, the recipes assume you used Ubuntu 18.04 and reference that version of the CUDA host-side tools.

The L4T BSP files (driver package, sources for gstreamer plugins, etc.) are accessible without a DevNet account, so if your builds only require the BSP, you don’t have to go through these extra steps.

L4T-R32.2.1-Notes

As of 01 Sep 2019, the master branch supports L4T R32.2.1/JetPack 4.2.2 content for Jetson TX1, Jetson TX2, Jetson Nano, and Jetson AGX Xavier.

Please Note

The JetPack 4.2.2 content cannot be downloaded anonymously from NVIDIA’s servers. You must use NVIDIA SDK Manager to download the JetPack 4.2.2 Debian packages to your build host, then add this setting to your build configuration (e.g., in conf/local.conf under your build directory):

NVIDIA_DEVNET_MIRROR = "file://path/to/downloads"

By default, the SDK Manager downloads to a directory called Downloads/nvidia/sdkm_downloads under your $HOME directory, so use that path in the above setting.

If you ran the SDK Manager on Ubuntu 16.04 to download the JetPack packages, you should add the following setting to your build configuration:

CUDA_BINARIES_NATIVE = "cuda-binaries-ubuntu1604-native"

By default, the recipes assume you used Ubuntu 18.04 and reference that version of the CUDA host-side tools.

L4T-R32.2.0-Notes

As of 18 Aug 2019, the master and warrior-l4t-r32.2 branches support L4T R32.2.0/JetPack 4.2.1 content for Jetson TX1, Jetson TX2, Jetson Nano, and Jetson AGX Xavier.

Please Note

The JetPack 4.2.1 content cannot be downloaded anonymously from NVIDIA’s servers. You must use NVIDIA SDK Manager to download the JetPack 4.2.1 Debian packages to your build host, then add this setting to your build configuration (e.g., in conf/local.conf under your build directory):

NVIDIA_DEVNET_MIRROR = "file://path/to/downloads"

By default, the SDK Manager downloads to a directory called Downloads/nvidia/sdkm_downloads under your $HOME directory, so use that path in the above setting.

If you ran the SDK Manager on Ubuntu 16.04 to download the JetPack packages, you should add the following setting to your build configuration:

CUDA_BINARIES_NATIVE = "cuda-binaries-ubuntu1604-native"

By default, the recipes assume you used Ubuntu 18.04 and reference that version of the CUDA host-side tools.

L4T-R32.1.0-Notes

As of 13 Apr 2019, the master and warrior branches support L4T R32.1.0/JetPack 4.2 content for Jetson TX1, Jetson TX2, Jetson Nano, and Jetson AGX Xavier.

Please Note

The JetPack 4.2 content cannot be downloaded anonymously from NVIDIA’s servers. You must use NVIDIA SDK Manager to download the JetPack 4.2 Debian packages to your build host, then add this setting to your build configuration (e.g., in conf/local.conf under your build directory):

NVIDIA_DEVNET_MIRROR = "file://path/to/downloads"

By default, the SDK Manager downloads to a directory called Downloads/nvidia/sdkm_downloads under your $HOME directory, so use that path in the above setting.

Jetson TX1 Notes

NVIDIA does not support Jetson TX1 with L4T R32.1.0, but it does appear to work with this version of the BSP. For production use of Jetson TX1, you should stick with L4T R28.x BSP releases.

L4T-R28.3-Notes

As of 10 Apr 2019, the thud-l4t-r28.3 branch supports L4T R28.3.0/JetPack 3.3 content for Jetson TX1 and Jetson TX2.

L4T-R28.2-Notes

As of 25 Aug 2018, the rocko-l4t-r28.2, sumo and master branches all support the Jetson TX1 with L4T R28.2 and the Jetson TX2 with L4T R28.2.1.

L4T-R28.1-notes

As of 30 Jul 2017, the pyro-l4t-r28.1 branch supports Jetson TX1 and Jetson TX2 builds using L4T R28.1.

Only minimal testing has been performed so far, but core-image-sato images build, and most functionality tested appears to work OK.

Note that with R28.1, the Jetson TX1 boot sequence has been changed to include cboot in the chain of bootloaders, similar to the Jetson TX2. cboot loads U-Boot from the LNX partition in the eMMC.

meta-tegra Wiki Redirects

If you are reading this page you have been redirected from the legacy OE4T wiki pages.

Content in the wiki has been replaced by the content of the mdbook here.

Documentation titles and markdown page names generally track previous wiki page names.

The master branch content is generally the most up-to-date and typically the branch to use. In some cases, however there may be branch specific content for a wiki page.

Outdated Content Redirects

If you are reading this content, the page or section linked here is out of date.

See older braches for relevant content to previous releases.

Contributions welcome to bring this documentation back up to date.

See the OE4T documentation project for a list of ways to contribute to documentation.

Applying-PREEMPT-RT-Real-Time-Kernel-Patches.md

See Outdated-Content-Redirects

Controlling Jetson Pin States

See Outdated-Content-Redirects

I suspect the content on older branch pages is relevant, however the links are all specific to r35. We should either make a generic version of this page with details about how to find content for specific releases or link to r39 content. See https://github.com/OE4T/oe4t.github.io/issues/2

Over the Air Reflashing Process

There may be times when you need to perform the equivalent of a re-flashing of your Jetson-based device without being able to use the normal flashing process via USB. This is possible, although there are some risks, and it requires careful setup and testing.

Possible applications:

You need to alter the layout of the partitions in the Jetson’s eMMC storage.
You need to update a Jetson running software based off an older version of the L4T BSP to a newer version that requires a modified layout of the eMMC and/or SPI flash (for Jetsons that have a SPI flash boot device).
You just need the equivalent of a full “factory reset” that restores the device to a pristine state.

This has been more necessary on previous Jetpack releases where no supported upgrade path existed.

See legacy branch docs content for an implementation specific to old releases which could be customized to support more recent jetpack releases.

Updates to this page to document a similar approach in the current master branch are welcome.

PPS GPIO Support on Jetson TX1 TX2

See Outdated-Content-Redirects

SPI Support

See Outdated-Content-Redirects

Keyboard shortcuts

OE4T Meta Tegra