Jetson Orin AGX flash failed

I got this error when I’m try to flash with self-compiled kernel, the host is a x86 ubuntu 22.04 PC, not using VM or any other tricky thing:

###############################################################################

L4T BSP Information:

R36 , REVISION: 4.4

User release: 0.0

###############################################################################
ECID is
Error: probing the target board failed.
Make sure the target board is connected through
USB port and is in recovery mode.

I can see the device by lsusb, the device show immediately after pressing the recovery button, I know it doesn’t mean it is 100% in recovery mode, but I can saw the device in NVIDIA SDK and which indicate it is a Jetson Orin AGX 64 GB module.

Here is the weird thing that my usb device info seems incorrect.

Bus 002 Device 012: ID 0955:7020 NVIDIA Corp. L4T (Linux for Tegra) running on Tegra

I saw other has ID 0955:7023 and said 7020 is jetson nano, would that be the reason for flash failed.

Looking forward any advice, thank you.

P.S. I had succeed flashing this kernel image once, but I tried plug and unplug many time and get this error many time, I’m not sure why I can succeed only once. I can succeed flashing with normal image and sdk, so i think it is not about the usb line and port.

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, it appears that you are trying to flash a self-compiled kernel onto a Jetson AGX Orin 64GB module using a host PC running Ubuntu 22.04. You are encountering an error during the flashing process, and you suspect that the issue might be related to the USB device information.

Firstly, let’s address the USB device information. The lsusb command output shows the device ID as 0955:7023, which corresponds to the Jetson AGX Orin module. However, you mentioned that others have reported a different ID, which might be related to the Jetson Nano module. This discrepancy could be due to the fact that the Jetson AGX Orin and Jetson Nano modules share the same device ID, but with different product IDs.

To confirm whether the device is indeed in recovery mode, you can try running the lsusb command with the -v option to get more detailed information about the device. This should help you verify whether the device is in recovery mode.

Regarding the flashing error, it’s possible that the issue is related to the USB connection or the flashing process itself. Since you’ve mentioned that you’ve successfully flashed the kernel image once before, it’s likely that the issue is intermittent.

Here are a few suggestions to help you troubleshoot the issue:

  1. Verify the USB connection: Ensure that the USB connection between the host PC and the Jetson module is stable and secure. Try using a different USB port or cable to rule out any issues with the current connection.
  2. Check the device mode: Verify that the Jetson module is indeed in recovery mode by running the lsusb command with the -v option. If the device is not in recovery mode, try pressing the recovery button again and check the output.
  3. Use the correct flashing script: Make sure you’re using the correct flashing script for your Jetson module. The l4t_initrd_flash.sh script is used for flashing the Jetson AGX Orin module, while the flash.sh script is used for flashing other Jetson modules.
  4. Check the kernel image: Verify that the kernel image you’re trying to flash is compatible with your Jetson module. Ensure that the kernel image is built for the correct architecture (aarch64) and that it’s not corrupted.
  5. Try flashing with a different tool: If you’re using the NVIDIA SDK to flash the kernel image, try using a different tool, such as the nvautoflash.sh script, to see if the issue persists.

By following these steps, you should be able to troubleshoot the issue and successfully flash the kernel image onto your Jetson AGX Orin module.

Here’s a comparative analysis of the flashing scripts mentioned in the context:

  • l4t_initrd_flash.sh: This script is used for flashing the Jetson AGX Orin module. It uses the recovery initial ramdisk to flash the device.
  • flash.sh: This script is used for flashing other Jetson modules. It uses the Bootloader to flash the device.
  • nvautoflash.sh: This script is a wrapper script for flash.sh that can be called without specifying a device name.

In your case, since you’re using the Jetson AGX Orin module, you should use the l4t_initrd_flash.sh script to flash the kernel image.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

Hi @peichun.huang,

I hope you are doing well.

Have you tried rebooting your host PC?

I would also suggest to use a different USB port and/or cable.

Best regards,
Nico
Embedded Software Engineer at ProventusNova

I tried several things in this hour:

  1. reboot my host
  2. try l4t_initrd_flash.sh (though i think it is just another method to flash, not specific for agx orin?)
  3. lsusb -v (but i did not see any useful information)
  4. refresh the system by sdk to default, and reboot with force recovery mode.

seems 1. 2. and 4. work. not sure which one helps.

my final flash command is:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c ./tools/kernel_flash/flash_l4t_external.xml --showlogs --network usb0 jetson-agx-orin-devkit internal

seems succeed, but small weird thing is that I saw it flash to emmc, i will figure it out and maybe I would post another issue if it did flashed to emmc instead of nvme.

Anyway, thanks a lot for helping and quick response!!

00:01:59.446 - Info: Successfully flashed the external device.
00:02:30.564 - Debug: writing item=78, 1:3:secondary_gpt, 61203267072, 16896, gpt_secondary_1_3.bin, 16896, fixed--0, 0bcd542899353e0f5a9d613de95f0bcd8889f81b

00:02:30.567 - Info: Successfully flashed the eMMC.
Erased 67108864 bytes from address 0x00000000 in flash
00:04:36.183 - Debug: Flash index file is /mnt/internal/flash.idx
00:04:36.189 - Debug: Number of lines is 79

Update: I tried several times and confirm that the ID should be 0955:7023 instead of 0955:7020, or it is not really in recovery mode, hope it may help someone debug.