Is the micro-B USB cable connected? Verify the host sees the Jetson in recovery mode via a response from:
lsusb -d 0955:772
# EDIT: Not sure what happened there but "722" is a typo. JTK1 is 0955:7140, JTX1 is 0955:7721
Note that if you do something with a Jetson in recovery mode (such as flash or clone), then you’ll need to restart in recovery mode for each new recovery mode operation (if you flash once, you need to restart recovery mode to start a new flash attempt…if you clone a partition, then you need to restart recovery mode to start cloning another partition).
Did you use JetPack, or did you use the command line “flash.sh” script? You could log the flash.sh output via:
sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1 2>&1 | tee flash_log.txt
Once it stalls out for a short time you could hit control-c to end the command, then post the flash_log.txt here (post a reply, then mouse hover of the quote icon in the post’s upper right corner…an paper clip attach icon should show up).
It looks like things start out normally and communications with the Jetson works (it isn’t a cable issue and the Jetson is definitely in recovery mode and able to reply).
When it goes to put cboot.bin in, it fails. If you go to the installer directory “Linux_for_Tegra/bootloader”, what is the output of this command:
Assuming L4T version R24.2, output should be file sizes 422704 bytes, sha1sum should be “99a8ed5a9292cd1836a09867d79a64596df631ab”. If other than R24.2 (see the “rootfs/etc” subdirectory, “head -n 1 nv_tegra_release”) the values will differ, but can be checked.
Given the successful steps for other previous communications with the Jetson, and with the correct content of the file transfer which stalls and fails, I’d recommend wiping the install software directory and re-downloading and unpacking it again (it looks like you did things correctly, and the Jetson seems to start out ok).
Should you want to debug instead, someone will have to give provide information on the meaning of this tegrarcm log excerpt:
I’ve tried to re-download JetPack again and also downloaded different version (2.2.1), but still got the same result. Except one try when i didn’t get that error and flashing proceeded. But then it hung on message
My observation is that obviously some software and some of the flash data transfer succeeds. I believe your methods are correct, and so issues are either software or hardware. The one time partial increase in how far it gets likely means the eMMC at the location of the previous stall works, although I wouldn’t guarantee 100%…but it has worked at least once. Then it stalled at a different place, not much further ahead. You’ve tried with a clean install and with an alternate version install…I’m thinking it isn’t software either, although there is no smoking gun to prove that.
I’m leaning towards either the USB communications being at fault, or something within the Jetson hardware. USB communications issues are actually somewhat common, although normally associated with the host, especially if the host is a VM. On rare occasion a different non-VM host fixes something like this…or in the case of a VM host, changing USB setup. I don’t know what your situation is so far as ability to try a different host, but provide more details on your current host…Linux version, any USB HUB in the chain of USB cabling, so on. Consider direct attachment of the micro-B USB cable from Jetson direct to host with nothing intervening. Consider using a live CD type Ubuntu which mounts the original hard drive in order to perform the flash if you want to try a different Ubuntu version which does not require permanent install. If you want to try installing with the simplest command line you could try a live CD of something like Fedora 23 (Fedora can’t use JetPack, but you can “sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1”). You’d be isolating results of how hardware behaves using alternate operating system versions. Use a different micro-B USB cable if available (it usually is not the cable, but most devices these days come with an OTG port, and type micro-B USB cable, so chances are you have a spare somewhere).
It could also be the Jetson. It might be time to RMA, but if it turns out to be a host issue, then you’re back to the same problem. If the issue is something simple like the USB cable or HUB, it’s a big consumption/waste of time for something otherwise quick to fix. So testing the host itself, though requiring time, might be the shortest “predictable” route to go. If you had a second Jetson, then swapping it out for flash test would be instant knowledge of what goes wrong, but RMA and shipping isn’t as fast as testing host issues first.
Hello,
No, I didn’t manage to revive the board. I tried flashing on a different machine, on different Linux distros (Ubuntu 14.04, Ubuntu 16.05) and with different micro USB cables (and also using different Jetpack versions). The reason why I wanted to flash the board was because the board didn’t boot OS. I didn’t save the logs received via UART. Eventually, I’ve sent the board to our reseller for RMA.
I have same problem and did every suggestion but couldn’t manage to start Jetson TX1 (I have 4 Jetson TX1 and only one of them is not flashing). If there is practical solution please let me know. Otherwise only solution is to use RMA.