flash TX2 OS eorror! Is Board Broken?

sherlock@sherlock-Linux:~/NVIDIA/64_TX2/Linux_for_Tegra_tx2$ sudo ./flash.sh jetson-tx2 mmcblk0p1
./tegraflash.py --chip 0x18 --applet “/home/sherlock/NVIDIA/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.0010 ] Generating RCM messages
[ 0.0017 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /home/sherlock/NVIDIA/64_TX2/Linux_for_Tegra_tx2/bootloader/mb1_recovery_prod.bin 0 0
[ 0.0023 ] RCM 0 is saved as rcm_0.rcm
[ 0.0027 ] RCM 1 is saved as rcm_1.rcm
[ 0.0027 ] List of rcm files are saved in rcm_list.xml
[ 0.0027 ]
[ 0.0027 ] Signing RCM messages
[ 0.0032 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0038 ] Assuming zero filled SBK key
[ 0.0067 ]
[ 0.0067 ] Copying signature to RCM mesages
[ 0.0073 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[ 0.0080 ]
[ 0.0080 ] Boot Rom communication
[ 0.0085 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
[ 0.0090 ] Boot Rom communication failed
[ 3.0060 ]
Error: Return value 3
Command tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
Reading board information failed.

Hi SherlockThang,

How about flash with JetPack 3.1 and 3.0? Both have the same issue?

JetPack 3.1

i use JetPack 3.1

Do you use VM? Does host detect the usb?

it’s not VM, but PC OS at disk!

Bus 002 Device 002: ID 8087:8001 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8009 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 018: ID 0ac8:3610 Z-Star Microelectronics Corp.
Bus 003 Device 043: ID 0955:7c18 NVidia Corp.
Bus 003 Device 002: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

when I use Jetpack 3.0, fllowing show:

sherlock@sherlock-Linux:~/NVIDIA/64_TX2/Linux_for_Tegra_tx2$ sudo ./flash.sh jetson-tx2 mmcblk0p1
./tegraflash.py --chip 0x18 --applet “/home/sherlock/NVIDIA/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.0010 ] Generating RCM messages
[ 0.0017 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /home/sherlock/NVIDIA/64_TX2/Linux_for_Tegra_tx2/bootloader/mb1_recovery_prod.bin 0 0
[ 0.0023 ] RCM 0 is saved as rcm_0.rcm
[ 0.0027 ] RCM 1 is saved as rcm_1.rcm
[ 0.0027 ] List of rcm files are saved in rcm_list.xml
[ 0.0027 ]
[ 0.0027 ] Signing RCM messages
[ 0.0033 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0038 ] Assuming zero filled SBK key
[ 0.0066 ]
[ 0.0067 ] Copying signature to RCM mesages
[ 0.0072 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[ 0.0080 ]
[ 0.0080 ] Boot Rom communication
[ 0.0086 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid

when i use JetPack 3.0. error occur ,the same as https://devtalk.nvidia.com/default/topic/1001082/jetson-tx2/jetpack-3-0-freezes-during-flash

If there is an issue with loopback (flash.sh loopback handling is incorrect), then you may have issues. If you do a fresh reboot of the host PC before flashing, what is the output of:

ls /dev/loop*

Then run this:

sudo losetup -f

…now what is the output of “ls /dev/loop*”? Does it add a new loop device?

If “/dev/loop0” shows up as the highest numbered loop device, try flashing. If loop1 or higher shows up, then you will need to edit flash.sh to use this loop device.

Keep in mind that loop device failure is unlikely to cause a boot rom communications error message. Loopback would be an issue when generating the system image, and could possibly cause an undefined behavior during a flash.

Hi linuxdev,
I continue to have this issue trying to flash my TX2.

this is the list of my loop devices:

myzhar@myzharbot-control ~ $ ls /dev/loop*
/dev/loop0  /dev/loop2  /dev/loop4  /dev/loop6  /dev/loop-control
/dev/loop1  /dev/loop3  /dev/loop5  /dev/loop7

I tried modifying “flash.sh” at line 466:

local loop_dev="${LOOPDEV:-/dev/loop1}";

I tried loop1 to loop7, but nothing to do…

Any ideas?

Thank you
Walter

Keep in mind in the following that I am assuming your are logged in as root or using sudo…“losetup --find” behaves differently since only root can create a loopback device…the “–find” means losetup reports the first unused loop device, and if you are root, then the device is also created…if not root, then the device is not created.

All losetup in flash.sh should use “losetup --find” right from the start…it should never ever be assumed loop0 can be used if it is there…simply put, something else might be using loop0.

Here is an existing excerpt of R28.1 flash.sh with line numbers:

...
 463 build_fsimg ()
 464 {
 465         echo "Making $1... ";
 466         local loop_dev="${LOOPDEV:-/dev/loop0}";
 467         if [ ! -b "${loop_dev}" ]; then
 468                 echo "${loop_dev} is not block device. Terminating..";
 469                 exit 1;
 470         fi;
 471         loop_dev=`losetup --find`;
 472         if [ $? -ne 0 ]; then
 473                 echo "Cannot find loop device. Terminating..";
 474                 exit 1;
 475         fi;
 476         umount "${loop_dev}" > /dev/null 2>&1;
 477         losetup -d "${loop_dev}" > /dev/null 2>&1;

Here is a candidate for how it should appear (I haven’t tried flashing in different circumstances as a test, YMMV):

...
 463 build_fsimg ()
 464 {
 465         echo "Making $1... ";
 466 #       local loop_dev="${LOOPDEV:-/dev/loop0}";
 467         loop_dev=`losetup --find`;
 468         if [ ! -b "${loop_dev}" ]; then
 469                 echo "${loop_dev} is not block device. Terminating..";
 470                 exit 1;
 471         fi;
 472 #       loop_dev=`losetup --find`;
 473         if [ $? -ne 0 ]; then
 474                 echo "Cannot find loop device. Terminating..";
 475                 exit 1;
 476         fi;
 <i>477         echo "Using loop device ${loop_dev}.";</i>
 478         umount "${loop_dev}" > /dev/null 2>&1;
 479         losetup -d "${loop_dev}" > /dev/null 2>&1;

If you run “losetup --find” as root prior to flash you will see the named loop device exists, and it will be unused. If something uses that loop device, then the next “losetup --find” will increment to the next device. Also, some kernels are not built with loopback support, e.g., some of the compact live CD type distributions may not enable loopback by default. See if the above edits work for you.

Thank you for the fast reply. I tried

sudo losetup --find

and the first free loop device is the loop0:

myzhar@myzharbot-control ~ $ sudo losetup --find
/dev/loop0

So there is no issue with it.

I tried changing the port, the cable, but always the same log error:

./tegraflash.py --chip 0x18 --applet "/home/myzhar/Nvidia/JetPack-3.1/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.0017 ] Generating RCM messages
[   0.0026 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /home/myzhar/Nvidia/JetPack-3.1/64_TX2/Linux_for_Tegra_tx2/bootloader/mb1_recovery_prod.bin 0 0
[   0.0033 ] RCM 0 is saved as rcm_0.rcm
[   0.0038 ] RCM 1 is saved as rcm_1.rcm
[   0.0038 ] List of rcm files are saved in rcm_list.xml
[   0.0038 ] 
[   0.0038 ] Signing RCM messages
[   0.0049 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[   0.0059 ] Assuming zero filled SBK key
[   0.0103 ] 
[   0.0103 ] Copying signature to RCM mesages
[   0.0112 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[   0.0123 ] 
[   0.0123 ] Boot Rom communication
[   0.0133 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid
[   0.0141 ] 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 do not know where to go to bump my head again. At this point I’m pretty sure that it’s an hardware issue.

PS I have no issue flashing the Jetson TX1

Loopback issues will never interfere with actual flash…this only interferes with having valid content on the image to be flashed, so I wouldn’t expect it to have anything to do with a communications error.

By far the biggest problem with such an error is when using a VM. There seems to be extra steps to making sure the VM gets and holds on to the recovery mode Jetson, and then sometimes changes need to be added just to make such communications reliable. Is this a VM? If so, this may help:
https://devtalk.nvidia.com/default/topic/1002081/jetson-tx2/jetpack-3-0-install-with-a-vm/

If not a VM, is there a HUB involved? Is the USB cable the original?

No VM, no USB hub, I tried three different original Nvidia USB cables with three different USB ports.
Always the same error

There may be an actual hardware failure, but one subtle issue is that after any operation on the recovery mode Jetson it must be put back into recovery mode before the next operation, e.g., you can’t clone twice in a row, you can’t flash twice in a row, so on…and a failed flash or a failed clone counts as an operation (lsusb does not count as an operation…it’s a question of whether the driver package ran). For each attempt did you do a fresh restart of the Jetson into recovery mode?

Yes, I reboot it before each try…

I just received an email by Dustin from Nvidia, he confirmed that it can be an hardware problem. My TX2 is a pre-launch board and he said that there were a bit of them with flash problems.

Hi Myzhar,

Please follow the RMA steps for returning your TX2.

1. Go to http://www.nvidia.com/nvcc
 2. Select “Live Chat” from the options near the top of the page.
 3. Enter your personal information.
 4. Select the appropriate product from the drop-down list (“Tegra” in this case).
 5. Submit the request.

How can I know if my board has a hardware problem too? And if there are flash problems, is it possible to flash from SD card instead of eMMC?

I’m having similar problems. I’m trying to flash to eMMC in recovery mode:

$ sudo ./flash.sh jetson-tx2 mmcblk0p1

And it’s just stuck there forever after showing the following:

./tegraflash.py --chip 0x18 --applet “/home/bochengyu/Linux_for_Tegra/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.0045 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /home/bochengyu/Linux_for_Tegra/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin 0 0
[ 0.0063 ] RCM 0 is saved as rcm_0.rcm
[ 0.0069 ] RCM 1 is saved as rcm_1.rcm
[ 0.0069 ] List of rcm files are saved in rcm_list.xml
[ 0.0069 ]
[ 0.0069 ] Signing RCM messages
[ 0.0079 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0087 ] Assuming zero filled SBK key
[ 0.0122 ]
[ 0.0122 ] Copying signature to RCM mesages
[ 0.0131 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml
[ 0.0142 ]
[ 0.0142 ] Boot Rom communication
[ 0.0150 ] tegrarcm_v2 --chip 0x18 --rcm rcm_list_signed.xml --skipuid

And if I interrupt the process by Ctrl+C, it shows:

^CTraceback (most recent call last):
File “./tegraflash.py”, line 1022, in
tegraflash_run_commands()
File “./tegraflash.py”, line 929, in tegraflash_run_commands
interpreter.onecmd(command)
File “/usr/lib/python2.7/cmd.py”, line 221, in onecmd
return func(arg)
File “./tegraflash.py”, line 614, in do_dump
tegraflash_dump(exports, args)
File “/home/bochengyu/Linux_for_Tegra/Linux_for_Tegra/bootloader/tegraflash_internal.py”, line 709, in tegraflash_dump
tegraflash_send_tboot(tegrarcm_values[’–signed_list’])
File “/home/bochengyu/Linux_for_Tegra/Linux_for_Tegra/bootloader/tegraflash_internal.py”, line 1242, in tegraflash_send_tboot
run_command(command)
File “/home/bochengyu/Linux_for_Tegra/Linux_for_Tegra/bootloader/tegraflash_internal.py”, line 166, in run_command
print_process(process)
File “/home/bochengyu/Linux_for_Tegra/Linux_for_Tegra/bootloader/tegraflash_internal.py”, line 134, in print_process
output = process.stdout.read(1)
KeyboardInterrupt
Reading board information failed.

Thank you!

You may try to use a USB hub between your PC and Jetson. In my case it had solved similar issue.

If you are using a VM this has a very high rate of similar USB failures.