JetPack 7.2.1 vs 6.2.2 on Jetson Orin: Migration Guide 2026

Last Updated: September 24, 2026

For the first time since Orin shipped, an Orin board and a Thor board can run the same JetPack. JetPack 7.2.1, released on August 11, 2026 with Jetson Linux 39.2.1, moves the Orin family from Ubuntu 22.04 and kernel 5.15 to Ubuntu 24.04 and kernel 6.8. It also moves CUDA from 12.6 to 13.2 (13.2.2 on NVIDIA’s current downloads page) and TensorRT from 10.3 to 10.16. So the question of JetPack 7.2.1 vs 6.2.2 is not about a point release. It is a platform re-base, and every binary artifact your product ships sits on the moving layers. This guide explains what actually changed, which of the reported speedups come from software and which come from a new power mode, what you must rebuild, and when staying on JetPack 6.2.2 is still the right call. The core argument is simple. The flash takes an afternoon; the real migration cost lives in your product’s binary surface, and you can size that cost before you touch a board.

What this covers: a verified version matrix, the mechanism behind each breaking change, a decode of the published benchmarks, a migration decision tree, a rebuild dependency map, a step-by-step runbook, and the failure modes that bite in production.

Context and Background

JetPack is NVIDIA’s software bundle for Jetson modules. It combines Jetson Linux (the board support package, or BSP, historically called L4T for “Linux for Tegra”) with the CUDA-X compute stack: CUDA, cuDNN, TensorRT, VPI, multimedia APIs and the higher-level SDKs. Until mid-2026 the line was cleanly split by hardware. JetPack 6.x served Orin (AGX Orin, Orin NX and Orin Nano) on Jetson Linux 36.x. JetPack 7.0 and 7.1 served only the Blackwell-based Jetson Thor.

JetPack 6.2.2 is the last stop on the Orin-only line. It maps to Jetson Linux 36.5, keeps kernel 5.15 and Ubuntu 22.04, and was described in the forum announcement (reprinted by JetsonHacks around February 6, 2026) as a minor upgrade over 6.2.1 with the same libraries. Its main job was fixing a CUDA memory allocation problem introduced in the preceding update. In other words, 6.2.2 is a stability release on a mature base.

JetPack 7.2, announced at GTC Taipei on June 1, 2026, broke the split. The OE4T meta-tegra release notes describe it as the first JetPack release to support both the Orin family and AGX Thor (T4000 and T5000). JetPack 7.2.1 followed on August 11 as the production refresh. NVIDIA’s JetPack downloads page lists AGX Thor Developer Kit, T5000, T4000 and “Jetson Orin Family” as supported hardware for 7.2.1.

The architectural reason is the JetPack 7 series’ alignment with Arm’s Server Base System Architecture (SBSA). SBSA is a hardware and firmware specification that lets generic Arm server software boot and run in a standard way. For Jetson, that alignment means a unified CUDA install across Arm targets and slightly changed manual flashing instructions. It also means Orin inherits Thor’s software foundation. Seeed Studio calls this a “platform reset,” and the phrase fits: the Orin you flash with 7.2.1 is running a different OS generation, kernel, firmware base and compute stack than the one on 6.2.2.

That also changes how you build production images. NVIDIA announced official Yocto Project support starting with JetPack 7.2, with NVIDIA owning CI and releases for the OE4T layer. If you are weighing that path, our comparison of Yocto OE4T vs Ubuntu L4T for Jetson production images covers the build-system trade-off in depth.

JetPack 7.2.1 vs 6.2.2: What Changed in the Stack

Direct answer: JetPack 7.2.1 (Jetson Linux 39.2.1) moves Jetson Orin from Ubuntu 22.04, kernel 5.15, CUDA 12.6, cuDNN 9.3.0 and TensorRT 10.3.0 to Ubuntu 24.04, kernel 6.8, CUDA 13.2.2, cuDNN 9.20.0 and TensorRT 10.16.2. It shares one software base with Jetson Thor. Upgrading requires a full reflash and rebuilding every kernel module, CUDA extension and TensorRT engine.

Figure 1: The same Tegra234 Orin module under two stacks. JetPack 6.2.2 is Orin-only; JetPack 7.2.1 is shared with AGX Thor.

Read the figure from left to right. The Orin silicon at the bottom is unchanged, but every software layer above it moves at once: the rootfs, the kernel, the CUDA toolkit and the inference runtime. The JetPack 7.2.1 chain also carries SDKs that have no equivalent version on the 6.2.2 side in this comparison, and it is fed by Thor as well as Orin. That shared base is the strategic point of the release.

The verified version matrix

The table below uses NVIDIA’s 7.2.1 downloads page and the OE4T release notes. Cells marked “not verified” are ones I could not confirm from a primary source for 6.2.2, so they are left blank rather than guessed.

Component	JetPack 6.2.2 (Jetson Linux 36.5)	JetPack 7.2.1 (Jetson Linux 39.2.1)	Migration impact
Ubuntu rootfs	22.04	24.04	Python 3.10 to 3.12, new glibc and toolchain
Kernel	5.15 (linux-jammy-nvidia-tegra)	6.8 (linux-noble-nvidia-tegra, 6.8.12-based)	All out-of-tree modules rebuilt and often ported
CUDA	12.6	13.2.2	CUDA extensions and native builds recompiled
cuDNN	9.3.0	9.20.0	Usually source-compatible; relink and retest
TensorRT	10.3.0	10.16.2	Every serialized engine rebuilt
VPI	not verified	4.1.3	Check API deltas if you use VPI
DeepStream	not verified	9.1	Pipeline configs retested
Holoscan	not in this comparison	3.9.0	New option for sensor pipelines
Nsight Systems	not in this comparison	2026.3	Profiling traces not comparable across versions
Container Toolkit	not in this comparison	1.19 (shipped with ISO)	Replaces nvidia-docker in Yocto builds
Vulkan	not in this comparison	1.4; Vulkan SC 1.0	Graphics and safety-critical rendering paths
Isaac ROS	supported	“Coming soon” on the 7.2.1 page	Hard blocker for Isaac ROS users today

For reference, the intermediate Thor-only JetPack 7.1 carried CUDA 13.0, cuDNN 9.12.0 and TensorRT 10.13.3. NVIDIA’s June launch post for 7.2 describes the unified stack as CUDA 13.0-based, while the 7.2.1 downloads page currently lists CUDA 13.2.2. An earlier revision of that page, captured in our research notes, listed 13.2.1, so NVIDIA appears to have refreshed the CUDA point release after GA. Treat the live 7.2.1 page, and nvcc --version on your own device, as authoritative for what you install today.

Why “platform re-base” is the right mental model

A point release keeps the application binary interface (ABI) stable. You upgrade with APT, your kernel modules still load and your TensorRT engines still deserialize. JetPack 6.2.x in-family upgrades worked that way. You edited /etc/apt/sources.list.d/nvidia-l4t-apt-source.list to point at r36.5 and ran apt dist-upgrade.

A re-base breaks four ABIs at once. The kernel module ABI changes because 6.8 is more than two years of mainline development past 5.15 (5.15 shipped in late 2021, 6.8 in early 2024). The C and C++ userland ABI moves with Ubuntu 24.04’s toolchain and glibc. The CUDA major version changes from 12 to 13. The TensorRT serialization format changes, as it does between any two TensorRT versions. Each break has a different blast radius, which is why the migration needs a dependency map rather than a checklist.

This is also why the APT path does not cross the major version. Seeed’s guidance for 6.x to 7.2 is a full flash, and it explicitly warns against relying on apt upgrade for production custom carriers. I agree, and would go further: treat the move to Jetson Linux 39.2.1 as a new product baseline, with its own golden image, validation run and rollback image.

What 7.2.1 adds on top of 7.2

JetPack 7.2.1 is a production refresh, and most of its new features are aimed at Thor or at video workflows. For Orin teams, four items matter.

• Super Mode by default on the Orin Nano Developer Kit. The ISO now flashes the Orin Nano dev kit with the Super Mode configuration by default. If your benchmarks assumed the older default power profile, your baseline has shifted.
• PyNvVideoCodec 2.2 on Jetson. This is the first time the library is supported on Jetson. It keeps decoded frames GPU-resident via DLPack and CUDA device buffers, and its ThreadedDecoder pre-decodes on a background thread. The Video Codec SDK itself arrived on Jetson with JetPack 7.1 for Thor.
• A unified jetson-videosdk agent skill. It lives in the NVIDIA-AI-IOT jetson-device-skills and jetson-bsp-skills repositories. It covers discovering capabilities, generating encoder recipes, benchmarking throughput, latency and quality, and validating codec workflows. NVIDIA scopes it explicitly: it does not cover GStreamer, V4L2, AI models or application-level pipeline building in this release.
• PCN support and fixes. It adds support for PCN211461 and PCN211462 and fixes known issues and security vulnerabilities.

The headline Thor feature is T3000 emulation on the AGX Thor Developer Kit, using the flash configuration p3834-0008-as-p5767-0000-nvme. It matters to Orin teams planning a future step up. Our Jetson T3000 vs T4000 vs T5000 module selection guide covers that decision, and a shared JetPack makes it far cheaper to keep both options open.

Deeper Analysis: Performance, Migration Paths and What You Must Rebuild

The case for migrating rests on two claims: the new stack is faster, and it is the future. The second is clearly true. The first needs decoding, because the most-cited numbers mix a software change with a hardware power-mode change.

Decoding the published benchmarks

Two data sources exist as of this writing. The first is NVIDIA’s own. JetPack 7.2 introduced a Super Mode (a MAXN_SUPER power model) for Jetson AGX Orin 32GB. According to NVIDIA’s JetPack 7.2 launch post, Super Mode raises GPU frequency from 930 MHz to 1.3 GHz and allows power envelopes up to 60 W. That lifts AI performance from 200 to 241 TOPS. NVIDIA’s model table shows token-per-second gains of roughly 1.1x to 1.3x for the 32GB Super configuration, for example Qwen 3.6 27B moving from 4 to 5 tokens per second.

There is an important catch that the launch coverage glosses over. NVIDIA presents the 32GB Super as a module configuration, and the flash configuration for it targets a specific module SKU (p3701-0004). In an August 2026 thread on NVIDIA’s developer forums, a user who moved an existing AGX Orin 32GB developer kit (module SKU 0000) to JetPack 7.2.1 found no MAXN_SUPER entry in nvpmodel. The Super flash configuration then failed with a “module SKU 0000 detected” error, and an NVIDIA moderator confirmed that SKU 0000 does not support the Super configuration. So do not assume that flashing 7.2.1 unlocks 241 TOPS on the AGX Orin 32GB modules you already have. Check your module SKU first.

The second is a third-party measurement from Seeed Studio’s JetPack 7.2 deep dive. It ran llama.cpp with Qwen3.5-27B at Q4_K_M quantization, using -ngl 999 -fa on -ub 512 -t 12. Seeed compared JetPack 6.2 (L4T 36.4.3, CUDA 12.6) against JetPack 7.2 (L4T 39.2, CUDA 13.x), using what Seeed describes as the same AGX Orin 32GB module.

Metric (Seeed, third-party)	JetPack 6.2	JetPack 7.2	Change
Memory after model load	24.6 GB	14.7 GB	about 40% lower
GPU frequency	930 MHz	1.36 GHz	about 46% higher
Prompt processing	18.2 tok/s	25.8 tok/s	+41.8%
Token generation	4.3 tok/s	5.5 tok/s	+27.9%

Methodology caveats. This is one workload and a single run configuration. The baseline is JetPack 6.2, not 6.2.2. The two runs used different carrier boards: an AGX Orin H01 for 6.2 and a reComputer Classic J5011 for 7.2. Most importantly, the GPU clock difference reflects the new high-performance power mode, so the gains are not purely software.

Separating the clock dividend from the software dividend

Here is the analysis that the headline numbers hide. The GPU clock ratio is 1.36 / 0.93 = 1.46, a 46% increase. Prompt processing, which is compute-bound matrix work, rose 41.8%. That is close to the clock ratio, which suggests most of the prefill gain is simply the clock. Token generation rose 27.9%, well below the clock ratio. That pattern is typical of decode, which on large models is usually limited by memory bandwidth rather than raw compute.

NVIDIA’s own table points the same way. Qwen 3.6 27B goes from 4 to 5 tokens per second between the standard and Super configurations. Because the table comes from the JetPack 7.2 launch post, it is best read as a Super-mode gain with the software held roughly constant, although NVIDIA does not spell out the exact test software. Seeed’s 4.3 to 5.5 generation result sits in the same band. My reading, which is an inference rather than a measured fact, is that the throughput gains in Seeed’s test are mostly the clock dividend.

The memory reduction is different. A drop from 24.6 GB to 14.7 GB is about 9.9 GB, or 40%, and a power mode does not explain it. Candidate causes include a different memory accounting under the new kernel, the JetPack 7.2 memory optimizations NVIDIA promotes, or differences in the two llama.cpp builds. Seeed does not isolate these. On a unified-memory SoC, tools also count memory-mapped model pages differently, so I would re-measure before planning capacity around that number.

The practical conclusion is useful. If you run an AGX Orin 32GB module in the Super SKU, JetPack 7.2.x gives you a mode worth about 20% more peak TOPS (241 vs 200) and 1.1x to 1.3x token throughput in NVIDIA’s table, at a higher power budget. If your AGX Orin 32GB modules are the original SKU, the forum evidence above says the Super configuration will not flash, so plan on software-only gains. If you run an Orin NX or Orin Nano, the AGX figures do not apply at all; those modules already gained their own Super modes with JetPack 6.2, so expect gains closer to whatever the software alone provides. Measure your own model on your own carrier board. For Orin Nano specifically, the power-mode history is covered in our Jetson Orin Nano 2 vs Orin Nano Super comparison.

Choosing a migration path

The right path depends on three questions. Does the product depend on Isaac ROS? Is it a developer kit or a custom carrier board? And do you build images with Ubuntu L4T or with Yocto?

Figure 2: Migration decision tree for moving an Orin product from JetPack 6.2.2 to JetPack 7.2.1.

The first gate is Isaac ROS, because it is binary. As of the 7.2.1 downloads page, Isaac ROS support is listed as “coming soon.” The second gate splits developer kits, which can use the unified ISO, from custom carriers, which need a ported BSP. The third gate splits Ubuntu-based images from Yocto images built on the OE4T layer. All paths converge on the same rebuild and validation phase before a staged rollout.

Path A: developer kit, evaluation or lab fleet. Use the unified ISO written to a USB stick. There is no SD-card image for the Orin Nano Developer Kit on the JetPack 7 branch. After flashing, install the compute stack with sudo apt update && sudo apt install nvidia-jetpack, or use SDK Manager. This path is quick and fine for development, but it is not a production process.

Path B: custom carrier with Ubuntu L4T. Port your BSP changes to Jetson Linux 39.2.1. That means device tree changes, pinmux, any custom UEFI configuration and every out-of-tree driver. Orin’s UEFI configuration handling now follows the Thor R38.4 approach, with in-tree general, minimal and simple configs, so custom UEFI configs need rework. OP-TEE moves to 4.6 and the UEFI/EDK2 base is updated. Then flash with the initrd flash tooling and the board configuration for your module, as described in the 39.2.1 developer guide.

Path C: custom carrier with Yocto. On the JetPack 7.2 layer, only initrd-flash is supported. The nvidia-docker recipe is removed in favour of nvidia-container-toolkit. New recipes add the SIPL API, the nvsiplcamerasrc GStreamer plugin and python3-jetson-io. NVIDIA committed to contributing the validated 7.2.1 update to OE4T by August 25, 2026, so check the layer’s branch state before you pin a revision.

The decision matrix

Situation	Recommendation	Reasoning
Robot stack built on Isaac ROS	Stay on 6.2.2 for now	Isaac ROS on 7.2.1 is listed as “coming soon”
AGX Orin 32GB Super SKU running LLMs or VLMs	Migrate, prioritise	Super Mode gives 241 vs 200 TOPS, plus newer CUDA and TensorRT
Original-SKU AGX Orin 32GB running LLMs	Migrate for the stack, not the clocks	Super config is SKU-gated; gains are software-only
Fleet mixing Orin and Thor	Migrate	One BSP, OS and container base across both families
Custom carrier with several OOT camera drivers	Migrate on a planned schedule	Kernel 6.8 driver ports are the long pole
Stable single-model vision appliance, no new features needed	Defer, plan for 2027	6.2.2 is stable, but its Ubuntu 22.04 base ages first
New product starting design now	Start on 7.2.1	Avoids a second migration mid-lifecycle
Audio-heavy product using Tegra ASoC	Migrate with audio retest	Most Tegra ASoC drivers moved in-tree

What must be rebuilt, and why

The rebuild list is where teams underestimate the work. Each item breaks for a specific mechanical reason, and knowing the reason tells you how hard the fix is.

Figure 3: Rebuild dependency map. Each platform change on the left invalidates a class of artifacts on the right.

Each left-hand node is one layer that changes between the two JetPacks. Each right-hand node is an artifact class your product probably ships. Count the right-hand nodes that apply to your product; that count, not the flash procedure, is the size of your migration.

Kernel modules and out-of-tree drivers. Kernel modules are compiled against a specific kernel’s internal interfaces, which mainline Linux does not keep stable. A module built for 5.15 will not load on 6.8. Rebuilding is not always enough, because internal APIs used by camera sensor drivers, such as the V4L2 subdevice and async registration interfaces, changed over those releases. Budget porting time for every OOT camera, GMSL serializer, CAN or custom FPGA driver.

Audio drivers moved in-tree. Many Tegra ASoC audio drivers moved from the out-of-tree nvidia-kernel-oot-alsa package into mainline. They include snd-soc-tegra210-admaif, -ahub, -i2s, -dmic, -mixer, -amx, -adx, the snd-soc-tegra186-asrc and -dspk drivers, and snd-soc-tegra-machine-driver. The ADSP and virtualization audio drivers remain out-of-tree. If your image packages, blacklists or patches the old OOT audio modules, that packaging needs to change.

CUDA extensions and native code. Anything compiled against CUDA 12.6 needs recompiling for CUDA 13.2. That includes PyTorch custom ops, CuPy kernels, custom CUDA libraries and llama.cpp builds. The Python move from 3.10 to 3.12 on Ubuntu 24.04 compounds this, because every compiled wheel in your virtual environments must be rebuilt or replaced. The ecosystem is moving: NVIDIA’s Isaac GR00T N1.7 reference install targets Thor and Orin on JetPack 7.2 with CUDA 13.2 and Python 3.12.

TensorRT engines. A serialized TensorRT engine is tied to the TensorRT version that built it, so engines from 10.3 will not run under 10.16. This is standard TensorRT behaviour, not a JetPack quirk. Keep your ONNX models and build scripts as the source of truth, and treat engines as build outputs. Custom plugins also need recompiling; if you are touching them anyway, our TensorRT IPluginV2 to IPluginV3 migration guide shows how to avoid a second rewrite later.

Containers. Container images built on r36 base images carry CUDA 12 userland libraries. Rebuild them against a JetPack 7 base rather than assuming they run on a 39.2.1 host. Under SBSA alignment, container choices widen, but you should validate each image on the target rather than trust tags.

A worked sizing example

Here is an estimate for a hypothetical product, with the arithmetic shown so you can substitute your own numbers. Assume one custom carrier, three camera drivers, two module SKUs (Orin NX 16GB and AGX Orin 32GB), and six production models served in FP16 and INT8.

• Engines: 6 models × 2 precisions × 2 SKUs = 24 engines. TensorRT recommends building on the target device type, so each SKU gets its own set. At an assumed 10 to 20 minutes per build, that is 4 to 8 hours of automated build time.
• Drivers: 3 camera drivers at an assumed 3 to 8 engineer-days each for port and bring-up gives 9 to 24 engineer-days.
• BSP and UEFI port: an assumed 5 to 10 engineer-days for device tree, pinmux and UEFI config rework.
• Validation: an assumed 72-hour soak per SKU plus I/O regression, roughly 5 engineer-days.

Total: about 19 to 39 engineer-days, dominated by driver work. These figures are my planning estimates, not measurements. The shape, however, is robust: the flash is trivial, engines are cheap because they are automated, and hand-maintained kernel code is expensive.

The Migration Runbook

Direct answer: Migrate an Orin product to JetPack 7.2.1 in six stages: inventory your binary surface, port the BSP, perform a full reflash with initrd flash or the ISO, install nvidia-jetpack, rebuild modules, wheels and engines, then validate I/O, thermals and long-duration stability before a staged rollout with a 36.5 rollback image.

Figure 4: The migration sequence between engineer, flashing host, Orin target and build CI.

The sequence shows who does what. The host performs a full reflash; the target boots the new OS and installs the compute stack; CI pushes rebuilt artifacts; the device rebuilds its engines locally and reports back. The soak test gates the decision to promote or roll back.

Stage 1: Inventory the binary surface

Before touching hardware, record what is installed on a 6.2.2 golden unit. These commands are standard on Jetson Linux and Ubuntu:

cat /etc/nv_tegra_release
uname -r
nvcc --version
dpkg -l | grep -E "nvidia-l4t|tensorrt|cudnn|cuda-toolkit"
find /lib/modules/$(uname -r) -name "*.ko*" -newer /etc/nv_tegra_release
pip list --format=freeze > pip-freeze-jp622.txt

The find line is a heuristic for modules added after the base install. Cross-check it against your build system. The goal is a complete list of every artifact on the right side of Figure 3.

Stage 2: Port the BSP

For custom carriers, apply your device tree and pinmux changes to the Jetson Linux 39.2.1 sources. Rework custom UEFI configs against the new general, minimal and simple configs. Port each out-of-tree driver to kernel 6.8 and build it in CI against the linux-noble-nvidia-tegra headers. Do the driver work first, because it is the long pole.

Stage 3: Full reflash

Developer kits can use the unified ISO on a USB stick. Custom carriers use initrd flash with the board configuration for the module, following the 39.2.1 developer guide, because the SBSA alignment changed the manual flashing instructions. Do not attempt an in-place apt upgrade from r36 to r39. Keep a known-good 36.5 image and the flashing host setup that produced it.

Stage 4: Install the compute stack and verify versions

sudo apt update && sudo apt install nvidia-jetpack
cat /etc/nv_tegra_release
uname -r
nvcc --version
sudo nvpmodel -q

Confirm the kernel reports a 6.8 build and nvcc reports CUDA 13.2. Check the active power mode with nvpmodel -q, because mode IDs and defaults differ between modules and releases. On an Orin Nano dev kit flashed from the 7.2.1 ISO, expect Super Mode by default.

Stage 5: Rebuild artifacts

Rebuild engines on the device from ONNX, for example:

/usr/src/tensorrt/bin/trtexec --onnx=detector.onnx --saveEngine=detector_fp16.engine --fp16

Recreate Python virtual environments on Python 3.12, and install wheels built for CUDA 13 and aarch64. Rebuild llama.cpp and any CUDA extension from source. Rebuild container images on a JetPack 7 base.

Stage 6: Validate and roll out

Follow a checklist in the spirit of Seeed’s post-upgrade list. Confirm versions. Check GPU frequency, power draw and thermals in your target power mode. Exercise cameras, GMSL links, Ethernet, CAN, USB and M.2 devices. Confirm every out-of-tree driver loads. Run your PyTorch, TensorRT, llama.cpp and CUDA extension workloads. Finish with a long-duration stress test, and only then promote to a canary slice of the fleet.

Trade-offs, Gotchas, and What Goes Wrong

Isaac ROS is a genuine blocker. If your robot runs Isaac ROS, the 7.2.1 page lists support as “coming soon.” Do not migrate a production robot on a promise. Stay on 6.2.2, build your kernel-driver ports on a branch, and switch when NVIDIA publishes a supported Isaac ROS release for 7.2.x.

Super Mode is tied to the module SKU. The AGX Orin 32GB Super flash configuration checks the module SKU, and NVIDIA staff have confirmed on the forums that the original SKU 0000 module does not support it. Read the SKU from the module label or the flash log before you put a throughput gain in a business case.

Super Mode costs power and heat. Super Mode on the AGX Orin 32GB allows up to 60 W. An enclosure designed for the standard mode’s thermal budget may throttle, which erases the gain and adds jitter. Validate thermals at your worst-case ambient temperature before enabling it in the field. Power-supply headroom on custom carriers needs the same check.

Benchmarks from other boards will mislead you. The most-cited third-party result compares different carrier boards, a different baseline release and different power modes. Your gains will depend on your module, carrier, model, precision and power mode. Re-measure your own workload on both stacks at the same power mode to isolate the software effect.

Camera drivers are the long pole. Out-of-tree sensor and serializer drivers often lean on kernel interfaces that changed between 5.15 and 6.8. Vendors of GMSL cameras and carrier boards may lag NVIDIA’s release by weeks or months. Ask each supplier for a 39.2.1 driver date before committing to a schedule.

Fleet OTA across the major version is unproven for most teams. In-family 36.x updates could use APT. Across r36 to r39, assume a full reflash unless the 39.2.1 developer guide documents a supported image-based update path for your module and you have tested it. Units in the field without physical access need a tested recovery path before you start.

Pinned revisions drift. The OE4T 7.2.1 contribution had a target date of August 25, 2026. Yocto users should pin a specific layer revision and re-verify it, rather than track a moving branch into production.

Staying put has a cost too. JetPack 6.2.2 sits on Ubuntu 22.04, whose standard support window closes in 2027, while 24.04 runs to 2029. Every quarter you defer, more upstream software, including NVIDIA’s own reference stacks, targets the new base. Deferral is a valid choice, but it should be a dated plan.

Practical Recommendations

Treat JetPack 7.2.1 as a new product baseline, not a patch. Size the migration by the artifacts it invalidates, and start with the ones you cannot automate. Engines and wheels are cheap because a build script regenerates them. Kernel drivers and UEFI configs are expensive because a person has to port them.

For most Orin teams without an Isaac ROS dependency, migrating in the next one or two quarters is the right call. AGX Orin 32GB modules in the Super SKU gain the most, through Super Mode; confirm your SKU before counting on it. Mixed Orin and Thor fleets gain the most operationally, through a single BSP and OS. Teams starting new designs should begin on 7.2.1 so they do not face a second re-base mid-lifecycle.

If you defer, write down the date and the trigger. Good triggers include Isaac ROS support on 7.2.x, a vendor driver release for your cameras, or a dependency that requires CUDA 13.

Checklist:

• [ ] Confirm Isaac ROS status for 7.2.x if your stack depends on it.
• [ ] Inventory kernel modules, CUDA extensions, wheels, engines and containers on a 6.2.2 golden unit.
• [ ] Get 39.2.1 driver commitments from camera and carrier vendors.
• [ ] Port device tree, pinmux, UEFI configs and OOT drivers to kernel 6.8.
• [ ] Full reflash; never cross r36 to r39 with apt.
• [ ] Install nvidia-jetpack; verify kernel 6.8, CUDA 13.2 and TensorRT 10.16.
• [ ] Rebuild engines on-device from ONNX; rebuild Python 3.12 environments and containers.
• [ ] Benchmark both stacks at the same power mode to isolate the software effect.
• [ ] Validate thermals and power at the target mode, then run a 72-hour soak.
• [ ] Keep a 36.5 rollback image; roll out to a canary slice first.

Frequently Asked Questions

Can I upgrade from JetPack 6.2.2 to 7.2.1 with apt?

No, not safely. APT upgrades worked within the JetPack 6.2.x family, where you pointed the NVIDIA L4T source list at r36.5 and ran apt dist-upgrade. Moving to Jetson Linux 39.2.1 changes the Ubuntu release, kernel, firmware base and CUDA major version at once. Seeed explicitly advises a full flash and warns against relying on apt upgrade for production custom carriers. Plan a full reflash with the ISO or initrd flash, then install the compute stack with sudo apt install nvidia-jetpack.

Does JetPack 7.2.1 support Isaac ROS on Jetson Orin?

Not yet, as of this writing. NVIDIA’s JetPack 7.2.1 downloads page lists Isaac ROS support as “coming soon.” If your robot depends on Isaac ROS packages, the conservative choice is to stay on JetPack 6.2.2 in production. You can still start the expensive work in parallel, especially porting out-of-tree camera and sensor drivers to kernel 6.8. Switch once NVIDIA publishes a supported Isaac ROS release for 7.2.x and you have validated it on your own hardware.

Will my TensorRT engines work after upgrading to JetPack 7.2.1?

No. JetPack 6.2.2 ships TensorRT 10.3.0 and JetPack 7.2.1 ships TensorRT 10.16.2. Serialized TensorRT engines are tied to the TensorRT version that built them, so every engine must be rebuilt. This is standard TensorRT behaviour. Keep ONNX models and build scripts as your source of truth, and rebuild engines on the target device type using trtexec or the TensorRT API. Custom plugins must also be recompiled against the new TensorRT and CUDA 13.

Is JetPack 7.2.1 faster than 6.2.2 on Jetson Orin?

Sometimes, but be careful which number you quote. NVIDIA’s Super Mode for AGX Orin 32GB raises AI performance from 200 to 241 TOPS by lifting GPU clocks and power, but NVIDIA forum staff say the original SKU 0000 module cannot use the Super configuration. A third-party Seeed test showed 41.8% faster prompt processing and 27.9% faster generation in llama.cpp. However, that test changed power mode, carrier board and baseline release together. Much of the throughput gain tracks the higher GPU clock. Benchmark your own model at the same power mode on both stacks.

Which Orin modules does JetPack 7.2.1 support?

NVIDIA’s 7.2.1 downloads page lists the “Jetson Orin Family” alongside AGX Thor Developer Kit, T5000 and T4000. The OE4T release notes for 7.2 name AGX Orin, Orin NX and Orin Nano as the Orin members previously supported in JetPack 6. For the Orin Nano Developer Kit, there is no SD-card image on the JetPack 7 branch, so use the unified ISO on a USB stick. The 7.2.1 ISO flashes that dev kit in Super Mode by default.

Should I start a new Jetson Orin product on JetPack 6.2.2 or 7.2.1?

Start on 7.2.1 unless you depend on Isaac ROS today. JetPack 7.2.1 gives Orin the Ubuntu 24.04 base, kernel 6.8, CUDA 13.2 and a software foundation shared with Thor. That makes a later move to Thor modules much cheaper. Starting on 6.2.2 means a second platform migration during your product’s life, because its Ubuntu 22.04 base leaves standard support in 2027. If Isaac ROS is required, prototype on 6.2.2 but keep your drivers building for 6.8.

Further Reading

• Jetson Orin Nano 2 vs Orin Nano Super: what changed and which to buy
• Yocto OE4T vs Ubuntu L4T: choosing a Jetson production image strategy
• TensorRT 11 vs 10: migrating plugins from IPluginV2 to IPluginV3
• Jetson T3000 vs T4000 vs T5000: selecting a Thor module
• NVIDIA JetPack downloads and release notes (primary source for 7.2.1 component versions)
• OE4T meta-tegra JetPack 7.2 / L4T R39.2.0 release notes (kernel, audio driver, UEFI and Yocto changes)
• Seeed Studio JetPack 7.2 deep dive (third-party benchmark and post-upgrade checklist)

By Riju — about