Hi all,
So, I’m also having trouble flashing my new TX2 board. I’ve read a most of the other posts about this problem. None of those ideas have helped me. I’m using VMware, the free version player. I tried Ubuntu 14.04.05, and 16.04.2. I deleted the VM and created another 14.04 version. I’ve check the board is in Recovery mode, lsusb, and is USB-2, lsusb -t. The Nividia name is there, and the id looks correct, 0955:7721 NVidia Corp. I tried to flash from the command line using “sudo ./flash.sh …” that failed, also. The failure is always in the same place. Here is part of the flash_os_tx2.log:
0.0096 ]
[ 0.0096 ] Signing RCM messages
[ 0.0125 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.ke
y
[ 0.0136 ] Assuming zero filled SBK key
[ 0.0294 ]
[ 0.0294 ] Copying signature to RCM mesages
[ 0.0317 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[ 0.0463 ]
[ 0.0464 ] Boot Rom communication
[ 0.0483 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
[ 0.0503 ] RCM version 0X8
[ 0.0566 ] Boot Rom communication failed
[ 0.0703 ]
Error: Return value 3
Command tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
Reading board information failed.
So, my question is does anyone know what Return value 3 means? I did notice that my RCM version is different from another person who was having the same problem. His RCM version was 0x180001. His version failed a couple of steps later, with “can’t open USB.” I’ve been working this for a 3 days now. I have no more ideas of where to look.
I did try to create an bootable SD card according to another user. I can’t read or format the card now.
It is fairly common for a VM to have USB communications failure. Make sure the port is set to USB2 mode (if USB3 in theory it would fall back to USB2, but this seems to be unreliable on a VM). There may be other VM settings to increase buffer size for the USB port which might help (I am unaware of how to set this, it’s just what some have reported as working).
Note that you can do command line flash on any x86_64 Linux PC, so if you are using a VM for JetPack, but have a real Linux install, you might try command line instead of JetPack.
Hey, thanks for your quick response.
I did check to be sure that it was USB2. I think you or someone else suggested lsusb -t. lsusb shows the bus and device, with ID 0955:7721 Nvidia and lsusb -t show that device is 480M, not 12M or 5000M, so USB2. I was unable to find any information about changing the USB buffer size as was suggested in another answer. I did try the command line flash, the failure is exactly the same. I don’t have any real Linux machines. I’m hoping to avoid that.
Under “lsusb -t” you’d want to be sure that the “Class=root_hub” is 480M. If the port is USB3 you’ll see the root_hub as 5000M, but the Jetson as 480M…this would mean it has throttled back from USB3 to USB2 speed. Is the root_hub USB2? If so, then I’d investigate how the VM might have a larger buffer size for the USB port. The fact that it sees the Jetson, yet fails under command line strongly suggests a USB issue…one which happens just like this quite often with a VM.
There is a chart of error codes for the TK1, I have not seen error codes for flash of a TX2. It would be good if NVIDIA could post the error codes for the TX2 flash…I’m going to guess that error 3 means “packet was NAKed” (not acknowledged).
So, “lsusb -t” show the root hub as USB2. The TX2 is bus 1, dev 4:
Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
I will try to find the error code chart for the TK1, maybe they are the same. Is there one for the TX1? Those would be the same. I will try again for the larger buffer.
I am also seeing the same problem flashing Nvidia Jetson TX@ with Jetpack 3.1. Any suggestions will be helpful. I am using a Dell XPS 13 Ubuntu laptop as a host.
./tegraflash.py --chip 0x18 --applet “/home/rnekkanti/JetPack/64_TX2/Linux_for_Tegra_tx2/bootloader/mb1_recovery_prod.bin” --cmd “dump eeprom boardinfo cvm.bin” --skipuid
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.0012 ] Generating RCM messages
[ 0.0020 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /home/rnekkanti/JetPack/64_TX2/Linux_for_Tegra_tx2/bootloader/mb1_recovery_prod.bin 0 0
[ 0.0026 ] RCM 0 is saved as rcm_0.rcm
[ 0.0030 ] RCM 1 is saved as rcm_1.rcm
[ 0.0030 ] List of rcm files are saved in rcm_list.xml
[ 0.0030 ]
[ 0.0030 ] Signing RCM messages
[ 0.0038 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0049 ] Assuming zero filled SBK key
[ 0.0091 ]
[ 0.0091 ] Copying signature to RCM mesages
[ 0.0099 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[ 0.0108 ]
[ 0.0109 ] Boot Rom communication
[ 0.0125 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
[ 0.0145 ] Boot Rom communication failed
[ 3.0131 ]
Error: Return value 3
Command tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
Reading board information failed.
I suppose that could be USB error, but usually this is only on a VM (or with the wrong cable). If a TX2 is recovery mode, then “lsusb -d 0955:7c18” should have some output. If this shows up, then basic USB is functioning.
I would suggest removing your JetPack install directory, downloading JetPack again, trying once more…it is possible it isn’t the Jetson itself being the issue. If a new JetPack fails, then more debugging could continue.
I’m having a similar issue. I’m using a laptop with Ubuntu 16.04 as a host to flash TX2.
While lsusb gives the following output.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0b05:1837 ASUSTek Computer, Inc.
Bus 001 Device 005: ID 0955:7c18 NVidia Corp.
Bus 001 Device 002: ID 0bda:57f6 Realtek Semiconductor Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Im getting the following error.
./tegraflash.py --chip 0x18 --applet "/media/mano/DATA/inst_lin/jetpack/64_TX2/Linux_for_Tegra_tx2/bootloader/mb1_recovery_prod.bin" --cmd "dump eeprom boardinfo cvm.bin" --skipuid
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.0140 ] Generating RCM messages
[ 0.0158 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /media/mano/DATA/inst_lin/jetpack/64_TX2/Linux_for_Tegra_tx2/bootloader/mb1_recovery_prod.bin 0 0
[ 0.0174 ] RCM 0 is saved as rcm_0.rcm
[ 0.0191 ] RCM 1 is saved as rcm_1.rcm
[ 0.0207 ] List of rcm files are saved in rcm_list.xml
[ 0.0216 ]
[ 0.0217 ] Signing RCM messages
[ 0.0237 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0254 ] Assuming zero filled SBK key
[ 0.0390 ]
[ 0.0390 ] Copying signature to RCM mesages
[ 0.0412 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[ 0.0458 ]
[ 0.0459 ] Boot Rom communication
[ 0.0479 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
[ 0.0495 ] Boot Rom communication failed
[ 3.0477 ]
Error: Return value 3
Command tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
Reading board information failed.
I have tried installing using both jetpack 3.0 and 3.1 multiple times, the same error pops up.
Because lsusb shows the Jetson, we know it is correctly connected. Is there any intervening HUB, if so, can you try without the HUB?
One minor possibility is that each time you do anything with the flash program the Jetson must be put back in recovery mode, and lacking a fresh recovery mode things will fail. So for example, if you tried to flash and it failed, or if you cloned, then you would have to manually restart recovery mode each time. Is recovery mode being started fresh at each attempt to flash?
Im not using any hub.
I’m using a router. Jetson is hooked to the router via an ethernet cable. and I have tried connecting my laptop to the router with both ethernet and wifi, just as shown in the video below. https://youtu.be/D7lkth34rgM
And yes every time when I flash, I try to shutdown the jetson board and then start the recovery mode.
Router is unrelated, all flash goes through the micro-B USB connector. Ethernet takes place after flash completes and the system reboots…this is when JetPack manages packages.
I’m having the same following error shown in the original post.
Error: Return value 3
Command tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
Reading board information failed.
I tried using both 16.04 LTS and 14.04 LTS (both not VM), but ended up with no success.
PS: I am working with a Jetson TX2 with orbitty carrier. Only the version latter than Jetpack 3.1 brings the above error. I could flash Jetpack 3.0 using Ubuntu 16.04 LTS.