Jetpack 3.0 freezes during flash

I have an issue with my TX2. I’m trying to install the new Jetpack 3.0, but the process freezes at the very beginning of the flash step.

After a few msec I get:

[0.0093] Assuming zero filled SBK key
[0.0152] Copying signature to TCL messages
[0.0165] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml

I tried several times to restart the process, but it hangs out at the same point.
I deleted everything then I downloaded the whole Jetpack again, but it freezed at the same point.

What could it be the issue?

Thank you

I ran into this same issues when trying to flash using a VM of 14.04 with a USB 1.1 settings. My solution was to use 16.04.

I noticed on my Fedora host that may not be correctly using losetup. In a case where the loop device already exists flash works normally; in a case where the loopback device does not exist the losetup command is not correct for creating the loopback device. When I went to flash I had to manually create “/dev/loop0” before creating the system image would succeed.

I have not looked to see what edit is needed. As a workaround, prior to flash, run this command:

sudo losetup --find

…then verify “/dev/loop0” exists.

This is very curious. What is loopback used for during flashing?

The image which makes up the rootfs starts as a regular file of the exact size of the rootfs. This is covered by loopback in order to run mkfs.ext4 on it, and then to mount/copy files over to it. It isn’t until the full-sized image is finished that the sparse/compressed image is created from that. system.img.raw and a clone are the same thing, but system.img.raw is generated and a clone is copied.

Anyone can use a loopback device, only root can create one. Assuming that “/dev/loop0” exists is a logic bug in the script. If root runs “losetup --find” then not only is the first unused device found, it is also created…if anyone but root runs “losetup --find” it might report the first unused loop device, but the device would not be created if it doesn’t already exist.

Windows does not do loopback, this is one reason why you can’t create a flash program that runs from Windows (understanding Linux file systems and mkfs.ext4 is another reason…then there is the matter of setting up installed files with Linux permissions…and there is Windows’ lack of understanding device special files and symbolic links…the list goes on…but losetup has to succeed before any of the other details can even start).

Thank you for the explanation linuxdev.
I hadn’t had any issues until today when I went to flash. For others that stumble on this later, I found that you have to

$ sudo losetup --find

and make sure that you power down the Jetson, and then set it back to force recovery mode.

There’s a very subtle issue, but very important: Any operation (or operation attempt such as flash or clone) on a Jetson in recovery mode requires restarting the Jetson once again in recovery mode before each operation…should flash fail you have to restart recovery mode even though lsusb says the Jetson is still there.

I always made this step because I assume that if a flashing operation fails it leaves the Jetson in a not consistent status.

I’m going to try to flash it again in a few hours checking the loopback status of my laptop.

I had issues flashing the TX2 with Jetpack 3 as well (no success so far).
This is likely something different but it fits the thread title anyway.

I get stuck at downloading manifest.
After many attempts, each time in a new directory it progressed to the module selection (I have no clue why suddenly as the connection was fine before as well).

I had to leave that running over night. Apparently something failed since when I wanted to flash in the morning (with NEXT button etc) some ‘tar error’ came up and the process was claimed to have completed successfully.

My question now is: can I restart the jetpack in the same directory?
Must I manually delete the update.lock?
I would prefer not to download those ~8 GB again (it takes hours).

I saw in an older thread about Tx1 that this might have been an issue with connections:
(with latest jetpack of course)

Is that still a valid option?

I suspect it to play a role as my laptop loses bandwidth/connection when the Jetpack started.
During the download of the packages all (seemingly) went fine though.

Here I am again… I tried to check for loopback presence and the command “sudo losetup --find” reported “/dev/loop0”.

I tried to flash it again, but the result is again the same, hanged out in this way:

./ --chip 0x18 --applet "/home/myzhar/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.0022 ] Generating RCM messages
[   0.0034 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 --download rcm /home/myzhar/Nvidia/64_TX2/Linux_for_Tegra_tx2/bootloader/mb1_recovery_prod.bin 0 0
[   0.0044 ] RCM 0 is saved as rcm_0.rcm
[   0.0051 ] RCM 1 is saved as rcm_1.rcm
[   0.0051 ] List of rcm files are saved in rcm_list.xml
[   0.0051 ] 
[   0.0051 ] Signing RCM messages
[   0.0065 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[   0.0082 ] Assuming zero filled SBK key
[   0.0143 ] 
[   0.0143 ] Copying signature to RCM mesages
[   0.0154 ] tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml

This error message does occur prior to loopback being required. I could see issues with USB getting in the way if it is a VM. Is this a regular host or is a VM being used? Also, with the Jetson connected in recovery mode, what does “lsusb -t” show?

I also wonder if perhaps rcm_list_signed.xml involves remote networking…if so, then there may also be network issues. I’m thinking that either rcm_list_signed.xml is downloaded over a network, or perhaps content within rcm_list_signed.xml refers to network addresses (or both).

The host is a laptop running Ubuntu 14.04. It is connected to internet by Wifi using the access point where Jetson TX2 is connected by wire.

The only test I have not yet done is to connect the laptop by wire to the access point.

However I do not think that there is any network related problem since I can download all the files of the Jetpacck in less than 30 minutes.

I forgot only to say one thing: I downloaded only the part of files related to device installation, I always do not download host files because I’m not used to cross compile my softwares.

During and after a failed install can you see “rcm_list_signed.xml” anywhere in your JetPack directory (or perhaps under a temp directory or in “/var/”)? I’m curious if the file is there or not and whether the file contains a URL which might be referenced.

Nothing… I downloaded again the full package, connected the laptop to access point by wire, connected the laptop to power cord… same freeze.

I verified the presence of the file “rcm_list_signed.xml” and I can find it (while flash is freezed) under “/home/myzhar/Nvidia/64_TX2/Linux_for_Tegra_tx2/bootloader/16540”.

The output of the “lsusb -t” command is:

myzhar@myzharbot-control ~ $ lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 2: Dev 11, If 0, Class=Vendor Specific Class, Driver=, 480M
    |__ Port 3: Dev 2, If 0, Class=Vendor Specific Class, Driver=rts5139, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
        |__ Port 5: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
        |__ Port 5: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
        |__ Port 4: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
        |__ Port 4: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M

I’m assuming the recovery mode Jetson is (in this case) bus 03 port 2. This correctly runs at 480Mbit/sec, so basic USB is correct.

Can you post the content of rcm_list_signed.xml? Or at least explore this and see if any web URLs are indicated for resources which might be downloaded, and then see if you can ping those addresses? I have no idea what the content of this file is, but I am curious if having the file implies the next step requires the internet or not.

Hi Myzhar,

Is this still an issue in you sides?
Any further experiment result can be shared?


All the tests I made failed. I also tried to use another PC to test the update, but nothing changed.
I spoke about this problem with Barrett W. and he said to me that he faced something similar and that he’d have contacted me if there was something new.

Any progress on this front? I’m running into the same problem when trying to flash the TX2 module.

Bump. I am having this same issue with my TX2 module.

Seems like the rcm_list_signed.xml is referencing “rcm_0_signed” and “rcm_1_signed” neither of which exist in the directory tree. Not sure if they are being created during this step or utilized, but either way something is going on there. Though, .rcm, .hash, and encrypt.rcm exist for both rcm_0 and rcm_1.

Also another thing to note is that the “rcm_list.xml” and “rcm_list_signed.xml” are ALMOST identical. Main difference being that “rcm_list_signed.xml” has “mode=‘sbk’” in the file list tag.

Another minor note is that “rcm_list.xml” contains self closing tags and “rcm_list_signed.xml” does not, though I doubt this would be an issue.

I’m happy to provided any information I can to clear up this issue, if possible.

This is a major discrepancy in the device drivers. I have been facing the same problem and I have tried all solutions with both 14.04 and 16.04. But the flashing still freezes at

tegrarcm_v2 --chip 0x18 --updatesig rcm_list_signed.xml.

We are running a time sensitive project and this problem has no solution.