Flashing Jetpack 3.2 onto my TX1 consistently hangs at the same point. I’ve repeated the process a few times now with the same outcome.
I’ve successfully flashed earlier versions onto this TX1.
I am now seeing a new solid red led (by the heatsink and PCIe connector after my last attempt.
It feels like I’ve bricked it.
Any help would be appreciated.
This is the tail end of the log file.
*** Flashing target device started. ***
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
The solid red light is just a power indicator…older carriers did not have this, but when you do have this it is “a good thing” :) Not bricked. If a partial flash changed the system you’ll just need a successful flash to get it working.
Is there anything unusual about the host, e.g., is it a VM?
I am installing from a VM (Ubuntu 16.04). This is the same virtualbox VM I used to successfully flash the Jetson a few months ago. It’s the same setup, cables etc… I can’t think of anything unusual.
The reason I mentioned the red led is that I don’t ever remember seeing it on. This isn’t the usual red power led that comes on when power is attached. This one is at the opposite end of the heatsink.
The LED opposite to the power LED is PCIe power. Not all carriers have that LED (I have an older carrier without the LED, and a newer carrier with the LED). Power will always light the one on the J21 side, but the PCIe one will only light under some circumstances (software state will change if this rail is powered). In particular, there are various power saving states which change power to PCIe. Your hardware is ok :)
The VM is almost certainly the problem. If it worked before you probably got lucky. There are also definite differences between different releases. My thought is that when it worked you just got lucky. The USB side is particularly “flakey” (that’s a technical term!) in a VM. Any change to USB state can change whether or not the VM fails.
I have the same issue and can confirm that flashing the TX1 with jetpack 3.0 on a VM (virtualbox ubuntu 16.04 on windows 10 host) works fine every time (I’ve used at least 10 times) and flashing with jetpack 3.2 never works and always hangs at:
VM’s used to work with older releases, but they definitely don’t work now.
Before I switched my development computer to linux I had an old laptop I used for flashing. You can also set up dual boot Ubuntu on a windows computer really easily.
I had the same experience with hangs using a VirtualBox VM as host. I got flashing to work reliably, but I’m not sure how.
My best guess is that the USB connection to the TX1 is closed/reset/reopened several times during the flash process, but I hadn’t correctly configured VirtualBox to automatically reattach the USB connection to the VM. So after each disconnect, I had to reattach manually, which maybe wasn’t what the JetPack utility expected to happen.
I changed the VM’s USB settings, adding a filter with minimal information:
Name: NVIDIA Corp. APX
Vendor ID: 0955
Remote: No
I also updated VirtualBox (to version 5.2.12) and the Oracle VM VirtualBox Extension Pack. Then in the VM’s USB settings, I enabled the “USB 3.0 (xHCI) Controller”. Now the TX1’s USB connection automatically attaches to the VM, and flashing JetPack works.
Hope this helps. My laptop’s OS is Ubuntu 18.04 64-bit; my VM’s OS is Ubuntu 16.04 64-bit. I’m using JetPack L4T 3.2. I’m flashing a TX1.
FYI, the micro-USB connector is not capable of using USB3…it runs only at USB2 speeds. A USB3 port on a PC will detect USB2 or USB3 and switch which controller routes to the port. The problem isn’t typically a question of having USB3 enabled so much as it is that VMs seem to lose their concept of whether the hardware is there when various stages of flash cause a re-enumeration of USB devices. A USB connector running on a non-VM always knows that it owns that device even if enumeration is going on…a VM can lose knowledge of the device under different circumstances. Having USB3 may change the configuration such that knowledge of the device is not lost during flash, but it isn’t USB3 itself which is fixing this…it is a side-effect of a different VM configuration. USB2 would be better…but only if the configuration doesn’t cause the VM to lose the device each time it re-enumerates (though in reality “best” is the one which works:).
Same thoughts on my side, I only did turn on USB3.0 after reading this thread.
I didn’t even realise, that this was the only difference between my development vm and the automatically provisioned Jetson-Flashing vm.
It must be something in the way VirtualBox handles USB. And it is consistent over different host operating system. I hade the same problem with Mac OS and Windows.
I can only speculate, but normally there is a mechanism on a USB3 port to detect USB2 and reroute to a different controller. I suspect that the mechanism to reroute upon re-enumeration is not normally enabled in the VM, but the USB3 to USB2 reroute could possibly trigger this. It should be possible to set it to always route certain USB2 devices to the VM using some other method…I don’t know what it is, I don’t use VMs.