Originally JetPack was purely for 14.04. I’m not sure if it is officially ok with 16.04 or not, but this has been something NVIDIA was working towards…16.04 support. JetPack 3.1 and 3.2 are known to work with 16.04. What you may find is that some optional package for host side install won’t install on 16.04, but everything important will work. So far as command line flash goes any x86_64 Linux PC will work (but you can’t install optional packages with command line…it is only for flash).
Moreover, the command line install is known to work with other Linux distributions than Ubuntu. Henceforth it is a more generic solution, in my opinion.
I agree…and JetPack can still be run at a later date to install packages to host or Jetson.
finally with installation real Ubunty-14.04 in my private old USB2.0-laptop I’ve flashed immage and install JetPack3.1 for CUDA-8 w/o problem and quite fast.
It’s amazing, it was so many problems with usb3.0, 16.04 and VMs, and very easily in a real hardware.
Thank you, devForum, for helping!
Have a good Friday!
You may also try jetpack 3.2
Regards,
USB 3 ports are fine. I flash from a USB 3 port on my workstation.
You should also be able to use a high-quality MicroUSB cable. I use a 6 foot Anker cable, and again, that works fine.
Just FYI, I also was unable to flash my TX2 using JetPack-L4T-3.2-linux-x64_b196.run from my Dell XPS13 DE with Ubuntu 16.04. I used the USB cable from the dev kit, and the device was recognized by the OS:
route34:bootloader$ lsusb -d 0955:7c18
Bus 001 Device 012: ID 0955:7c18 NVidia Corp.
I traced through flash.sh and tegrarcm_v2 is failing:
route34:bootloader$ sudo ./tegrarcm_v2 --uid
Failed to read UID
Since tegrarcm_v2 is a compiled program, doesn’t output any useful info, and doesn’t seem to have a --debug or --verbose option I’m not sure if there’s anything else I can do on this machine. Is the tegrarcm_v2 source code available somewhere so I can dig a little deeper?
The good news is that I successfully used @linuxdev’s manual instructions to flash the TX2 from a Debian 9 desktop machine so at least I’ve got a workaround, albeit a kludgey one.
I’m not sure what UID provides/affects.
A comment on USB 2 versus 3:
The micro-B connector is only useful with USB2…it lacks wiring to use USB3. USB3 on a host would in theory throttle back to USB2 for any system capable of doing so (and most systems are capable of doing so). One of the problems with a VM is that when checking on USB3 and reverting to USB2 the device might be lost. In fact any re-enumeration of devices on a VM means every single combination needs to enforce passing through to the VM and not dropping back to the host. Mode switching is a major headache for VMs.
So while a USB3 port on the host would in theory work for a Jetson flash, there would be an implied re-enumeration as it switches back to USB2. Starting with a purely USB2 port can simplify things.
Thanks for getting back so quickly!
Not sure either, but that was the command (and options) whose failure caused flash.sh to crap out so I was hoping it might provide some info if I ran it ad-hoc. Unfortunately not.
Interesting. I guess I’ll use the “old computer” workaround for the time being. I shouldn’t need to flash my TX2s often so it should be OK.
Hi,
I had a lot of similar problems flashing from my Dell machine (Latitude 7490) running native Ubuntu 16.04. After various combinations of USB ports and hubs, still same error. (device shows up in lsusb just fine).
After some testing I found a solution.
From flash.sh we can see that the failing command is:
sudo ./tegrarcm_v2 --uid
Indeed, even when the device is in recovery, the command fails. However, I noticed that running this command immediately after putting the device in recovery, it succeeds and reports the UID needed by the flash script. So, running the flash script from the terminal immediately after entering recovery lets the script start, build the image, and then tries to flash. However, it will then hang when trying to actually flash the device.
The final solution was to re-use the image from the previous attempt (that failed due to the hang) using the -r flag in the flash.sh script. The complete sequence was the following:
- Enter recovery w/ micro-usb cable connected to host.
- Immediately run
sudo ./flash jetson-tx2 mmcblk0p1(as described in the dev kit user guide) - Wait until the system builds the image, and hangs during the install (mine hangs after
tegrarcm_v2 --isapplet - Restart and re-enter recovery
- Run the flash again with the
-rflag:sudo ./flash -r jetson-tx2 mmcblk0p1
I have still to install the rest of the packages, but at least the system is flashed and can be accessed from the console.
This seems like an interesting bug. If anyone knows where to report it properly, let me know.
I was stuck trying to flash it for a couple of days, unsuccessfully, with the same problem as described, and this solution also worked for me!
Thanks so much.
This fix worked for me as well with a Xavier AGX (host: Ubuntu 18.04.5 LTS, kernel 4.15.0-122-generic) with one modification. On step 5 (i.e. rerunning flash with the -r flag) it was still hanging at the tegrarcm_v2 --isapplet, maybe because it still took a little to long to get to that point? I was able to make it work, though, by following steps one through 5 - then restarting the xavier back into recovery again while the script was running, and just before it got to the point where it normally hangs. After it got through that portion the rest of the process seemed to go all right, and the newly flashed Xavier seems to be working without issue.