Unable flash jetson-tx2 with sdkmanager

When trying to flash a Jetson TX2 from attached to the Nvidia carrier board from an Ubuntu 18.04 host machine it is failing when trying to flash the OS. I am trying to use the SDKManager GUI as I also want to install the additional software packages (cuda, tensorflow, etc). The SDKManager is failing.

I have also tried to manually flash the board via:

sudo ./flash.sh jetson-tx2 mmcblk0p1

but the failure is the same.

Terminal output from manual flash attempt:

###############################################################################
# L4T BSP Information:
# R32 , REVISION: 2.3
###############################################################################
# Target Board Information:
# Name: jetson-tx2, Board Family: t186ref, SoC: Tegra 186, 
# OpMode: production, Boot Authentication: NS, 
###############################################################################
./tegraflash.py --chip 0x18 --applet "/home/graves/nvidia/nvidia_sdk/JetPack_4.2.3_Linux_GA_P3310/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin" --skipuid --cmd "dump eeprom boardinfo cvm.bin" 
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
 
[   0.0055 ] Generating RCM messages
[   0.0087 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 0 --download rcm /home/graves/nvidia/nvidia_sdk/JetPack_4.2.3_Linux_GA_P3310/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin 0 0
[   0.0119 ] RCM 0 is saved as rcm_0.rcm
[   0.0134 ] RCM 1 is saved as rcm_1.rcm
[   0.0134 ] List of rcm files are saved in rcm_list.xml
[   0.0134 ] 
[   0.0134 ] Signing RCM messages
[   0.0164 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[   0.0192 ] Assuming zero filled SBK key
[   0.0307 ] 
[   0.0308 ] Copying signature to RCM mesages
[   0.0342 ] tegrarcm_v2 --chip 0x18 0 --updatesig rcm_list_signed.xml
[   0.0395 ] 
[   0.0396 ] Boot Rom communication
[   0.0426 ] tegrarcm_v2 --chip 0x18 0 --rcm rcm_list_signed.xml --skipuid
[   0.0451 ] RCM version 0X180001
[   0.3502 ] Boot Rom communication completed
[   1.3574 ] 
[   2.3625 ] tegrarcm_v2 --isapplet
[   2.3663 ] Applet version 01.00.0000
[   2.9772 ] 
[   2.9805 ] Retrieving EEPROM data
[   2.9809 ] tegrarcm_v2 --oem platformdetails eeprom cvm /home/graves/nvidia/nvidia_sdk/JetPack_4.2.3_Linux_GA_P3310/Linux_for_Tegra/bootloader/cvm.bin
[   2.9844 ] Applet version 01.00.0000
[   3.5977 ] 00000000000a0111: 
[   3.6172 ] 
[   3.6204 ] tegradevflash_v2 --oem platformdetails eeprom cvm /home/graves/nvidia/nvidia_sdk/JetPack_4.2.3_Linux_GA_P3310/Linux_for_Tegra/bootloader/cvm.bin
[   3.6233 ] CPU Bootloader is not running on device.
[   3.9293 ] 
Error: Return value 4
Command tegradevflash_v2 --oem platformdetails eeprom cvm /home/graves/nvidia/nvidia_sdk/JetPack_4.2.3_Linux_GA_P3310/Linux_for_Tegra/bootloader/cvm.bin
Reading board information failed.

I have spent several hours on the forums without being able to find a working solution. I can confirm my jetson is in recovery mode and that I can connect to it via USB from my host. It is not an issue with the USB cable as I have tried several cables with the same result.

Any help is appreciated.

Is the host a VM? Also, is this the development kit (with that carrier board)? If not a VM, and if this is the dev kit, then you might also test to see if JetPack4.2 does the same thing. The different release versions can be found here (redirect does not work, so go there, log in, and click the link a second time):
https://developer.nvidia.com/embedded/jetpack-archive

Try something between 4.2 and 4.2.2 (you don’t have to stick with that version, but I don’t see 4.2.3 listed yet and I’m wondering if you got something not quite finished).

My Host machine is not a VM. It’s a regular Ubuntu 18.04 full installation. I am not dual booting or running from a container, or anything else out of the ordinary.

I am using the development kit board.

I have tried with using Jetpack 4.2.2 and Jetpack 4.2 with identical results.

In the SDKManager GUI Jetpack 4.2.3 is the default selection and is what I prefer as it comes with TensorFlow and DeepStream SDKs. I can give these up I suppose, but would rather not if I don’t have to.

The most basic failures are accounted for, and I’m not sure what to test next. This could be an actual hardware failure, or perhaps something simple such as deleting the “~/nvidia/” folder and starting over, but I am unable to say without knowing what the “return value 4” indicates. Would someone be able to suggest if return value 4 might be an actual hardware failure?

I did some more testing and have good news and bad news.

It appears that if I first flash the TX2 with Jetpack 3.3 via command line script

sudo ./flash.sh jetson-tx2 mmcblk0p1

THEN reflash it using the SDKManager with Jetpack 4.2 it all seems to work. I have no clue why this works, but have repeated it a few times successfully.

It’s not a perfect solution as Jetpack 4.2 doesn’t include DeepStream or TensorFlow, but it’s good enough for me to consider my problem solved.

Link to a related issue
https://devtalk.nvidia.com/default/topic/1067506/jetson-tx2/usb-port-inactive-after-flashing-jetson-tx2/post/5407666/#5407666
I’ve been encountering that this solution also seems to fix.

I appreciate your help. Re-trying older Jetpack versions was the key point here.

Glad it now works. Adding some content below just to help people understand more about the topic if they read this or are just curious.

For those with an interest in manual versus automatic flash procedures, SDKM is a front end to the flash.sh content (a.k.a., “the driver package”). If you run flash.sh manually, then you need to make sure the sample rootfs (a.k.a., the “sample rootfs”, which is purely Ubuntu) and apply_binaries.sh (which adds NVIDIA drivers on top of the Ubuntu content) steps have been completed. If you use SDKM, then a manifest is used to do the equivalent based on what the manifest deems to be the current versions…SDKM downloads and applies these items automatically. If you ran flash.sh after SDKM has been used, then you are simply doing the same thing SDKM would have done.

Differences may occur if something has been done out of order and some files had incorrect permissions. An example is that although flash.sh execution, sample rootfs download, and apply_binaries.sh require sudo, the driver package itself is unpacked as a regular user…if something was run with sudo when it should not have, then files expecting regular users to access might then be refused unless sudo is used. If things were done out of order, then normally we would say to delete the “Linux_for_Tegra/” content and start again.

Another difference may occur if the manifest file has a new release, whereas running manually will never check for new releases.