Jetson TX2 - Failed to flash device

I’m trying to flash my Jetson tx2 with Jetpack 3.3. Im getting the following error when attempting to flash the device:

Error: probing the target board failed.
Make sure the target board is connected through micro-B USB port and is in recovery mode.

The board is in recovery mode, and connected to the host via the micro usb cable provided in the dev kit.

The lsusb command on the host shows the Nvidia device.

I then attempted to flash the device with the command line but get the following error:

Error: Return value 8
Reading board information failed.

Thanks

If there is a VM for the host, then the failure is expected. If there is no VM, and if this command shows a recovery mode TX2, then it should flash ok:

lsusb -d 0955:7c18

Some flash instructions may change with different releases, but this is for command line flash:
https://devtalk.nvidia.com/default/topic/982779/jetson-tk1/how-to-perform-a-correct-fresh-ubuntu-install-on-jetson-tk1/post/5040584/#5040584

Note that you’ll probably have to adjust for the most recent R28.2.1 release if you are on a TX2…package names will differ from that older thread. This is a more recent thread and might even be a better place to start, but is R28.2 so you’d adjust to be the R28.2.1 release:
https://devtalk.nvidia.com/default/topic/1031769/jetson-tx2/unable-install-any-jetpacks-jetson-tx2/post/5249710/#5249710

Thanks for your reply.

lsusb -d 0955:7c18 produces no output.

the output of lsus -d 0955: is :
Bus 001 Device 010: ID 0955:7020 NVidia Corp.

Host is not a VM, running ubuntu 16.04

I’m not familiar with the 0x7020 idProduct. It isn’t a TX2, but I haven’t seen either the TX2i or the new 4GB version of TX2…I am only guessing, but is this a TX2i?

I don’t know the designation used for flashing a TX2i…the “jetson-tx2” would expect idProduct “0x7c18”, and I am guessing (lots of guessing) that maybe it is something like “jetson-tx2i”.

Can someone comment on which product the 0955:7020 is, and what the correct flash.sh command line designation is?

It is the tx2, not tx2i (unless they shipped the wrong board). It should be the 8gb model as well.

In this case there is something quite odd going on…7140 is a TK1, 7721 is a TX1, 7c18 is a TX2, and 7019 is an Xavier. Unless something changed which I’ve never heard of, 7020 for an ordinary 8GB TX2 implies a product mix-up.

Can someone from NVIDIA suggest what USB 0955:7020 really is? Can you post a picture of the module and/or carrier? FYI, if you hover your mouse over the “pencil” icon in the upper right of an existing post it’ll allow you to edit…but instead of clicking the pencil, notice that a paper clip icon also becomes visible. The paper clip is how you’d attach a file to that post.

Heres a photo of the board and the box.


It certainly looks like any other TX2 dev board. I am wondering if the module itself isn’t really an “ordinary” TX2. Unfortunately, I don’t know enough about it to look at markings to find out if it is really a TX2i or 4GB TX2 (neither should arrive on a dev carrier board though).

Many people are out for the holiday though, but hopefully someone will see this and be able to comment.

Seems to me it doesn’t look like a TX2i, but a 4GB TX2 may explain the 7020 id.
Someone from NVIDIA may tell more abouth this code.

Sorry for late reply. Is this one really a out of box TX2?
You should not get any T186 devices which are not TX2 or TX2i at this moment.

Could you share the full flash log with us?

Yes, it is an out of box TX2.

The following is from the flash_os_tx2.log

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

L4T BSP Information:

R28 (release), REVISION: 2.1, GCID: 11272647, BOARD: t186ref, EABI: aarch64,

DATE: Thu May 17 07:29:06 UTC 2018

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

Thanks for your reply!

14ctc2,

The flash log is different with the previous one… do you put device into recovery mode…?

I think I a log from a previous attempt… This is the consule output I get when I run flash.sh, with the device in recovery mode.

sudo ./flash.sh -S 29318MiB jetson-tx2 mmcblk0pl
[sudo] password for cooper:
./tegraflash.py --chip 0x18 --applet “/home/cooper/jetson/Linux_for_Tegra/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.0019 ] Generating RCM messages
[ 0.0033 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /home/cooper/jetson/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin 0 0
[ 0.0043 ] RCM 0 is saved as rcm_0.rcm
[ 0.0052 ] RCM 1 is saved as rcm_1.rcm
[ 0.0053 ] List of rcm files are saved in rcm_list.xml
[ 0.0053 ]
[ 0.0053 ] Signing RCM messages
[ 0.0070 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0082 ] Assuming zero filled SBK key
[ 0.0123 ]
[ 0.0123 ] Copying signature to RCM mesages
[ 0.0133 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[ 0.0150 ]
[ 0.0150 ] Boot Rom communication
[ 0.0160 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
[ 0.0174 ]
Error: Return value 8
Command tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
Reading board information failed.

I suspect this is just a typographic error, and not what you really used, but need to verify something. Did you actually use “mmcblk0pl”, and not “mmcblk0p1”? The last digit should be number “one”, not lower case “L”. If you did use “L”, then this would cause a failure. On the other hand, I doubt it would have got as far as it did if it were not a “one”.

I accidently put “L”. After running it again, i got the same error however.

sudo ./flash.sh -S 29318MiB jetson-tx2 mmcblk0p1
./tegraflash.py --chip 0x18 --applet “/home/cooper/jetson/Linux_for_Tegra/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.0015 ] Generating RCM messages
[ 0.0028 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /home/cooper/jetson/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin 0 0
[ 0.0038 ] RCM 0 is saved as rcm_0.rcm
[ 0.0043 ] RCM 1 is saved as rcm_1.rcm
[ 0.0043 ] List of rcm files are saved in rcm_list.xml
[ 0.0043 ]
[ 0.0043 ] Signing RCM messages
[ 0.0053 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0062 ] Assuming zero filled SBK key
[ 0.0095 ]
[ 0.0095 ] Copying signature to RCM mesages
[ 0.0104 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[ 0.0116 ]
[ 0.0116 ] Boot Rom communication
[ 0.0126 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
[ 0.0141 ]
Error: Return value 8
Command tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
Reading board information failed.

14ctc2,

Could you see “cvm.bin” under your “bootloader” folder? If so, could you try to use binary chkbdinfo to dump the info of eeprom on this board?

I don’t see a “cvm.bin” under my bootloader folder on the host PC.

Please try this command under Jetpack folder → Linud_for_Tegra/bootloader/.

sudo ./tegraflash.py --chip 0x18 --applet "mb1_recovery_prod.bin" --cmd "dump eeprom boardinfo cvm.bin"

After that command, cvm.bin should be generated.

I figured out what was going wrong. I had not properly put the device into recovery mode.

Is this issue resolved now?