Flashing Jetpack 3.2 onto TX1 Hangs

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

[ 0.0000 ] Generating RCM messages
[ 0.0062 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 --download rcm nvtboot_recovery.bin 0 0
[ 0.0072 ] RCM 0 is saved as rcm_0.rcm
[ 0.0120 ] RCM 1 is saved as rcm_1.rcm
[ 0.0120 ] List of rcm files are saved in rcm_list.xml
[ 0.0120 ]
[ 0.0120 ] Signing RCM messages
[ 0.0165 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0182 ] Assuming zero filled SBK key
[ 0.0369 ]
[ 0.0370 ] Copying signature to RCM mesages
[ 0.0378 ] tegrarcm --chip 0x21 --updatesig rcm_list_signed.xml
[ 0.0399 ]
[ 0.0400 ] Parsing partition layout
[ 0.0581 ] tegraparser --pt flash.xml.tmp
[ 0.0806 ]
[ 0.0806 ] Creating list of images to be signed
[ 0.0871 ] tegrahost --chip 0x21 --partitionlayout flash.xml.bin --list images_list.xml
[ 0.1145 ]
[ 0.1145 ] Generating signatures
[ 0.1154 ] tegrasign --key None --list images_list.xml --pubkeyhash pub_key.key
[ 0.1161 ] Assuming zero filled SBK key
[ 0.1948 ]
[ 0.1948 ] Generating br-bct
[ 0.1990 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.cfg --chip 0x21
[ 0.1999 ] Copying Sdram info from 1 to 2 set
[ 0.2059 ] Copying Sdram info from 2 to 3 set
[ 0.2154 ]
[ 0.2154 ] Updating boot device parameters
[ 0.2162 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.bct --chip 0x21 --updatedevparam flash.xml.bin
[ 0.2171 ] Warning: No sdram params
[ 0.2253 ]
[ 0.2253 ] Updating bl info
[ 0.2261 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.bct --chip 0x21 --updateblinfo flash.xml.bin --updatesig images_list_signed.xml
[ 0.2343 ]
[ 0.2343 ] Updating secondary storage information into bct
[ 0.2351 ] tegraparser --pt flash.xml.bin --chip 0x21 --updatecustinfo P2180_A00_LP4_DSC_204Mhz.bct
[ 0.2486 ]
[ 0.2486 ] Updating board information from board config into bct
[ 0.2494 ] tegraparser --boardconfig board_config_p2597-devkit.xml --chip 0x21 --updatecustinfo P2180_A00_LP4_DSC_204Mhz.bct
[ 0.2586 ]
[ 0.2586 ] Updating Odmdata
[ 0.2595 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.bct --chip 0x21 --updatefields Odmdata =0x84000
[ 0.2603 ] Warning: No sdram params
[ 0.2689 ]
[ 0.2689 ] Get Signed section bct
[ 0.2697 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.bct --chip 0x21 --listbct bct_list.xml
[ 0.2780 ]
[ 0.2780 ] Signing BCT
[ 0.2795 ] tegrasign --key None --list bct_list.xml --pubkeyhash pub_key.key
[ 0.2802 ] Assuming zero filled SBK key
[ 0.2966 ]
[ 0.2966 ] Updating BCT with signature
[ 0.2974 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.bct --chip 0x21 --updatesig bct_list_signed.xml
[ 0.3090 ]
[ 0.3090 ] Copying signatures
[ 0.3099 ] tegrahost --chip 0x21 --partitionlayout flash.xml.bin --updatesig images_list_signed.xml
[ 0.3108 ] Run tegrabct to update tboot signature in bct
[ 0.3298 ]
[ 0.3298 ] Updating BFS information
[ 0.3336 ] tegrabct --bct P2180_A00_LP4_DSC_204Mhz.bct --chip 0x21 --updatebfsinfo flash.xml.bin

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.

Thanks for the speedy response. I’ll see about pulling together a setup without a “flakey” VM before trying again.

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:

tegrabct --bct P2180_A00_LP4_DSC_204Mhz.bct --chip 0x21 --updatebfsinfo flash.xml.bin


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.

Good to know! I’ll setup a dedicated ubuntu computer for this then.


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.

For me it were exactly the two things kaben.nanlohy said:

a) Turn on USB3.0
b) Turn on auto connect for the NVidia USB device

Since then it works flawlessly on a VirtualBOx running Ubuntu 16.04

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.