Jetson carrier board design: Orin NX, PCIe and UEFI boot

A Jetson carrier board is the printed circuit board that hosts an NVIDIA Jetson module and turns it into a product. On a recent Jetson carrier board project, the boot device was a PCIe device that the UEFI firmware does not support, and making it boot took a lot of work. Our advice, after that project, is simple: choose a boot device on NVIDIA's supported list.

Contrary to the usual reading, the hard part of a Jetson Orin NX carrier board is rarely the routing; it is the boot path and the software that has to describe your board. At AESTECHNO, an electronic design firm in Montpellier, we design carrier boards and the embedded Linux that runs on them. This guide covers what the module gives you, the boot devices UEFI supports, the five things NVIDIA says to change for a custom board, our method, a decision matrix and the field report. For the platform itself, start with our guide to NVIDIA Jetson Orin for embedded AI.

What a Jetson carrier board is

A Jetson carrier board is the board an NVIDIA Jetson system-on-module plugs into. The module carries the Orin system-on-chip, its LPDDR5 memory and its power management; the carrier board supplies input power, storage, connectors, cameras, networking and the physical interface to the rest of the product.

The Orin NX and Orin Nano share one form factor. The specification table of NVIDIA's Jetson Orin product page shows that the modules use the same 260-pin SO-DIMM connector and measure 69.6 mm by 45 mm. NVIDIA states that the reference carrier board of the Orin Nano Super Developer Kit is compatible with all Orin NX and Orin Nano modules, which means a carrier designed for this family can host either. That is useful when the edge AI inference workload is not frozen yet: the same board can ship with a smaller or a larger module, and the choice can move with prices.

The developer kit is a carrier board too

The developer kit is a module on NVIDIA's own carrier board. In NVIDIA's naming, the Orin Nano developer kit P3766 combines the module P3767 and the carrier board P3768, and each of the two holds an EEPROM with its board ID. Everything in the Jetson Linux board support package is set up for that pair. Unlike a developer kit, a custom carrier is unknown to the software until you describe it, which is the subject of the sections below.

Why products end up on a custom carrier board

A custom carrier board is the usual answer when a developer kit or an off-the-shelf carrier does not match the enclosure, connectors, power input or certification target of a real product. A custom board keeps the module, which is the expensive and difficult part, and changes only what the product needs.

Module availability makes the effort worth it. NVIDIA's Jetson product lifecycle page lists the Orin NX 16GB, Orin NX 8GB, Orin Nano 8GB and Orin Nano 4GB as available through January 2032, which is long enough to amortise a dedicated board. The trade-off is the one we described in our comparison of COTS and custom electronics: the module stays off the shelf, the board it plugs into is yours. We followed exactly that split on a COM Express project, where the off-the-shelf board was 30 mm too long for the mechanics and drew too much power, and we designed a custom carrier instead.

The module price follows the memory market

A module does not protect a product from memory prices. On a Jetson Orin NX project, the 2025-2026 memory shortage significantly increased the cost of the RAM and the NVMe storage for our customer, and the price of the Jetson modules went up as a consequence. Our article on the 2026 memory shortage and embedded products covers that exposure. For the carrier, it argues for a footprint that accepts several module variants and for not oversizing the NVMe SSD.

What the Orin NX and Orin Nano give the carrier board

The main difference for the carrier is the PCIe generation, the power range and the memory size, since the Orin NX and the Orin Nano share one connector and one outline. The Orin NX supports PCIe up to Gen4 and the Orin Nano up to Gen3, according to NVIDIA's bring-up guide, and neither module has internal storage, so the carrier must provide it.

NVIDIA's Jetson Orin product page describes the Orin NX in 16 GB and 8 GB versions, at up to 100 TOPS between 10 W and 25 W in its original power modes, and the Orin Nano in 8 GB and 4 GB versions, at up to 40 TOPS between 7 W and 15 W. The same page's specification table adds higher power modes: up to 40 W for the Orin NX and up to 25 W for the Orin Nano, the modes behind the 157 and 67 TOPS figures on NVIDIA's Jetson modules page. For a carrier designer, the power range matters more than the TOPS: size the input stage, the thermal path and the enclosure for the highest mode the product may ever enable, not for the mode it ships with.

UPHY lanes are shared, so plan them first

The high-speed lanes of the module are not all independent. NVIDIA's guide warns that not every port can be used, because PCIe, UFS and USB (XUSB) share the UPHY lanes, and that the USB SuperSpeed lanes map to UPHY0 lanes 0 to 2 on the P3767 module. The chosen lane configuration is set in software through the ODMDATA variable, and some choices cost speed: the configuration hsio-uphy-config-40 limits one PCIe root port to Gen2. In our practice, the lane plan is fixed before the schematic, together with the PCI Express link widths and generations each endpoint needs.

Boot devices: choose one the UEFI firmware supports

The boot device of a Jetson Orin carrier board is the storage the UEFI firmware loads the operating system from. NVIDIA's Jetson Linux guide states that "OS boot is supported from eMMC/SD/UFS/NvME/USB", with USB boot on the Orin generation only. Outside that list, the firmware has no driver to read the device, whatever Linux can do later.

UEFI is, in the words of the Wikipedia article on UEFI, "a specification for the firmware architecture of a computing platform", owned by the UEFI Forum. On Jetson, NVIDIA's UEFI chapter of the Jetson Linux Developer Guide explains that UEFI replaced the earlier CBoot bootloader from release 34 onward, and that L4tLauncher is its default OS loader. By default, UEFI then reads the kernel and device tree named in the extlinux.conf file of the root file system.

Why a Linux driver is not enough

Contrary to the common assumption that any device with a Linux driver can hold the root file system, the firmware has to read the boot device before the kernel and its drivers are loaded. In UEFI, device support during boot comes from UEFI drivers, which the Wikipedia article places in the DXE phase, where "UEFI drivers / Option ROMs of PCI / AMBA devices are executed". A PCIe device the firmware has no driver for is invisible at that stage, even though the same device works perfectly once Linux runs.

Boot order and the removable-first default

Boot order matters on a product too. According to NVIDIA, removable devices (SD and USB) take precedence over non-removable ones (eMMC, NVMe, UFS) in the default order. The default can be set through the DefaultBootPriority variable in L4TConfiguration.dts, which NVIDIA notes "only sets the default boot order on the first boot after flashing", or with a flashing overlay such as BootOrderNvme.dtbo. On a field product with a service USB port, we recommend fixing the order so that a USB stick left in a port does not change what boots. NVIDIA also strongly recommends disabling the UEFI shell on production devices.

What NVIDIA says to change for a custom carrier board

The board support package is the software that has to describe a custom carrier board, and NVIDIA lists exactly what changes in it. NVIDIA's module adaptation and bring-up guide for Orin NX and Orin Nano states that, before using the module with a carrier other than the P3768, you must change the kernel device tree, the MB1 and MB2 configurations, the ODM data and the flashing configuration.

Each of the five maps to a hardware decision. The pinmux comes from NVIDIA's Orin NX and Orin Nano pinmux spreadsheet, customised for the board, which generates the pinmux, GPIO and pad-voltage files used by MB1 and the bootloader. The device tree describes the board to Linux; the kernel documentation on the devicetree defines it as "a data structure and language for describing hardware", needed for devices "which cannot be detected by hardware". ODMDATA selects the UPHY lane configuration. MB2 handles the board EEPROM, which is optional. The flashing configuration ties it all together in a board .conf file.

Flashing a custom carrier: keep a USB device-mode port

Production flashing is a hardware requirement as much as a software one. NVIDIA's flashing support chapter says the official method for Orin NX and Orin Nano is initrd flashing, that production systems must use it for successful over-the-air updates, and that on a custom carrier you must "ensure that a USB device mode has been enabled". It also notes that initrd flash is validated on the developer kit. A carrier without an accessible USB device-mode port, and a way to put the module in recovery mode, is a carrier you cannot flash on the production line.

Our method for a Jetson carrier board, step by step

Our method is a seven-step sequence that starts from the boot path and the lane plan, then moves to schematic, stack-up, layout, bring-up and validation. The order matters: the two decisions that are hardest to change after the first prototype, which device boots and which lanes go where, are made first.

Step one is the interface list and the lane plan against NVIDIA's UPHY options. Step two is the boot device, chosen from the UEFI list. Step three is the schematic from NVIDIA's design guide and pinmux spreadsheet, drawn in Altium. Step four is the stack-up: we calculate impedances in ANSYS and Simbeor, then cross-check them against the Polar SI9000 calculation of the PCB fab, as in our PCB stack-up and impedance guide. Step five is layout of the PCIe, USB 3.2 and MIPI CSI-2 pairs following our high-speed PCB design rules. Step six is bring-up with the board support package.

Validation: PCIe compliance and EMC pre-scan

Validation is step seven, and it has its own test procedure. In our lab, PCIe links are checked with a Tektronix oscilloscope and the TekExpress compliance suite, which measures eye diagrams and helps tune equalisation, as explained in our article on eye diagrams and jitter. EMC is checked with an in-house pre-scan before the accredited lab. In the EU, the EMC Directive 2014/30/EU limits emissions and sets immunity requirements, and a carrier with exposed USB and Ethernet connectors will meet the IEC 61000-4-2 electrostatic discharge immunity test, whose 2008 edition the IEC replaced with a 2025 edition.

Field report: booting from a PCIe device outside the UEFI list

This field report is the case of a Jetson carrier board that had to boot from a PCIe device the UEFI firmware does not support. On a recent project, we made it work, but it took a lot of work, and our recommendation since is not to try it: choose a boot device the firmware supports. The solution is confidential, so this field report does not describe how we did it, nor name the device.

What we can share is why this class of problem is hard and how to avoid it. A PCIe device can be perfectly usable once Linux runs; the difficulty is the minute before, when only the firmware is in charge and it needs its own way to read the device. Contrary to what a quick look at a block diagram suggests, "boot from this PCIe device" is not one feature but two: a data path for Linux, and a boot path for UEFI. The data path is about routing and drivers. The boot path is about firmware support, and every hour spent outside NVIDIA's list is an hour not spent on the product.

The software half: a custom Yocto BSP on Orin NX

The board support package is the other half of every carrier. In Q1 2026 we delivered a Jetson Orin NX project with a fully custom board support package developed under Yocto: custom layers, kernel configuration, device tree and root file system. On a custom carrier, the five items NVIDIA lists land in exactly this kind of work. In our practice, the schedule of a Jetson carrier project is set as much by this software as by the PCB, which is why we plan the bring-up from the first schematic review. Our comparison of embedded Linux distributions explains when Yocto is worth its cost.

What we recommend after these projects

We recommend making the boot device a line of the specification, reviewed with the firmware in mind, not a consequence of the storage choice. Despite the appeal of reusing a storage device the product already has, keep the boot on NVMe, eMMC, SD, UFS or USB, and let Linux mount any other PCIe device as data after boot. Even though NVMe on an M.2 Key M slot is the usual answer, check the exact device on the target firmware release early, on the first prototype. On that prototype, we recommend a test procedure that covers PCIe compliance on TekExpress, the boot order with and without removable media, and flashing as it will be done on the line.

Decision matrix: developer kit, off-the-shelf carrier or custom board

The right option is a matter of volume, mechanical fit, interfaces and certification, more than of the module itself. A developer kit suits prototypes; an off-the-shelf carrier suits small series whose interfaces match; a custom board suits products whose enclosure, connectors or boot path differ from the catalogue.

In our practice the question that settles it is whether the product's interfaces and enclosure exist in a catalogue carrier, and whether that carrier boots from a supported device. If both are true, buying is faster. If one fails, a custom board pays for itself, because adapting a catalogue carrier with adapters and cables tends to cost more in EMC and reliability than it saves. The same reasoning is behind our guide on choosing between SoC, SoM, SBC or custom.

Hardware checklist before the first prototype

A hardware checklist is a list of the decisions a first prototype will expose if they were made late: lane plan, boot device, flashing access, power and thermal margins, connectors and the EEPROM. Each line below comes either from NVIDIA's documentation or from general carrier board practice.

Storage first: a Key M slot for an NVMe SSD, which on the M.2 specification carries up to four PCIe lanes; the common 2280 size is 22 mm wide and 80 mm long, and our M.2 Key B, M and E pinout shows the keys. NVIDIA notes the NVMe drive must be attached before boot, and USB boot works with bulk-only mass storage without hot plugging. Wireless next: a Key E slot provides PCIe and USB 2.0 for a Wi-Fi and Bluetooth card. Then power: size the input for the highest power mode of the largest module the board may host, up to 40 W for an Orin NX, with the sequencing and protection covered in our embedded power management guide.

The checklist in a table

Cameras, displays and the rest

MIPI CSI-2 cameras are a common reason to build a Jetson carrier at all, since the developer kit's connectors rarely suit a product. Each camera adds a device tree entry and a lane mapping, so the camera list belongs in the same early lane plan. For longer cable runs and industrial cameras, our guide to industrial video protocols covers HDMI, SDI and CoaXPress, and our USB 3 SuperSpeed article covers USB cameras and their routing.

Bottom line

A Jetson carrier board is a boot path, a lane plan and a board support package wrapped around a module that already does the hard silicon work. Decide those three early and the routing becomes the routine part; decide them late and they drive the re-spin.

• One footprint, two families. Orin NX and Orin Nano share the 260-pin SO-DIMM connector and the 69.6 x 45 mm outline; route to the Orin NX rules if both must fit.
• Boot from the UEFI list. NVIDIA supports OS boot from eMMC, SD, UFS, NVMe and USB on Orin. A PCIe device outside that list was a lot of work for us; we recommend not trying it.
• Plan the UPHY lanes first. PCIe, USB and UFS share lanes, and the ODMDATA choice must match the schematic.
• Five software items per carrier. Device tree, MB1, MB2, ODM data and flash configuration change for any board other than NVIDIA's P3768.
• Keep a way to flash. Initrd flashing is the official method for Orin NX and Orin Nano and needs a USB device-mode port on your carrier.

Related reading: NVIDIA Jetson Orin for embedded AI, the 2026 memory shortage and embedded products, the PCI Express bus, the PCIe card-edge pinout, deploying industrial AI at the edge, CUDA versus OpenCL on an embedded project, the Cyber Resilience Act and embedded Linux, electromagnetic compatibility, CE RED certification, electronic product testing and validation, design for manufacturing, obsolescence management, our COM Express embedded computing work, our hardware design services and our embedded firmware expertise.

Written by Hugues Orgitello, an electronic-design engineer with 10+ years of experience who founded AESTECHNO in Montpellier in 2022.

FAQ: Jetson carrier board design

What is a Jetson carrier board?
It is the printed circuit board an NVIDIA Jetson module plugs into. The module carries the Orin system-on-chip and its LPDDR5 memory; the carrier provides power, storage, connectors, cameras, networking and the physical interface to the product. The Orin NX and Orin Nano use a 260-pin SO-DIMM connector and measure 69.6 by 45 mm, so one carrier can host either family. NVIDIA's developer kit is itself a module on NVIDIA's own carrier, the P3768.

Can one carrier board take both Orin NX and Orin Nano?
Yes. NVIDIA states that the reference carrier board of the Orin Nano Super Developer Kit is compatible with all Orin NX and Orin Nano modules, and both families share the connector and outline. Differences remain: the Orin NX supports PCIe up to Gen4 and the Orin Nano up to Gen3, and their power ranges differ, up to 40 W and 25 W in the higher modes. Route the high-speed pairs to the Orin NX rules and size the input stage and thermal path for the highest mode of the larger module.

Which devices can a Jetson Orin boot from?
NVIDIA's Jetson Linux guide states that OS boot is supported from eMMC, SD, UFS, NVMe and USB, with USB boot on the Orin generation only. The Orin NX and Orin Nano have no internal storage, so an NVMe SSD on an M.2 Key M slot is the usual choice on a custom carrier. Removable SD and USB devices come first in the default boot order, which can be changed with the DefaultBootPriority setting or a flashing overlay.

Can a Jetson boot from an unsupported PCIe device?
Not without significant firmware work. The UEFI firmware loads the kernel using its own drivers, so a device it has no driver for cannot be the boot device, even if Linux supports it later. On a recent Jetson carrier board project we made such a device boot, but it took a lot of work and the solution stays confidential. Our recommendation is to boot from NVMe, eMMC, SD, UFS or USB and mount the other device as data.

What must change in software for a custom carrier?
NVIDIA's bring-up guide for Orin NX and Orin Nano lists five items for any carrier other than the P3768: the kernel device tree, the MB1 configuration with pinmux, GPIO and pad voltages, the MB2 configuration including the optional board EEPROM, the ODM data that selects the UPHY lane configuration, and the flashing configuration file. On a Yocto build, these belong in the custom layers, kernel configuration and device tree of the board support package.