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.
SIMILAR STEREOLABS FORUM TOPICS REVIEWED
Before opening this topic we reviewed several related ZED Box threads, including:
- “Cannot update Zedbox to Jetpack 6.2 - Device failed to boot to the initrd flash kernel”
- “Zedbox Orin Flashing Issues”
- “Flashing Zed Box Orin NX 16GB Problem: Directory renamed before its status could be extracted”
- “Unable to boot ZED Box Orin NX after restart”
We have therefore already checked several recommendations that appear repeatedly in these discussions and in the Stereolabs troubleshooting guide:
-
Force Recovery Mode confirmed
-
Correct APX VID:PID confirmed
-
Different USB cable tested
-
Original USB cable tested
-
Different host USB port tested
-
Device power-cycled
-
Recovery mode re-entered multiple times
-
USB autosuspend disabled
-
BSP placed on a disk with sufficient space
-
Rootfs successfully populated
-
NVIDIA binaries applied
-
NFS service running
-
UFW inactive
-
XUSB/XUDC DT configuration inspected
-
Stereolabs device-tree files compared against BSP
-
MB2 BCT/EEPROM configuration checked
-
boot0.img generation verified
-
USB enumeration monitored throughout RCM → initrd
-
A specifically ~10 cm USB cablse
-
A completely different Ubuntu host PC
we haven’t yet tested A forced USB 2.0 connection through a USB 2.0 hub because it is not currently available to us.
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.