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.
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
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
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.
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:
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.
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:
[url]https://devtalk.nvidia.com/default/topic/1002081/jetson-tx2/jetpack-3-0-install-with-a-vm/[/url]
If not a VM, is there a HUB involved? Is the USB cable the original?
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?
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.
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.