If you already have a Jetson Orin Nano Developer Kit, have a spare Jetson module sitting around, or are buying a standalone module that needs a board to run on, Turing Pi 2.5 gives it a very different home from NVIDIA’s usual developer-kit carrier.
The Jetson can be installed directly as one of the Turing Pi’s compute nodes, with NVMe storage, integrated networking, power control, and remote management available from the same platform. You still get NVIDIA’s JetPack, CUDA, TensorRT, GPU acceleration, and the rest of the Jetson software stack, but without building the system around a standalone developer kit.
In this guide, we move the 8GB Jetson Orin Nano development module from NVIDIA’s developer kit to Turing Pi 2.5, install a 500GB NVMe SSD, flash Jetson Linux directly while the module remains installed in the Turing Pi, bring the node online over Ethernet and SSH, then install JetPack and verify CUDA.
The module does not need to be prepared or flashed on NVIDIA’s carrier board first. Turing Pi 2.5 can expose the Jetson’s recovery interface through its USB OTG connection, allowing NVIDIA’s Linux flashing tools to install the boot firmware and operating system directly while the module stays installed in the board.
Our module is the 8GB P3767-0005 development module supplied with the Jetson Orin Nano Developer Kit. NVIDIA supports it with both the standard jetson-orin-nano-devkit configuration and the higher-performance jetson-orin-nano-devkit-super configuration used in this guide. The Super configuration increases the available power budget and extends the supported clock-frequency steps.
Tested configuration
| Component | Configuration |
| Turing Pi | Turing Pi 2.5 |
| Hardware revision | 2.5.2 |
| Jetson module | Orin Nano 8GB development module, P3767-0005 |
| Turing Pi node | Node 2 |
| Storage | Crucial P310 500GB NVMe |
| Flash host | Ubuntu 22.04 live environment |
| Jetson userspace | Ubuntu 24.04.4 LTS |
| Jetson Linux after update | R39.2.1 |
| Kernel | 6.8.12-1021-tegra |
| JetPack | 7.2.1-b49 |
| CUDA | 13.2 |
| CUDA compiler | V13.2.86 |
| Power mode | 25W |
1. Install the Jetson and prepare the Turing Pi
Power down the Turing Pi completely before installing or removing any compute module or NVMe drive.
Remove the Jetson Orin Nano module from the NVIDIA developer kit and install it into the desired Turing Pi 2.5 node. Install the NVMe SSD assigned to the same node.
Before powering the Jetson, make sure an appropriate heatsink and active cooling solution are installed. This becomes especially important once the Jetson is running the higher-power Super configuration.
Node selection
For this setup, we used Node 2.
We initially attempted the same flashing process with the Jetson installed in Node 1, but repeatedly encountered USB transfer failures during recovery. Moving the same Jetson module and NVMe SSD to Node 2 allowed the recovery and flashing process to complete successfully.
This does not necessarily mean Node 1 will fail on every Turing Pi 2.5 system. It is simply the behavior we observed during this installation, and trying another node is worth keeping in mind if you encounter persistent USB recovery errors.
Connect the Turing Pi and flash host
Connect:
- one of the Turing Pi Ethernet ports to your network so the BMC and compute nodes have network access
- a USB data cable between the Turing Pi 2.5
USB_OTGUSB-C port and the Ubuntu computer that will perform the flash
We performed the flashing from an Ubuntu 22.04 live USB.
Because the live environment had limited writable storage, we kept the Jetson Linux BSP, root filesystem, and Linux_for_Tegra workspace on an existing local disk instead of storing them inside the live USB environment.
2. Prepare Jetson Linux on the Ubuntu host
Download the Jetson Linux Driver Package (BSP) and Sample Root Filesystem from NVIDIA’s JetPack downloads page.
On that page, scroll to Jetson Linux Downloads and Documents → Jetson Linux 39.2.1 and download:
- Driver Package (BSP)
- Sample Root Filesystem
Make sure both files are from the same Jetson Linux release.
Our original installation used Jetson Linux R39.2.0 and was later updated to R39.2.1. If you are following this guide now, NVIDIA provides R39.2.1 directly, so you can start with the current R39.2.1 BSP and root filesystem.
For R39.2.1, the downloaded files are:
Jetson_Linux_R39.2.1_aarch64.tbz2
Tegra_Linux_Sample-Root-Filesystem_R39.2.1_aarch64.tbz2
From the Ubuntu flashing computer, extract the BSP, unpack the sample root filesystem into it, then install NVIDIA’s flashing prerequisites and userspace binaries:
tar xf <Jetson_Linux_package>.tbz2
sudo tar xpf <Sample_Root_Filesystem>.tbz2 \
-C Linux_for_Tegra/rootfs/
cd Linux_for_Tegra
sudo ./tools/l4t_flash_prerequisites.sh
sudo ./apply_binaries.shThe prerequisites script installs the host-side packages required by NVIDIA’s flashing tools. apply_binaries.sh then adds NVIDIA’s drivers and userspace components to the root filesystem that will be installed on the Jetson.
Disable the missing carrier EEPROM check
Before flashing, one adjustment is required for a carrier board without the EEPROM expected by NVIDIA’s reference configuration.
On Jetson Orin Nano and Orin NX under R39.2, the relevant MB2 configuration file is:
Linux_for_Tegra/bootloader/generic/BCT/tegra234-mb2-bct-misc-p3767-0000.dts
Find:
cvb_eeprom_read_size = <0x100>;
and change it to:
cvb_eeprom_read_size = <0x0>;
You can make the same change directly with:
sed -i 's/cvb_eeprom_read_size = <0x100>/cvb_eeprom_read_size = <0x0>/g' \
bootloader/generic/BCT/tegra234-mb2-bct-misc-p3767-0000.dts
Setting cvb_eeprom_read_size to 0x0 tells the Jetson boot configuration not to attempt to read the carrier-board EEPROM. NVIDIA documents this adjustment for Orin Nano/NX modules used with carrier boards that do not provide that EEPROM.
Create a user before flashing
Because this installation will be managed headlessly, create the Linux user before flashing. This skips the normal first-boot OEM setup and gives us an account that can be used immediately over SSH once the Jetson comes online.
Run:
sudo ./tools/l4t_create_default_user.sh \
-u <username> \
-p <password> \
-n <hostname> \
--accept-license
For example:
sudo ./tools/l4t_create_default_user.sh \
-u turingpi \
-p '<temporary-password>' \
-n jetson \
--accept-license
Use a temporary password here rather than a password you reuse elsewhere, since it is being supplied directly on the command line.
After the first successful login, change it with:
passwd
At this point, the Jetson Linux filesystem is prepared, the carrier EEPROM check is disabled, and a default user is ready. The next step is to put the Jetson into recovery mode through the Turing Pi BMC.
3. Put the Jetson into recovery mode
Before flashing, the Jetson needs to be placed into Force Recovery Mode, where it appears to the Ubuntu flashing computer as an NVIDIA USB recovery device.
SSH into the Turing Pi BMC:
ssh root@<BMC_IP>
For the Jetson installed in Node 2, the Turing Pi 2.5 CLI sequence we used was:
tpi power off --node 2
tpi usb flash --node 2
tpi power on --node 2
This powers down the node, configures it for flashing through the Turing Pi USB recovery path, and powers it back on in recovery mode.
At this point, make sure a USB-C data cable is connected between the Turing Pi 2.5 USB_OTG port and the Ubuntu flashing computer.
Return to the Ubuntu flashing computer and run:
lsusb
The Jetson should appear as an NVIDIA APX device:
NVIDIA Corp. APX
Our P3767-0005 module appeared as:
0955:7523 NVIDIA Corp. APX
USB product IDs differ between Jetson modules. Our P3767-0005 appeared as 0955:7523; look for an NVIDIA recovery device with vendor ID 0955, which may be labeled APX by lsusb.
If APX does not appear, do not start flashing. Recheck the USB data cable, the Turing Pi 2.5 USB_OTG connection, selected node, power state, and flash mode first.
Read the Jetson module information
This step is not required for every installation. We used it while troubleshooting our initial flashing attempts to explicitly read the board information detected from the module.
From Linux_for_Tegra, run:
sudo ./flash.sh \
--read-info \
--no-flash \
jetson-orin-nano-devkit-super-nvme \
internal
Rather than flashing the Jetson, this generates a command for reading its board information:
bootloader/readinfocmd.txt
Run that command while the Jetson remains in recovery mode:
cd bootloader
sudo bash ./readinfocmd.txt
Our module reported:
BOARDID=3767
FAB=300
BOARDSKU=0005
CHIP_SKU=00:00:00:D5
RAMCODE_ID=2
These values describe our specific module configuration. Do not copy them into your own flashing command without first confirming the values reported by your Jetson.
4. Flash Jetson Linux directly from Turing Pi 2.5
With the Jetson in recovery mode and visible to the Ubuntu host as an NVIDIA APX device, it can now be flashed while remaining installed in Turing Pi 2.5.
Warning: the following command erases the target NVMe. Back up anything you need first.
From the Linux_for_Tegra directory on the Ubuntu flashing computer, run:
sudo ./l4t_initrd_flash.sh \
--erase-all \
jetson-orin-nano-devkit-super \
internal
In our setup, after explicitly reading the module information in the previous section, the successful flash supplied those detected board values:
sudo BOARDID=3767 \
FAB=300 \
BOARDSKU=0005 \
CHIP_SKU='00:00:00:D5' \
RAMCODE_ID=2 \
./l4t_initrd_flash.sh \
--erase-all \
jetson-orin-nano-devkit-super \
internal
These values came from our P3767-0005 module. If you need to supply board information explicitly, use the values reported by your own Jetson rather than copying ours.
The successful flash ended with:
Flash is successful
Reboot device
Cleaning up...
At this point, Jetson Linux had been written to the NVMe while the module remained installed in Turing Pi 2.5. There was no need to move it back to NVIDIA’s developer-kit carrier for flashing.
Once flashing is complete, return the node to normal operation from the Turing Pi BMC:
tpi advanced normal --node 2
If needed, power-cycle the node:
tpi power off --node 2
tpi power on --node 2
The Jetson can now boot normally from the newly flashed NVMe.
5. First boot, NVMe, networking, and SSH
Once the Jetson boots normally, find its IP address from your router’s DHCP client list or scan the local network.
For example:
sudo nmap -sn 192.168.0.0/24
Replace 192.168.0.0/24 with the subnet used by your own network.
Once you identify the Jetson’s address, connect using the account created before flashing:
ssh <username>@<JETSON_IP>
The actual IP address will depend on your network and DHCP server.
Verify the Jetson Linux installation
Once connected, check the kernel, Ubuntu release, Jetson Linux release, and detected hardware model:
uname -a
cat /etc/os-release
cat /etc/nv_tegra_release
cat /proc/device-tree/model
These checks confirm that the Jetson has booted into the expected Linux environment before we continue with the NVIDIA software stack.
Verify the NVMe root filesystem
Confirm that the root filesystem is actually running from the NVMe:
findmnt /
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL
Our system showed:
/dev/nvme0n1p1 /
with the Crucial P310 detected as:
CT500P310SSD8
This confirms that the Jetson is booting and running its root filesystem directly from the NVMe installed in Turing Pi 2.5.
Check networking and SSH
Check the active network interfaces and assigned addresses:
ip -br addr
Then verify that SSH is enabled and running:
systemctl is-enabled ssh
systemctl is-active ssh
Verify the NVIDIA platform tools
Finally, make sure NVIDIA’s basic platform tools are responding correctly:
sudo nvpmodel -q
timeout 5 sudo tegrastats
At this stage, tegrastats is only a sanity check, not a benchmark. We simply want to confirm that the Jetson can report processor activity, memory usage, temperatures, frequencies, and platform power data correctly.
Our Super configuration reported:
NV Power Mode: 25W
1
The 1 is the active nvpmodel mode ID. For the Jetson Orin Nano 8GB Super configuration, NVIDIA defines the 25W profile as mode ID 1.
At this point, the Jetson is booting from NVMe, reachable over Ethernet and SSH, and responding correctly to NVIDIA’s platform tools. The next step is to update Jetson Linux and install the complete JetPack software stack.
6. Update Jetson Linux and install JetPack
The BSP gives us a bootable Jetson Linux system, but the complete JetPack software stack is installed separately.
Before installing JetPack, check the current Jetson Linux release:
cat /etc/nv_tegra_release
Our initial flash was based on Jetson Linux R39.2.0. If you flashed R39.2.1 directly, your system will already report REVISION: 2.1; you can still update the installed packages before installing JetPack. Before installing the rest of the JetPack components, update the installed BSP packages:
sudo apt update
sudo apt dist-upgrade
sudo reboot
The reboot is important because the update can include changes to the Jetson Linux kernel, bootloader, and other platform components.
Once the Jetson comes back online, reconnect over SSH and verify the updated release:
cat /etc/nv_tegra_release
uname -a
Our installation moved from R39.2.0 to:
# R39 (release), REVISION: 2.1
with:
Linux jetson 6.8.12-1021-tegra
Install JetPack
With Jetson Linux updated, install the complete JetPack software stack:
sudo apt install -y nvidia-jetpack
The nvidia-jetpack package installs the NVIDIA compute and development components associated with the installed Jetson Linux release, including CUDA, cuDNN, TensorRT, and supporting libraries and tools.
Once installation finishes, verify the installed JetPack package:
dpkg-query --show nvidia-jetpack
Our final system reported:
nvidia-jetpack 7.2.1-b49
At this point, the Jetson is running Jetson Linux R39.2.1 with the JetPack 7.2.1 software stack installed. The next step is to verify CUDA and confirm that the NVIDIA development environment is working correctly.
7. Verify CUDA and the NVIDIA stack
Installing JetPack gave us CUDA 13.2, but there was one final environment detail to fix before the CUDA compiler could be called directly from the shell.
Running:
nvcc --version
initially returned:
nvcc: command not found
CUDA itself was installed correctly. The compiler was available at:
/usr/local/cuda/bin/nvcc
The CUDA bin directory simply was not included in the shell’s PATH.
Add CUDA to the shell environment
We added the CUDA binary and library directories to the shell environment:
echo 'export PATH=/usr/local/cuda/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc
source ~/.bashrc
The PATH addition makes commands such as nvcc available directly from the shell.
Now run:
nvcc --version
Our Jetson returned:
Cuda compilation tools, release 13.2, V13.2.86
This confirms that the CUDA 13.2 compiler installed through JetPack is present and accessible.
Final verification
As a final check, verify the JetPack package, Jetson Linux release, CUDA compiler, power mode, and NVIDIA platform monitoring tools:
dpkg-query --show nvidia-jetpack
cat /etc/nv_tegra_release
nvcc --version
sudo nvpmodel -q
timeout 5 sudo tegrastats
At the end of our installation, the system looked like this:
| Check | Result |
| Jetson Linux | R39.2.1 |
| Ubuntu | 24.04.4 LTS |
| Kernel | 6.8.12-1021-tegra |
| JetPack | 7.2.1-b49 |
| CUDA | 13.2 |
nvcc | V13.2.86 |
| Root filesystem | NVMe |
| Ethernet | Working |
| SSH | Working |
nvpmodel | 25W |
tegrastats | Working |
| Direct Turing Pi flash | Successful |
With Jetson Linux, JetPack, CUDA, NVMe boot, networking, and NVIDIA’s platform tools all working, the Jetson is ready to be used as a GPU-accelerated node inside Turing Pi 2.5.
Conclusion
Turing Pi 2.5 turns the Jetson Orin Nano module from part of a standalone developer-kit setup into a GPU-accelerated node inside a larger, remotely managed compute system.
The Jetson still brings the parts that make NVIDIA’s platform valuable: CUDA, TensorRT, JetPack, hardware-accelerated vision, and efficient AI inference. What changes on Turing Pi is everything around it. The module can sit alongside other compute nodes, use its own NVMe storage, share the board’s networking, and be powered, recovered, and managed through the Turing Pi BMC.
That makes the Jetson far more useful for systems where the GPU is only one part of the workload. An Orin node can handle inference or vision while other nodes run storage, databases, orchestration, monitoring, web services, or general-purpose compute, all inside the same compact platform.
This guide establishes the base for that architecture. Our 8GB Jetson Orin Nano is now running the Super configuration directly in Turing Pi 2.5, booting from NVMe, reachable over Ethernet and SSH, and running Jetson Linux R39.2.1, JetPack 7.2.1, CUDA 13.2, and the 25W power profile.
The setup also remains serviceable without moving the module back to NVIDIA’s carrier. Turing Pi’s USB recovery path can expose the Jetson directly to NVIDIA’s flashing tools, so the node can be rebuilt while it stays installed in the system.
With the platform working, the rest of this series can focus on what the combination is actually capable of: local AI, accelerated containers, computer vision, inference performance, orchestration, monitoring, and mixed-node workloads built around NVIDIA compute inside Turing Pi.
Troubleshooting
NVIDIA APX does not appear in lsusb
Do not start flashing until the Jetson appears as an NVIDIA APX device on the Ubuntu flashing computer.
Check:
lsusb | grep -i nvidia
If nothing appears:
- Confirm the Jetson node is powered off.
- Set the correct Turing Pi node to flash mode.
- Power that node back on.
- Make sure a USB-C data cable is connected between the Turing Pi 2.5
USB_OTGport and the Ubuntu flashing computer. - Confirm that the correct Turing Pi node was selected.
- Try another known-good USB data cable.
Once the connection is working, lsusb should show an NVIDIA APX device before you continue with the flash.
ERROR: might be timeout in USB write
We repeatedly encountered this error with the Jetson installed in Node 1 during the early recovery stage, including while transferring MB2.
Moving the same Jetson module and NVMe SSD to Node 2 allowed the read-info process and subsequent flash to complete successfully.
If the failure consistently occurs during the initial recovery USB transfer, try another Turing Pi node before changing the BSP or assuming there is a problem with the Jetson module.
cvm.bin does not exist
We encountered this after an earlier USB recovery transfer had already failed.
In our case, the missing cvm.bin file was a downstream symptom rather than the original problem. Check the earlier lines in the flashing log for USB or RCM transfer errors before troubleshooting cvm.bin itself.
Jetson disappears after sudo reboot
After a large Jetson Linux update, the Jetson may take longer than a normal Linux reboot because kernel, bootloader, and other platform changes can be applied during the process.
First check whether the Jetson has returned to the network:
sudo nmap -sn 192.168.0.0/24
Replace 192.168.0.0/24 with the subnet used by your network.
Then check whether SSH is available:
sudo nmap -p 22 <JETSON_IP>
During our update, the host briefly returned No route to host. Shortly afterward, the same address reappeared with port 22 open and we were able to reconnect normally.
nvcc: command not found
If nvcc is not found after installing JetPack, first verify that the CUDA compiler is actually installed:
ls -l /usr/local/cuda/bin/nvcc
ls -ld /usr/local/cuda*
If it exists, add CUDA to the shell environment:
echo 'export PATH=/usr/local/cuda/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc
source ~/.bashrc
Then run nvcc --version again.
Do not install Ubuntu’s similarly named nvidia-cuda-toolkit package as a workaround. For this Jetson setup, CUDA is installed as part of the NVIDIA JetPack software stack.
FAQ
Can you flash a Jetson Orin Nano while it is installed in Turing Pi 2.5?
Yes. That is the exact setup tested in this guide. Turing Pi 2.5 can expose the Jetson’s recovery interface through its USB_OTG connection, allowing NVIDIA’s Linux flashing tools to communicate with and flash the module without moving it back to NVIDIA’s developer-kit carrier.
Do I need NVIDIA SDK Manager?
No. This workflow uses NVIDIA’s Linux_for_Tegra BSP tools directly, so SDK Manager is not required.
Why did you use Node 2 instead of Node 1?
We initially tried the same setup in Node 1 but repeatedly encountered USB recovery-transfer failures. Moving the same Jetson module and NVMe SSD to Node 2 allowed the read-info and flashing process to complete successfully.
This was the behavior we observed on our system and does not necessarily mean Node 1 will fail on every Turing Pi 2.5 setup.
Does flashing erase the NVMe?
Yes. The flashing command used in this guide includes:
--erase-all
This erases the target NVMe, so back up anything important before starting.
Why is the carrier EEPROM modification necessary?
NVIDIA’s reference configuration expects a carrier-board EEPROM. On a carrier that does not provide that EEPROM, setting cvb_eeprom_read_size to 0x0 prevents the flashing process from attempting to read it.
How do I know the Super configuration is active?
The Jetson was flashed using:
jetson-orin-nano-devkit-super
and running:
sudo nvpmodel -q
reported:
NV Power Mode: 25W
1
The 25W profile confirms that the Jetson is running the Super power configuration used in this guide.
Is the Jetson ready for AI workloads at this point?
Yes. The NVIDIA software foundation is in place: Jetson Linux, JetPack, CUDA, NVMe boot, networking, SSH, and NVIDIA’s platform tools are all installed and working.
Actual workloads such as LLM inference, computer vision, accelerated containers, inference servers, and multi-node AI deployments are intentionally left for later articles in this series.