Jetson Nano eMMC APP backup fails to create image file (Error 8)

Hello. Using toolchain from release 32.7.1. Attempting to backup the APP partition on eMMC using the following:

sudo ./flash.sh -r -k APP -G backup.img jetson-nano-emmc mmclbk0p1

Results in the following:

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.0036 ] Generating RCM messages
[ 0.0060 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 0 --download rcm nvtboot_recovery.bin 0 0
[ 0.0073 ] RCM 0 is saved as rcm_0.rcm
[ 0.0077 ] RCM 1 is saved as rcm_1.rcm
[ 0.0079 ] List of rcm files are saved in rcm_list.xml
[ 0.0079 ]
[ 0.0079 ] Signing RCM messages
[ 0.0099 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0108 ] Assuming zero filled SBK key
[ 0.0156 ]
[ 0.0157 ] Copying signature to RCM mesages
[ 0.0180 ] tegrarcm --chip 0x21 0 --updatesig rcm_list_signed.xml
[ 0.0198 ]
[ 0.0199 ] Boot Rom communication
[ 0.0221 ] tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml
[ 0.0233 ] BootRom is not running
[ 0.4572 ]
[ 0.4573 ] Parsing partition layout
[ 0.4606 ] tegraparser --pt flash.xml.tmp
[ 0.4627 ]
[ 0.4628 ] Creating list of images to be signed
[ 0.4654 ] tegrahost --chip 0x21 0 --partitionlayout flash.xml.bin --list images_list.xml
[ 0.4755 ]
[ 0.4755 ] Generating signatures
[ 0.4781 ] tegrasign --key None --list images_list.xml --pubkeyhash pub_key.key
[ 0.4791 ] Assuming zero filled SBK key
[ 0.5640 ]
[ 0.5640 ] Send BCT from Host
[ 0.5640 ] Generating br-bct
[ 0.5664 ] tegrabct --bct P3448_A00_lpddr4_204Mhz_P987.cfg --chip 0x21 0
[ 0.5707 ]
[ 0.5707 ] Updating boot device parameters
[ 0.5726 ] tegrabct --bct P3448_A00_lpddr4_204Mhz_P987.bct --chip 0x21 0 --updatedevparam flash.xml.bin
[ 0.5734 ] Warning: No sdram params
[ 0.5737 ]
[ 0.5737 ] Updating bl info
[ 0.5745 ] tegrabct --bct P3448_A00_lpddr4_204Mhz_P987.bct --chip 0x21 0 --updateblinfo flash.xml.bin --updatesig images_list_signed.xml
[ 0.5760 ]
[ 0.5760 ] Updating secondary storage information into bct
[ 0.5781 ] tegraparser --pt flash.xml.bin --chip 0x21 0 --updatecustinfo P3448_A00_lpddr4_204Mhz_P987.bct
[ 0.5798 ]
[ 0.5799 ] Updating Odmdata
[ 0.5819 ] tegrabct --bct P3448_A00_lpddr4_204Mhz_P987.bct --chip 0x21 0 --updatefields Odmdata =0xa4000
[ 0.5831 ] Warning: No sdram params
[ 0.5834 ]
[ 0.5835 ] Get Signed section of bct
[ 0.5857 ] tegrabct --bct P3448_A00_lpddr4_204Mhz_P987.bct --chip 0x21 0 --listbct bct_list.xml
[ 0.5873 ]
[ 0.5874 ] Signing BCT
[ 0.5919 ] tegrasign --key None --list bct_list.xml --pubkeyhash pub_key.key
[ 0.5928 ] Assuming zero filled SBK key
[ 0.5934 ]
[ 0.5934 ] Updating BCT with signature
[ 0.5955 ] tegrabct --bct P3448_A00_lpddr4_204Mhz_P987.bct --chip 0x21 0 --updatesig bct_list_signed.xml
[ 0.5968 ]
[ 0.5968 ] Sending BCTs
[ 0.5990 ] tegrarcm --download bct P3448_A00_lpddr4_204Mhz_P987.bct
[ 0.6002 ] Cannot open usb device.Check if device is in recovery
[ 1.2981 ] **
Error: Return value 8
Command tegrarcm --download bct P3448_A00_lpddr4_204Mhz_P987.bct
***** The [APP] has been read successfully. *****
** Converting RAW image to Sparse image… mv: cannot stat ‘/home/jason/dev/jetson_nano_devkit/Linux_for_Tegra/backup.img’: No such file or directory

open input file /home/jason/dev/jetson_nano_devkit/Linux_for_Tegra/backup.img.raw failed.

Hi jbattin83,

[ 0.6002 ] Cannot open usb device.Check if device is in recovery

Please help to check if your board is in force recovery state before flash.

You can run lsusb on your host PC to check.

Hi @KevinFFF,

Thanks for the reply. The board starts in recovery. I’m not sure it would make it this far if it wasn’t. Maybe it is getting kicked out somehow. I will tail the logs to see if disconnect occurs during the backup. Is a disconnect expected at this step?

It appears there is a disconnect happening at the point of failure (there are actually several disconnects during the initial stages of this process). Maybe things are moving too fast for the Ubuntu vbox to grab the USB device from the host.

Apr 12 09:04:52 ubuntu kernel: [930357.056310] usb 3-2: USB disconnect, device number 9
Apr 12 09:04:56 ubuntu kernel: [930360.584495] usb 3-2: new high-speed USB device number 10 using xhci_hcd
Apr 12 09:04:56 ubuntu kernel: [930360.735198] usb 3-2: New USB device found, idVendor=0955, idProduct=7f21, bcdDevice= 1.02
Apr 12 09:04:56 ubuntu kernel: [930360.735212] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Apr 12 09:04:56 ubuntu kernel: [930360.735221] usb 3-2: Product: APX
Apr 12 09:04:56 ubuntu kernel: [930360.735228] usb 3-2: Manufacturer: NVIDIA Corp.

Interesting, though. Today the script hangs on

[ 0.5968 ] Sending BCTs
[ 0.5990 ] tegrarcm --download bct P3448_A00_lpddr4_204Mhz_P987.bct

Maybe it’s working? I hung around for about 5 minutes and didn’t see any file creation happening. Disk space doesn’t budge either. I will give it another 5 minutes.

[UPDATE] Left it hanging for about 45 minutes. No movement.

I see “APX”. Is this a VM? If so, then it is the VMs fault for not reconnecting after disconnect. USB will disconnect and reconnect during flash, this is normal. A non-VM though will reconnect.

Hi @linuxdev,

Thanks for the reply. I’m not convinced its anyones “fault”. I have flashed several Jetson boards from this VM without issue. This failure only occurs when I try to read back a partition. I would be curious to see what delay is being used after a disconnect in Tegraflash. Seems to me that a few extra milliseconds would probably do the trick. Unfortunately as you know, the app is closed source.

VMs have to be told to pass USB through. Depending on setup, they might not reacquire USB if it disconnects and reconnects. This is completely out of the control of the software running within the VM (the flash software cannot tell the VM to reconfigure, it has no idea USB was lost due to the VM setup).

Again, I realize the limitations of a VM. The box is told to automatically use the VID and PID of APX when it plugs in. Please recall that the device disconnects several times during a flash and is able to continue under normal conditions. The problem is specific to reading a partition.

Perhaps the host PC ran out of space? During a clone it is the .img.raw which is created first. This file is the exact same byte size as the rootfs partition. If the partition is 28 GB, then so is that file. Then the sparse file is generated based on that, and this file is slightly larger than the actual content stored on the partition (on a freshly flashed Jetson that’d be around 3.5 GB).

Yeah. I considered the space issue as well. The image file never gets created. Disk space does not budge during the process. I do have enough space to cover the APP partition however, should the flash utility create the img and img.raw file. I also verified the path the utility is using actually exists.

Since you are using sudo there shouldn’t be a permissions problem, but for debugging purposes, what do you get without sudo if you:

cd /where/ever/it/is/Linux_for_Tegra
touch bootloader/backup.img
ls -l bootloader/backup.img

Then, if that fails, try using sudo. If it does not fail, don’t bother using sudo. However, I’m also interested in which filesystem type is involved. From that Linux_for_Tegra/ directory, what do you see from:
df -H -T .
(the “.” is important, it is an alias for “the current directory”)

I suspected something similar but I am not able to run the script without sudo. Unless there is a workaround I am unaware of. Regardless, here is the info you wanted to see.

jason@ubuntu:~/nvidia/L4T32.7.1/Linux_for_Tegra$ touch bootloader/backup.img
jason@ubuntu:~/nvidia/L4T32.7.1/Linux_for_Tegra$ ls -l bootloader/backup.img 
-rw-rw-r-- 1 jason jason 0 Apr 12 14:25 bootloader/backup.img

jason@ubuntu:~/nvidia/L4T32.7.1/Linux_for_Tegra$ df -H -T .
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda5      ext4  169G  118G   45G  73% /

Well, you do have permissions, and have proven that location is writable by your user. You have 45 GB available there (actual storage might be slightly less). I don’t know what the inode usage is, and I doubt that’s a problem, but what do you see from that location via:
df -H -i .
(this displays inodes, which are basically metadata consumed when storing content; if inodes run out, then a nearly empty filesystem will actually be filled without ever coming close to filling the space)

The more likely answer depends on the partition size. On the Jetson, what is the partition you are backing up? What is the actual partition size (the total, not just the amount currently stored)?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.