Jetpack 34.1 Kernel 5.10 Flashing hangs

I am trying to flash Jetson xavier NX board, but the process hangs at
[ 8.4914 ] Sending bootloader and pre-requisite binaries
[ 8.4943 ] tegrarcm_v2 --download blob blob.bin
[ 8.4953 ] Applet version 01.00.0000
[ 8.5705 ] Sending blob
[ 8.5706 ] […] 100%
[ 9.4642 ]
[ 9.4687 ] tegrarcm_v2 --boot recovery
[ 9.4712 ] Applet version 01.00.0000
[ 9.5063 ]
[ 10.5131 ] tegrarcm_v2 --isapplet
It does not respond even after waiting for 30 minutes.

The steps I followed,

  1. Downloaded the BSP sources from
  2. Extracted the BSP sources.
  3. cd Linux_for_Tegra
  4. Downloaded sample root filesystem from and extracted it inside Linux_for_Tegra/rootfs
  5. Ran sudo ./
  6. Finally ran sudo ./ jetson-xavier-nx-devkit-emmc mmcblk0p1

Is there anything I am missing out? I have not done any changes to source and I am using default L4T.
Also attached complete flash log.
flash_fail.txt (50.2 KB)

Most of flash succeeds and runs normally until the very end:

Failed flashing t186ref.

Is there a keyboard which might have had a key accidentally pressed? Did you try to flash again? You wouldn’t need to “” again, but if you flash yet again, does it end the same way?

1 Like

Is this a NX custom board or devkit?

1 Like

Yes I am using a custom carrier board and Xavier NX SOM which is in stock condition. I am using jetpack 34.1 without any modifications.
Also, I went through Xavier flashing hangs at tegrarcm_v2 –isapplet with JetPack_5.0_DP - #33 by user100090.

After commenting out eeprom flags from the below files,

I was able to flash the board successfully. I think it is a temporary solution and waiting for NVIDIA to look into it and fix it.

I don’t know how much this would change flash, but the custom carrier board implies the device tree is likely at least partially wrong when using the one for the dev kit. Each carrier board will have a published flash software which differs from the NVIDIA dev kit flash software such that many parts are duplicated, but device tree itself will seldom be an exact duplicate.

Device trees would affect boot and runtime success, though it is unlikely to change flash itself. In most cases flash of a particular device tree for a given carrier board can be performed via a different carrier board, e.g., if the target board does not have the correct USB for flash; thus, one might flash to a different carrier, but the device tree would have to be for the unit the module will actually boot from (the module would be removed from the flash carrier and installed to the actual boot target carrier board).

Each custom carrier board manufacturer must provide this modification. It isn’t possible for NVIDIA to know the trace layout of a custom carrier, and the default flash software is not intended for that purpose (though dev kit flash software can easily be modified for this if one knows how the device tree differs).

I had this problem before for flashing TX2. I couldn’t figure it out until I reinstall ubuntu on that linux laptop. I suspect is something related to usb device detection or secure boot, because I did something unusual to my linux laptop (don’t remember the detail) before that for another project.

Can you still flash JP4.x?

There is a known issue in JP5.10 which is related to the custom board.

I mean only custom board has chance to hit this issue.

We have a overlay tarball here for this fix.

1 Like

Yes I can flash the older versions without any issues on the custom carrier board(which is almost similar to NVIDIA devkit).
And one more thing, after flashing the board successfully when I restart the board, it does not boot up. While running ‘lsusb’ Nvidia driver does not list up. What could be causing the issue, any input is much appreciated.

Are you talking about the old version or you are talking about the new overlay?

Ok. Ignore my previous comment then.

I’m having exactly same issue here. I found that it only happens if I flash with a modified dtb to start with. So I did the following to make it work:

  • First flash with default dtb without any changes.
  • Then, modify the /boot/extlinux/extlinux.conf by removing the line FDT /boot/dtb/kernel_tegra194-p3668-0001-p3509-0000.dtb. I also create a backup boot options just in case.
  • Then cp "$BUILD_OUT/arch/arm64/boot/dts/nvidia/"*.* "$L4T/kernel/dtb/"
  • Flash the correct customized kernel-dtbsudo ./ -k kernel-dtb jetson-xavier-nx-devkit mmcblk0p1.
  • Then, reboot new dtb will be in effect .

This works every time for me.

1 Like

I have a custom dtb as well.
Thank you so much for the input, I will try this and let you know my observations.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.