ZED Box Orin NX 16GB - JetPack 7.2 flash fails after RCM boot: "Device ping failed after RCM boot"

ccastellanos-code · August 27, 2026, 2:20pm

Hi,

We are trying to upgrade/reflash a ZED Box Orin NX 16GB to JetPack 7.2 using the current official Stereolabs flashing procedure.

We have already followed the Stereolabs documentation and troubleshooting recommendations and investigated several similar topics in this forum. The failure is highly reproducible and always occurs at the same point, immediately after the RCM boot payload has been successfully transferred.

I am including the complete context and the tests already performed below.

HARDWARE / CURRENT SYSTEM / OBJECTIVE

Device:

Stereolabs ZED Box
NVIDIA Jetson Orin NX 16GB / Tegra234
NVMe: ~256 GB
GMSL2 / ZEDBox Duo capture card
MAX96712 deserializer
ZED X Mini camera
Recovery VID:PID: 0955:7323
Board information reported during flashing:
- Board ID: 3767
- Version/FAB: 303
- SKU: 0000
- Revision: F.1

Before starting the upgrade, the ZED Box was working and able to boot its existing operating system.

The currently installed software is:

JetPack 6.2
L4T 36.4.4
Ubuntu 22.04
ZED X Driver 1.4.1
ZED SDK 5.2.3
Linux kernel observed from the running system: 5.15.148-tegra aarch64

Target system:

JetPack 7.2
Jetson Linux / L4T R39.2.1 used by the current Stereolabs package
Ubuntu 24.04 target root filesystem
Kernel contained in the prepared BSP: 6.8.12-1021-tegra

Flashing script:

zedbox_all_usb_flash_7.2.sh

Our objective is to perform a clean installation/update of this ZED Box from its currently working JetPack 6.2 / L4T 36.4.4 / Ubuntu 22.04 installation to the current Stereolabs JetPack 7.2 / Ubuntu 24.04 image using the official ZED Box flashing procedure.

FLASHING HOST

The flashing host is:

Ubuntu 22.04.5 LTS
Running from a Live USB environment
x86_64 PC
Not a VM
Not WSL/WSL2

The BSP itself is NOT stored on the Live USB filesystem.

The working directory is located on the internal NVMe/ext4 partition of the host:

/mnt/msi/zedbox_flash

BSP directory:

/mnt/msi/zedbox_flash/zedbox_jp72/Linux_for_Tegra

The filesystem containing the BSP has approximately:

576 GB total
~180 GB free during testing

Therefore, there is substantially more than the 80 GB required by the Stereolabs documentation.

PROCEDURE

We followed the current Stereolabs ZED Box Orin flashing procedure for JetPack 7.2.

The ZED Box was placed in Force Recovery Mode and verified from the host with:

lsusb | grep 0955

Result:

0955:7323 NVIDIA Corp. APX

The flashing environment was then launched using the Stereolabs script with BSP_ROOT pointing to the prepared BSP.

The BSP preparation succeeds and the failure happens during the actual flash.

FORCE RECOVERY MODE WORKS

Force Recovery itself appears to work correctly.

The host consistently detects:

0955:7323 NVIDIA Corp. APX

This matches the expected recovery VID:PID for a ZED Box Orin NX 16GB.

RCM communication with the Tegra also works.

During the flash, the tool successfully reads board information:

Board ID(3767) version(303) sku(0000) revision(F.1)

and communicates with the boot ROM / MB2 applet.

Therefore, the problem is not simply that the unit fails to enter Force Recovery Mode.

EXACT POINT OF FAILURE

The RCM stage completes successfully.

Relevant output:

Entering RCM boot

BR_CID: 0x80012344705E031B1C0000000C020040

Sending bct_br
Sending mb1
Sending psc_bl1
Sending bct_mb1

…

The number of images in blob is 19
blobsize is approximately 105 MB

…

BL: version 1.0.1.17-t234-54845784-9b0d5809
last_boot_error: 0

Sending bct_mem
Sending blob

RCM-boot started

After this point the script enters:

Step 3: Start the flashing process

Mounting NFS folder from this host
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
…

It never succeeds.

Eventually:

Error: Timeout
Error: Device ping failed after RCM boot.
Error: This can be due to XUSB not being enabled or device failed to boot.
Error: Please retrieve the serial log to debug further.
Cleaning up…
FLASH FAILED.

The failure is reproducible.

USB BEHAVIOR DURING RCM → INITRD TRANSITION

We monitored lsusb and dmesg continuously during the flash.

Before RCM boot:

0955:7323 NVIDIA Corp. APX

After “RCM-boot started”, the device disconnects/reconnects, but it never reaches the expected initrd flashing state.

Instead, it remains/reappears as:

0955:7323 NVIDIA Corp. APX

Example host kernel messages:

usb 1-3: USB disconnect

usb 1-3: new high-speed USB device using xhci_hcd
usb 1-3: New USB device found, idVendor=0955, idProduct=7323
usb 1-3: Product: APX
usb 1-3: Manufacturer: NVIDIA Corp.

This behavior repeats.

We also monitored:

/dev/ttyACM*

throughout the transition.

No ttyACM device appeared during the failed RCM → initrd boot.

The important point is therefore:

Recovery/APX communication works
→ RCM payload is transferred
→ “RCM-boot started”
→ target does not become reachable by l4t_initrd_flash
→ target remains/reappears as APX
→ timeout

USB CABLE / HOST USB PORT TESTS

We have already tested the physical USB connection.

Tests performed:

Changed USB cable
Tested the original cable supplied/used with the ZED Box
Changed USB port on the host computer
Reconnected the device multiple times
Re-entered Force Recovery Mode
Power-cycled the ZED Box
Repeated the flash procedure

With the original cable, the ZED Box can reliably enumerate as APX and the complete RCM boot blob is transferred successfully.

The failure after “RCM-boot started” remains unchanged.

We also reviewed the forum topic:

“Cannot update Zedbox to Jetpack 6.2 - Device failed to boot to the initrd flash kernel”

We saw that in that case a very short (~10 cm) USB cable eventually solved the problem.

We have tested different cables, including the original one, but we have NOT specifically tested a 10 cm USB cable because we do not currently have one available.

If such a short cable is considered mandatory/recommended for JetPack 7.2 flashing, please let us know.

USB AUTOSUSPEND

Following the Stereolabs troubleshooting guide, USB autosuspend was disabled on the Ubuntu host:

sudo bash -c ‘echo -1 > /sys/module/usbcore/parameters/autosuspend’

Verified with:

cat /sys/module/usbcore/parameters/autosuspend

Output:

-1

The flashing behavior remained exactly the same.

NFS / HOST FLASH REQUIREMENTS

The NFS service required by l4t_initrd_flash was checked.

nfs-kernel-server is active.

UFW is inactive.

The NVIDIA flashing tool also reports:

UFW is not active. NFS port is accessible.
No VPN connection detected.

Therefore, the failure does not appear to be caused by the host firewall/NFS service.

BSP / ROOTFS PREPARATION

The BSP has been successfully unpacked and populated.

The package uses:

Jetson_Linux_R39.2.1_aarch64.tbz2
Tegra_Linux_Sample-Root-Filesystem_R39.2.1_aarch64.tbz2

The Stereolabs files are also present:

zedbox_device_trees_392.tar
zedbox_rootfs_392.tar

The root filesystem contains:

rootfs/etc/passwd
rootfs/etc/shadow
rootfs/etc/hostname

NVIDIA files are present, including:

rootfs/usr/lib/aarch64-linux-gnu/tegra → nvidia

and:

rootfs/lib/modules/6.8.12-1021-tegra

The Stereolabs patched iwlwifi modules are also present.

We compared the actual files in the BSP with the contents of the Stereolabs patch archives using SHA256.

For example, the hashes match for:

tegra234-p3768-0000+p3767-0000-nv.dtb
tegra234-mb2-bct-misc-p3767-0000.dts
tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi
p3509-a02-p3767-0000.conf
iwlwifi.ko
iwlmvm.ko

Therefore, the Stereolabs device-tree/rootfs patches appear to actually be applied to the BSP.

DEVICE TREE / XUSB CHECK

Because the flash error specifically mentions XUSB, we decompiled and inspected:

tegra234-p3768-0000+p3767-0000-nv.dtb

The XUSB pad controller is enabled:

padctl@3520000 {
compatible = “nvidia,tegra234-xusb-padctl”;
status = “okay”;
}

USB2 lanes include:

usb2-0:
nvidia,function = “xusb”;
status = “okay”;

usb2-1:
nvidia,function = “xusb”;
status = “okay”;

usb2-2:
nvidia,function = “xusb”;
status = “okay”;

The corresponding ports include:

usb2-0:
status = “okay”;
mode = “otg”;

usb2-1:
status = “okay”;
mode = “host”;

usb2-2:
status = “okay”;
mode = “host”;

USB3 lanes/ports are also enabled for usb3-0, usb3-1 and usb3-2.

The USB device controller is enabled:

usb@3550000 {
compatible = “nvidia,tegra234-xudc”;
status = “okay”;
phy-names = “usb2-0”;
}

The XUSB host controller is also enabled:

usb@3610000 {
compatible = “nvidia,tegra234-xusb”;
status = “okay”;
phy-names = “usb2-1\0usb2-2\0usb3-0\0usb3-1\0usb3-2”;
}

Therefore, XUSB/XUDC are at least marked as enabled in the Stereolabs DTB being used.

We are NOT claiming that XUSB initializes successfully on the hardware; only that the DTB configuration itself does not simply have the controller disabled.

MB2 BCT / EEPROM CHECK

We also investigated the MB2 BCT because similar Jetson initrd boot failures can be related to carrier-board EEPROM configuration.

The ZED Box configuration chain is:

p3509-a02-p3767-0000.conf
→
p3768-0000-p3767-0000-a0.conf
→
p3767.conf.common

p3767.conf.common selects:

MB2_BCT=“tegra234-mb2-bct-misc-p3767-0000.dts”;

The corresponding EEPROM configuration contains:

cvm_eeprom_i2c_instance = <0>;
cvm_eeprom_i2c_slave_address = <0xa0>;
cvm_eeprom_read_size = <0x100>;

cvb_eeprom_i2c_instance = <0x0>;
cvb_eeprom_i2c_slave_address = <0xae>;
cvb_eeprom_read_size = <0x0>;

We extracted the same file from:

zedbox_device_trees_392.tar

and compared it with the BSP version.

They are identical.

Therefore, cvb_eeprom_read_size is already disabled (<0x0>) exactly as supplied by Stereolabs.

We did not modify it.

GENERATED INITRD BOOT IMAGE

The flash process successfully generates:

bootloader/boot0.img

Size:

approximately 77 MB

file identifies it as:

Android bootimg

with kernel/ramdisk and command line including:

root=/dev/initrd
rw
rootwait
mminit_loglevel=4
console=ttyTCU0,115200
firmware_class.path=/etc/firmware

Therefore, the initrd boot image is being generated before the RCM transfer.

INITRD SCRIPT / ttyTCU0 CHECK

We inspected:

tools/kernel_flash/initrd_flash/init

The script defines:

TTY_CONSOLE=“ttyTCU0”

The generated boot0.img command line contains:

console=ttyTCU0,115200

We also inspected the initrd logic.

There is a helper function that can reboot if ttyTCU0 is missing, but we verified that this helper function is only defined in the inspected script and no call to it was found there.

The explicit early reboot paths we found in the init script are failures to mount:

/proc
/dev
/sys
debugfs

We currently have no evidence that any particular one of these conditions is occurring, because the target never becomes reachable after RCM boot.

SERIAL / USB CONSOLE OBSERVATION

When the ZED Box was booting its existing Linux installation normally, the same USB connection could enumerate as:

0955:7020 NVIDIA Corp. L4T (Linux for Tegra) running on Tegra

and the host obtained:

/dev/ttyACM0

We were able to open:

sudo screen /dev/ttyACM0 115200

and log into the running ZED Box.

We observed:

Ubuntu 22.04.5 LTS
GNU/Linux 5.15.148-tegra aarch64

The USB gadget interfaces were also created on the host, including RNDIS/NCM, and the standard 192.168.55.x USB network was functional.

For example, the host had:

192.168.55.100/24

and:

ping 192.168.55.1

worked.

This is useful because it demonstrates that the ZED Box has previously been able to expose its Linux USB gadget interface successfully when booting the installed OS.

However, during the JetPack 7.2 RCM-loaded initrd boot, none of those interfaces appear.

ZED BOX BIOS / UEFI USB OBSERVATION

We also checked the ZED Box UEFI/BIOS during troubleshooting.

USB devices connected to the ZED Box USB ports were not detected/listed there.

We do not know whether this is expected behavior on this carrier board or whether it is relevant to the XUSB/initrd problem.

Because the initrd flashing failure itself reports a possible XUSB issue, we would appreciate confirmation about whether USB devices should normally be visible/functional from the ZED Box UEFI environment.

QUESTIONS

Could you please help us determine where the ZED Box boot chain is failing after “RCM-boot started”?

In particular:

Is zedbox_all_usb_flash_7.2.sh officially supported on this ZED Box Orin NX 16GB hardware/revision (Board ID 3767, version/FAB 303, SKU 0000, revision F.1)?
Is JetPack 7.2 / L4T R39.2 currently expected to flash successfully on this generation of ZED Box Orin NX?
We are using Ubuntu 22.04 Live USB as the flashing host, with the BSP stored on an internal ext4/NVMe filesystem. Is this a supported host configuration for JetPack 7.2?
After “RCM-boot started”, what USB VID:PID and/or network interface should normally appear when the JetPack 7.2 initrd flash kernel has booted successfully?
Does the target returning/remainining as 0955:7323 APX indicate that MB2/UEFI/kernel/initrd is failing and the unit is rebooting back into recovery?
Are there any known JetPack 7.2 issues specific to the ZED Box carrier involving XUSB, XUDC, UPHY, pinmux or MB2 BCT configuration?
Is the p3509-a02-p3767-0000 configuration and the tegra234-p3768-0000+p3767-0000-nv.dtb distributed in the current zedbox_device_trees_392.tar expected to support this exact ZED Box revision?
Is it expected that USB devices connected to the ZED Box are not detected in its UEFI/BIOS, or could this indicate a carrier/XUSB configuration issue?
Is a very short USB cable (for example the ~10 cm cable mentioned in the previous JetPack 6.2 forum topic) required or strongly recommended even when the original cable can reliably transfer the complete RCM blob?
Is a particular ZED Box power mode required during JetPack 7.2 flashing?
What is the recommended way to obtain the early serial boot log requested by l4t_initrd_flash on this ZED Box model?

During normal Linux boot we can access ttyACM0 over the OTG USB port, but ttyACM0 never appears during the failed RCM-loaded JetPack 7.2 initrd boot.

If access to a physical UART/debug connector is required, could you provide the correct connector/pinout and serial settings for this ZED Box revision?

Are there any additional logs or files you would like us to provide to determine whether the failure occurs in MB2, UEFI, kernel startup, XUSB initialization or the initrd?

We can provide:

complete flash log
host dmesg trace during RCM → initrd
lsusb monitoring output
generated DTB/DTS
MB2 BCT configuration
boot0.img information
any other requested diagnostic files

Our main goal is to successfully update this ZED Box Orin NX 16GB from JetPack 6.2 / Ubuntu 22.04 to JetPack 7.2 / Ubuntu 24.04 using the official ZED Box flashing procedure.

Thanks.

ZED Box Orin NX 16GB - JetPack 7.2 flash fails after RCM boot: "Device ping failed after RCM boot"

HARDWARE / CURRENT SYSTEM / OBJECTIVE

FLASHING HOST

PROCEDURE

FORCE RECOVERY MODE WORKS

EXACT POINT OF FAILURE

USB BEHAVIOR DURING RCM → INITRD TRANSITION

USB CABLE / HOST USB PORT TESTS

USB AUTOSUSPEND

NFS / HOST FLASH REQUIREMENTS

BSP / ROOTFS PREPARATION

DEVICE TREE / XUSB CHECK

MB2 BCT / EEPROM CHECK

GENERATED INITRD BOOT IMAGE

INITRD SCRIPT / ttyTCU0 CHECK

SERIAL / USB CONSOLE OBSERVATION

ZED BOX BIOS / UEFI USB OBSERVATION

SIMILAR STEREOLABS FORUM TOPICS REVIEWED

QUESTIONS