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.
Finally ran sudo ./flash.sh 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:
KeyboardInterrupt
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 “apply_binaries.sh” again, but if you flash yet again, does it end the same way?
After commenting out eeprom flags from the below files,
bootloader/tegra194-mb1-bct-misc-flash.cfg
bootloader/tegra194-mb1-bct-misc-l4t.cfg
bootloader/t186ref/BCT/tegra194-mb1-bct-misc-flash.cfg
bootloader/t186ref/BCT/tegra194-mb1-bct-misc-l4t.cfg
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.
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.
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 ./flash.sh -k kernel-dtb jetson-xavier-nx-devkit mmcblk0p1.