ERROR: might be timeout in USB write, can't flash BalenaOS to NVIDIA Jetson AGX Orin

[treygilliland]

We have attempted to flash BalenaOS to an NVIDIA Jetson AGX Orin Dev Kit using 3 different devices running 2 different OSs (Arch and Ubuntu 20.04) and have continuously run into the following issue:

[   0.2737 ] Sending bct_br
[   0.4198 ] ERROR: might be timeout in USB write.
Error: Return value 3
Command tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
Reading board information failed.

This seems to be a common problem with Orins in general as it happens when using NVIDIA's SDKManager to try and flash NVIDIA Jetpack on the Orin.

We were originally able to successfully flash this Orin fresh out of the box using the laptop running Arch but now are unable to reflash this device either to a different copy of the BalenaOS (w/ development mode enabled) or the Jetpack OS provided by NVIDIA.

Here are some similar threads:

• https://forums.developer.nvidia.com/t/flashing-jetson-agx-orin-devkit-after-breaking-system/239058
• https://forums.developer.nvidia.com/t/unable-to-clone-jetson-orin-with-jetpack-5-0-2-using-flash-sh-error-might-be-timeout-in-usb-write/230088
• https://forums.developer.nvidia.com/t/usb-timeout-when-flashing-agx-orin/235600

Some suggestions from various threads that we haven't been able to try include:

• Changing Linux kernel to version 5.15
• Downgrading from Ubuntu 20.04 to Ubuntu 18
• Using a different machine as the Dell XPS laptop running Ubuntu may have issues with the USB-C ports

Any help/advice would be appreciated!

[acostach]

Hi @treygilliland, I think you can give the Dockerfile method a try, as you can switch between base images in it if needed. I've encountered the issue that surfaces those logs many times on my AGX Orin Devkit 32GB & Dell laptop, especially after breaking the QSPI flash. On my side it's been the rcm boot that appears to work differently and it turned out that the most reliable way of putting the device in recovery was keeping the middle Force recovery button pressed while plugging in the USB-C power cord, then pressing the power button, then releasing it and finally releasing the force recovery one. I'm using kernel 5.19.

[acostach]

Closing due to inactivity, feel free to re-open if needed.