Programming a blank TX1

I just received a TX1 with no BSP in flash. I am attempting to restore an image taken from my development kit that has 24.1 installed using the following instructions: http://elinux.org/Jetson/TX1_Cloning

I am getting the following error when sending the EBT, it seems this means I am getting an error code: nv3p_status_bct_req

Does anybody have any suggestions on what to check?

Thanks,

  • Mark

ubuntu@ubuntu:~/32_TX1/Linux_for_Tegra_32_tx1/bootloader$ sudo ./tegraflash.py --bl cboot.bin --applet nvtboot_recovery.bin --chip 0x21 --cmd “write APP my_backup_image_APP.img”
[sudo] password for ubuntu:
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.0019 ] Generating RCM messages
[ 0.0032 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 --download rcm nvtboot_recovery.bin 0 0
[ 0.0042 ] RCM 0 is saved as rcm_0.rcm
[ 0.0049 ] RCM 1 is saved as rcm_1.rcm
[ 0.0049 ] List of rcm files are saved in rcm_list.xml
[ 0.0049 ]
[ 0.0050 ] Signing RCM messages
[ 0.0061 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0073 ] Assuming zero filled SBK key
[ 0.0123 ]
[ 0.0124 ] Copying signature to RCM mesages
[ 0.0139 ] tegrarcm --chip 0x21 --updatesig rcm_list_signed.xml
[ 0.0193 ]
[ 0.0194 ] Boot Rom communication
[ 0.0207 ] tegrarcm --chip 0x21 --rcm rcm_list_signed.xml
[ 0.0217 ] BR_CID: 0x32101001642897892400000013060200
[ 0.2170 ] RCM version 0X210001
[ 0.2984 ] Boot Rom communication completed
[ 1.3841 ]
[ 1.3841 ] Sending bootloader and pre-requisite binaries
[ 1.3854 ] tegrarcm --download ebt cboot.bin 0 0
[ 1.3866 ] Applet version 00.01.0000
[ 1.6024 ] Sending ebt
[ 1.6028 ] 0000000b: Pre processing failed
[ 1.6604 ]
[ 1.6604 ]
Error: Return value 11
Command tegrarcm --download ebt cboot.bin 0 0

Are you positive that the Jetson was in recovery mode? Verify that on host “lsusb -d 0955:7721” has output prior to starting flash.

Yes, I have verifed it is in recovery mode:

ubuntu@ubuntu:~/32_TX1/Linux_for_Tegra_32_tx1/bootloader$
ubuntu@ubuntu:~/32_TX1/Linux_for_Tegra_32_tx1/bootloader$ lsusb -d 0955:7721
Bus 001 Device 012: ID 0955:7721 NVidia Corp.
ubuntu@ubuntu:~/32_TX1/Linux_for_Tegra_32_tx1/bootloader$
ubuntu@ubuntu:~/32_TX1/Linux_for_Tegra_32_tx1/bootloader$ sudo ./tegraflash.py --bl cboot.bin --applet nvtboot_recovery.bin --chip 0x21 --cmd “write APP my_backup_image_APP.img”
[sudo] password for ubuntu:
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.0019 ] Generating RCM messages
[ 0.0075 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 --download rcm nvtboot_recovery.bin 0 0
[ 0.0091 ] RCM 0 is saved as rcm_0.rcm
[ 0.0105 ] RCM 1 is saved as rcm_1.rcm
[ 0.0106 ] List of rcm files are saved in rcm_list.xml
[ 0.0106 ]
[ 0.0107 ] Signing RCM messages
[ 0.0126 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0140 ] Assuming zero filled SBK key
[ 0.0191 ]
[ 0.0192 ] Copying signature to RCM mesages
[ 0.0205 ] tegrarcm --chip 0x21 --updatesig rcm_list_signed.xml
[ 0.0242 ]
[ 0.0243 ] Boot Rom communication
[ 0.0253 ] tegrarcm --chip 0x21 --rcm rcm_list_signed.xml
[ 0.0264 ] BR_CID: 0x32101001642897892400000011000200
[ 0.1621 ] RCM version 0X210001
[ 0.2425 ] Boot Rom communication completed
[ 1.3303 ]
[ 1.3303 ] Sending bootloader and pre-requisite binaries
[ 1.3316 ] tegrarcm --download ebt cboot.bin 0 0
[ 1.3326 ] Applet version 00.01.0000
[ 1.5524 ] Sending ebt
[ 1.5531 ] 0000000b: Pre processing failed
[ 1.6124 ]
[ 1.6124 ]
Error: Return value 11
Command tegrarcm --download ebt cboot.bin 0 0
ubuntu@ubuntu:~/32_TX1/Linux_for_Tegra_32_tx1/bootloader$

One possibility is that if the JTX1 is mixing an earlier release with the R24.1 you are restoring there could be another incompatibility. Can you flash to R24.1 first to verify regular flash works? Then restore (tegraflash.py does not do everything the flash.sh script does, it is a subset…first doing everything and then just the rootfs clone restore guarantees it all matches).

One option is to do a normal R24.1 flash rather than directly using tegraflash.py, but add the “-r” option to reuse system.img (essentially flashing everything but never using the default sample rootfs…this would go directly to your clone rootfs). You’d have to put a copy of your root partition clone in “bootloader/system.img”. Just be careful to not destroy your original image. Note that if you had a specific size used for your root partition when originally flashed it might be useful (I’m not sure) to explicitly use that same size argument during the flash with restore option. E.g., something like this if you used maximum partition size in the past:

sudo ./flash.sh -r -S 14580MiB jetson-tx1 mmcblk0p1

I was just going down the same line of thought. Looking at the output of tegraflash.py vs. Jetpack, there are many distict differences. It looks like tegraflash isn’t restoring everything required (such as the bct, NVC and GPT), instead it is only flashing the rootfs. I’m sure there is a way to generate and program the necessary partitions, but I’m under a time crunch at the moment so this research will have to wait.

I just flashed the TX1 with Jetpack and now restoring my rootfs from tegraflash.py is working just fine.

It would be good to hear from NVidia on how to bring up a blank TX1 with a custom rootfs without having to use Jetpack first.

There is a partition table to see what partitions are on a Jetson (the table can be cloned and is a human readable plain text file), and every partition can be cloned individually, or the entire image spanning the full eMMC can be cloned (this differs somewhat from the JTK1 and I’m not sure of how to use the clone to get every part of a JTX1 the way I would on a JTK1). In theory you can clone not just the root partition, but all partitions, and restore them one at a time if cloned individually, or restore the image as a whole if the entire eMMC were cloned as a single integral file. You would not be able to loopback mount anything except the root partition clone, but you could extract a span of bytes from a clone of the whole eMMC and get the equivalent of any individual partition using dd (this is more of an academic exercise rather than being of practical use under normal circumstances).

Note that if your root partition is the wrong size for what the other partitions are then the loopback mounted (read-only) root partition image can be resized using something like gparted to match what is required. Remember that the root partition is appended at the end of the other partitions, so if other partitions differ then so does the start offset of the root partition…whether that root partition will fit on the remaining tail end of the eMMC is another question. Mismatched clone size versus eMMC layout won’t stop restore so long as the resize can cause a match to existing partition boundaries. The motivation in cases where I suggest using the “-S size” parameter for flash.sh even though a clone image is being reused is because I’m unsure of whether the partition table would look at the actual root partition size or be stuck with the old layout…perhaps some parts of flash pay attention to the image size and others pay attention to a previously written table.