NVIDIA Jetson Module Compatibility Guide

Official relationship source: NVIDIA Jetson FAQ.[1] The word “compatible” on this page never replaces the current data sheet, product design guide, migration guide or carrier validation record.

Which Jetson module families are hardware-compatible?

The matrix below translates NVIDIA's official summary into an engineering action. “Pin- and form-factor-compatible” still allows interface, power-mode and storage differences. “Form-factor-compatible” means the outline relationship is useful for mechanical planning; it does not authorize power-on.

Swipe the table to review every compatibility condition.

Choose the module group before comparing performance

Portfolio positioning source: NVIDIA Jetson Modules.[2] Hardware relationships source: NVIDIA Jetson FAQ.[1]

Classify a proposed Jetson module migration

This tool summarizes the family-level relationship in NVIDIA's FAQ. It does not know the exact carrier schematic, module SKU, power mode or software branch, so its output is the first review step rather than an approval.

A developer kit is not the production assembly

NVIDIA states that developer kits are intended for development and prototyping and are not for production use. The kit module may have a different storage configuration or sales status from a separately orderable production module. Production modules carry their own operating-life, validation, PCN and warranty framework.

Release-gate question

What assumption still belongs to the kit?

Replace the kit's carrier, module type, power adapter, fan, boot media, recovery access and lab airflow with evidence for the production unit. A model benchmark on a desk is not proof of closed-enclosure performance or factory recoverability.

• Identity: production-module part number and P-number, memory size, commercial or Industrial type.
• Hardware: released carrier schematic/layout, connector, retention and production thermal stack.
• Software: versioned board configuration, pinmux, device tree, drivers, flash layout and local patches.
• Factory: recovery access, secure provisioning, serial traceability, test coverage and RMA method.
• Supply: lifecycle snapshot, PCN/EOL monitoring, origin needs and approved purchasing channel.

Developer-kit and module distinction: NVIDIA Jetson FAQ.[1]

JetPack support is a module-and-release decision

CUDA-X and the JetPack model make higher-level application reuse practical, but the boot chain, board configuration, kernel, device tree, camera stack and drivers remain platform-specific. The current archive shows overlapping generations; it does not promise that one flash image or container set works unchanged everywhere.

Snapshot dated August 27, 2026. NVIDIA releases and support lists change. Confirm the archive and release notes when the project freezes its branch.[3]

Swipe the table to compare software ownership across branches.

A custom carrier requires a custom, versioned BSP

NVIDIA's module adaptation guide describes production porting from a developer kit to another hardware platform. The current guide includes separate Thor, AGX Orin and Orin NX/Nano paths, covering board naming, MB1/MB2 configuration, pinmux, device tree, USB, PCIe, UPHY, storage and flashing. The exact files and procedures depend on the selected Jetson Linux release.

The software should identify the module and carrier at boot and reject an unknown or unsafe combination. A fallback device tree or default power mode can turn a configuration mistake into damaged hardware or an intermittent field failure.

Release-specific production porting guidance: NVIDIA Jetson Module Adaptation and Bring-Up.[6]

Migration failures usually hide in the routed interfaces

UPHY and PCIe: count controllers, not only lanes

A total lane count does not prove a usable topology. Lanes belong to controllers, can share UPHY resources with USB or other interfaces, and need valid reference clocks, reset timing and widths. A requirement for two x4 NVMe devices plus one x4 network controller totals 12 lanes, but the target must expose three independent x4-capable paths in the required mapping.

MIPI CSI cameras: payload is only the first number

Camera compatibility includes D-PHY or C-PHY support, lane count, connector pinout, clocks, reset and I2C signals, voltage domains, virtual channels, the sensor driver and ISP path. Four uncompressed 1920 × 1080 cameras at 30 fps and 12 bits per pixel create about 2.99 Gbit/s of image payload before protocol overhead, blanking and metadata.

USB, display, Ethernet and low-speed I/O

USB role and VBUS switching, recovery-mode access, Type-C control, hub topology, display output and Ethernet PHY requirements are carrier-specific. GPIO, I2C, SPI, UART and CAN names can hide different voltages, boot states, pull resistors, drive strength and pinmux functions. Build a pin-by-pin intersection sheet for any multi-module carrier, including every reserved and no-connect instruction.

Power, cooling, storage and recovery must move with the module

Budget source power from the complete workload

Suppose a compact system assigns 25 W to the module, 8 W to cameras and USB devices, and 6 W to NVMe and networking. The 39 W load becomes about 43.3 W at 90% conversion efficiency. Applying a 20% planning margin yields a 52 W input target.

NVIDIA's FAQ notes that Orin Super modes can require more carrier power and thermal capability. For Orin NX 40 W modes, the carrier needs an HV rail, and the production thermal design must support the intended mode. A module that boots at a lower profile is not evidence that the carrier supports the advertised maximum configuration.

Cooling is a mechanical and performance interface

Match the module heat spreader or thermal-transfer structure, mounting pattern, interface material, contact pressure and keep-outs. Run sustained production-like workloads in the closed enclosure and log ambient, module temperatures, clocks, throttling flags, fan speed, power mode and inference latency. Average temperature alone can hide short throttling events that break a real-time budget.

Storage and factory flashing are part of compatibility

Developer and production configurations can use different storage paths: microSD, eMMC, QSPI plus NVMe or another supported target. The current NVIDIA quick-start tables tie module type, carrier, configuration name and flash destination together. Define root filesystem, inactive update partition, model storage, secure boot, rollback and force-recovery access before the pilot build.

• Can factory software select the correct board configuration from the module SKU and carrier revision?
• Can an interrupted update recover without opening the enclosure or losing traceability?
• Does secure boot change RMA, module replacement or factory access?
• Does the inactive partition hold the real signed image with margin?
• Are flash logs, software hashes and serial numbers retained as production evidence?

Documented case: Serve Robotics moved from Xavier to Orin

NVIDIA-published customer case • Not YURUNOX project experience

Software continuity helped, but the result came from a complete robot platform

NVIDIA reports that Serve Robotics progressed from Xavier to AGX Orin as its delivery robots evolved. In NVIDIA's case study, the third-generation robots use Jetson Orin and gained a reported five-times compute improvement for video processing, while the fleet had completed more than 100,000 deliveries with a reported 99.8% completion rate.

The case also reports more than 12 hours of battery life per charge. Those results belong to Serve's robot, operating model and validation process; they are not universal Jetson benchmarks and do not establish that Xavier and Orin are drop-in carrier replacements.

The transferable lesson is architectural: shared Jetson software can preserve development momentum, but successful migration still lives inside a redesigned or qualified product platform. The production decision must include sensor throughput, enclosure thermals, power mode, battery budget, storage, remote support and field data collection.

• Published fact: NVIDIA describes the Xavier-to-Orin platform progression and reported fleet results.
• Engineering inference: software reuse reduced migration friction, but hardware compatibility still requires exact carrier evidence.
• Buyer consequence: request module, carrier, BSP and validation records as a package rather than buying “an Orin” by family name.

Source: NVIDIA Serve Robotics customer story.[9]

Four common Jetson migration scenarios

Lifecycle compatibility can invalidate a technically successful design

NVIDIA publishes “available through” dates for production modules. A replacement should support the remaining production and service horizon after qualification time, not merely be orderable today. Developer kits do not carry the same availability commitment.

Swipe the table to review the lifecycle snapshot.

These dates are a dated planning snapshot, not a purchase guarantee. Confirm the current lifecycle page, module status, PCNs, authorized supply and last-time-buy conditions before approval.[4]

What evidence should accompany a Jetson module RFQ?

A useful quotation starts with the exact module and the platform it must enter. Family names such as “Orin NX” do not capture memory, origin, industrial status, module P-number or full orderable part number. The carrier and software baseline must be equally specific.

The NVIDIA Download Center is the starting point for current module data sheets, product design guides, pin/function documents, carrier files, supported-component lists and PCNs.[8] For sourcing support, review YURUNOX's NVIDIA page, its quality assurance process and the purchasing experience.