With the release of R23.1 for TX1, the “nvflash” app no longer exists, and appears to be just a blank placeholder. What would the clone tools be for cloning partition tables, root partition, and all partitions?
nvflash has been succeeded by tegraflash.py
tegraflash.py includes the read and write commands for backing-up and restoring partitions, respectively.
It looks like cloning the entire eMMC device including all partitions, may require additional scripting. The python source can easily be edited however.
It looks like tegraflash.py options for reading may need some explanation in order to clone TX1 partitions. It’s nice that tegraflash.py has an interactive shell, and commands such as “read” prompt for information. The problem is, I don’t know the answer to some of those parameters. I’m guessing “APP” (which is correct for TK1) is the root partition in TX1 as well, but to read “APP” (or to find out if it doesn’t exist), a “–bl” option is also required. In TK1 it was fastboot.bin, which I believe interacts with 3pserver…there is no fastboot.bin in the R23.1 installer, but there are others which may be a candidate, such as mvtboot.bin and nvtboot_recovery.bin. Would it be possible to get a list of which partitions “read” can be used with to clone, and what to use with options like --bl?
It turns out that cboot bootloader was built with the cloning commands. Use the following to clone APP partition, for example:
Backing up an image
sudo ./tegraflash.py --bl cboot.bin --applet nvtboot_recovery.bin --chip 0x21 --cmd “read APP my_backup_image_APP.img”
dusty@dusty-ubuntu-PC:~/workspace/JetPack-L4T-2.0/Linux_for_Tegra_tx1/bootloader$ sudo ./tegraflash.py --bl cboot.bin --applet nvtboot_recovery.bin --chip 0x21 --cmd "read APP my_backup_jetpack_231_APP.img" [sudo] password for dusty: 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.0025 ] Generating RCM messages [ 0.0047 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 --download rcm nvtboot_recovery.bin 0 0 [ 0.0059 ] RCM 0 is saved as rcm_0.rcm [ 0.0105 ] RCM 1 is saved as rcm_1.rcm [ 0.0105 ] List of rcm files are saved in rcm_list.xml [ 0.0105 ] [ 0.0105 ] Signing RCM messages [ 0.0149 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.hash [ 0.0164 ] Assuming zero filled SBK key [ 0.0313 ] [ 0.0313 ] Copying signature to RCM mesages [ 0.0325 ] tegrarcm --chip 0x21 --updatesig rcm_list_signed.xml [ 0.0339 ] [ 0.0339 ] Boot Rom communication [ 0.0348 ] tegrarcm --rcm rcm_list_signed.xml [ 0.0357 ] BootRom is not running [ 0.2092 ] [ 0.2093 ] Retrieving storage infomation [ 0.2104 ] tegrarcm --oem platformdetails storage storage_info.bin [ 0.2113 ] Applet version 00.01.0000 [ 0.3594 ] Saved platform info in storage_info.bin [ 0.3606 ] [ 0.3606 ] Reading BCT from device for further operations [ 0.3606 ] Sending bootloader and pre-requisite binaries [ 0.3619 ] tegrarcm --download ebt cboot.bin 0 0 [ 0.3630 ] Applet version 00.01.0000 [ 0.5354 ] Sending ebt [ 0.5381 ] [................................................] 100% [ 0.8105 ] [ 0.8111 ] tegrarcm --boot recovery [ 0.8117 ] Applet version 00.01.0000 [ 0.9603 ] [ 0.9603 ] Reading partition [ 0.9621 ] tegradevflash --read APP /home/dusty/workspace/JetPack-L4T-2.0/Linux_for_Tegra_tx1/bootloader/my_backup_jetpack_231_APP.img [ 0.9629 ] Cboot version 00.01.0000 [ 1.6797 ] Reading partition APP in file /home/dusty/workspace/JetPack-L4T-2.0/Linux_for_Tegra_tx1/bootloader/my_backup_jetpack_231_APP.img [ 1.6807 ] [................................................] 100% [ 3279.1986 ]
Restoring an image
sudo ./tegraflash.py --bl cboot.bin --applet nvtboot_recovery.bin --chip 0x21 --cmd “write APP my_backup_image_APP.img”
dusty@dusty-ubuntu-PC:~/workspace/JetPack-L4T-2.0/Linux_for_Tegra_tx1/bootloader$ sudo ./tegraflash.py --bl cboot.bin --applet nvtboot_recovery.bin --chip 0x21 --cmd "write APP my_backup_jetpack_231_APP.img" [sudo] password for dusty: Sorry, try again. [sudo] password for dusty: 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.0027 ] Generating RCM messages [ 0.0050 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 --download rcm nvtboot_recovery.bin 0 0 [ 0.0061 ] RCM 0 is saved as rcm_0.rcm [ 0.0081 ] RCM 1 is saved as rcm_1.rcm [ 0.0089 ] List of rcm files are saved in rcm_list.xml [ 0.0124 ] [ 0.0125 ] Signing RCM messages [ 0.0146 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.hash [ 0.0157 ] Assuming zero filled SBK key [ 0.0242 ] [ 0.0243 ] Copying signature to RCM mesages [ 0.0255 ] tegrarcm --chip 0x21 --updatesig rcm_list_signed.xml [ 0.0272 ] [ 0.0272 ] Boot Rom communication [ 0.0283 ] tegrarcm --rcm rcm_list_signed.xml [ 0.0293 ] BR_CID: 0x32101001640ca588100000000aff8380 [ 0.1769 ] RCM version 0X210001 [ 0.2645 ] Boot Rom communication completed [ 1.2711 ] [ 1.2711 ] Sending bootloader and pre-requisite binaries [ 1.2720 ] tegrarcm --download ebt cboot.bin 0 0 [ 1.2727 ] Applet version 00.01.0000 [ 1.4215 ] Sending ebt [ 1.4241 ] [................................................] 100% [ 1.7419 ] [ 1.7426 ] tegrarcm --boot recovery [ 1.7432 ] Applet version 00.01.0000 [ 1.8947 ] [ 1.8948 ] Writing partition [ 1.8966 ] tegradevflash --write APP /home/dusty/workspace/JetPack-L4T-2.0/Linux_for_Tegra_tx1/bootloader/my_backup_jetpack_231_APP.img [ 1.8973 ] Cboot version 00.01.0000 [ 2.6234 ] Writing partition APP with /home/dusty/workspace/JetPack-L4T-2.0/Linux_for_Tegra_tx1/bootloader/my_backup_jetpack_231_APP.img [ 2.6241 ] [................................................] 100% [ 823.6449 ]
Is there any faster (and more efficient) way to Backup & Restore? This way I always have to move ~15Gb of data to Backup and Restore whether I just used a fraction of that with my current TX1 configuration…
My suggestion is clone once. After that, loopback mount the clone on the host, and use standard rsync commands (or your favorite Linux backup software) and do an incremental update to the loopback mounted system. If critical, I’d recommend saving one clone without modification and updating to a copy of the clone.
The advice above was very helpful. I’ve been using the commands to download and upload images amongst my TX1 boards. I’ve also been able to share my images with a colleague and he’s able to upload to his TX1 as well.
The problem we’re seeing though is that if he creates an image file, I can’t upload it to my board. The upload fails with the message, “00000004: Filesize is bigger than partition size”. We’ve checked the partition sizes on our TX1 boards using df and they seem identical.
We’ve also used md5sum on the image to confirm there’s been no corruption during transmission from his machine to mine.
We’ve also checked the upload and download commands and they are nearly identical. The only small difference we’ve noticed is that on my Ubuntu machine, the cboot.bin file is in my …/JetPack/TX1/Linux_for_Tegra_tx1/bootloader directory while on his machine it’s in a subdirectory called t210ref. Running md5sum on the cboot.bin files shows they’re identical between our machines. We haven’t noticed any other differences although I suspect perhaps our JetPack versions are different or something like that.
There are many partitions in a Jetson, the root file system is just the obvious one. When flashing I choose the maximum size for rootfs, option “-S 14580MiB”. If you flashed another Jetson with a different size, then the partitions making up the more invisible part of the install would be unlikely to remain constant. Make sure the image itself, as a file, is the same exact size…the size seen from “df” of a running Jetson does not describe other details of the underlying file system, nor its offset for starting within the eMMC as a whole.
Note that the “bootloader/cboot.bin” is a NULL-padded copy of the reference boot loader…other than some trailing NULL bytes, they are the same. Normally I would not expect a boot loader image without proper NULL-byte padding would get through, but if it did then the difference in partition sizes might be accounted for by this…offsets of starting point of other partitions following this may shift.
I can’t say for sure, but if you are using a Jetson with the trailing NULL bytes in the boot image to create a rootfs image, then the Jetson failing to be able to flash would possibly be able to flash that partition if it were flashed again using the same parameters as the one from which the image was created. The goal being to get the boot image and all partition sizes below the rootfs to match, and then try to append the rootfs.
Ok, thanks for the advice. I’ve tried to use “-S 14580MiB” but it doesn’t seem to be an option for tegraflash.py. So I tried inserting it like this:
sudo ./tegraflash.py --bl cboot.bin --applet nvtboot_recovery.bin --chip 0x21 -S 14580MiB --cmd “write APP my_image.img”
…and like this:
sudo ./tegraflash.py --bl cboot.bin --applet nvtboot_recovery.bin --chip 0x21 --cmd “write -S 14580MiB APP my_image.img”
…but neither worked. Sorry for being helpless and possibly pedantic but could you provide the exact command?
It sounds like you two are using different versions of Jetpack or L4T. It is recommended to use the same L4T to clone and restore the image. Try downloading the same version as your colleague. You can use Jetpack or technically L4T directly for this:
(see archive: https://developer.nvidia.com/embedded/linux-tegra-archive)
If your issue persists, before restoring the cloned image try freshly flashing your Jetson with the same stock Jetpack/L4T as your colleague. This will get the partitions all set up the same.
In addition to making sure you use the same L4T release version, I would also suggest using the “flash.sh” front-end, do not use the tegraflash.py script directly for the step where you are trying to make your two Jetsons have the same compatible environment. Here are some typical examples:
sudo flash.sh -S 14580MiB jetson-tx1 mmcblk0p1 <s># sudo flash.sh -R -S 14580MiB jetson-tx1 mmcblk0p1</s> sudo flash.sh -r -S 14580MiB jetson-tx1 mmcblk0p1
Note that the latter case re-uses “bootloader/system.img”, and if a clone file is there in place, that installs the clone. I also doubt the “re-use” option needs the “-S 14580MiB”, but I’m a bit lazy and didn’t want to flash a Jetson to find out…I know using “-S 14580MiB” does work. Using the front-end should do the right thing relative to any boot loader reference getting padded as needed.
Thanks very much for the responses above. I’ve found that if I simply truncate the image by a few K it uploads successfully. I attempted to follow the instructions linked below and chop about 4G from the image but that didn’t work but I found that chopping just a few K off the end with the “truncate --size=15032385536 myImage.img” command did.
I’m sure this is quite a questionable way to resolve the problem but it seems to have worked at least in my specific case.
Like Randy I’m trying to clone an image to a TX1.
Specifically one of his from arducopter.org to prove the TX1 as a companion computer to a Pixhawk on the Auvidea J100 carrier board. Randy appears to be using the J120 board at present.
When I follow:
sudo flash.sh -R jetson-tx1 mmcblk0p1 (The lack of -S appeared to make little difference as you suspected.)
with the required image in the bootloader/system.img as suggested.
The command reports a lack of a rootfs and after providing rootfs (from …/rootfs)
sudo flash.sh -R rootfs jetson-tx1 mmcblk0p1
The command rebuilds system.img instead of using the clone file.
(I also tried using tegraflash.py which appeared to hang at the image write stage.)
Any help greatly appreciated.
How far into the upload did it freeze?
You can, try again - see if it gets farther. Remove USB hubs. Try a shorter USB cord between the PC and TX1.
If you’re flashing from within a VM, try a live CD or native install of Ubuntu 14.04. Or with the module on the devkit.
My fault, sometimes I answer questions away from my development environment and can’t check things, it’s all from memory (known as a bug in wetware…a.k.a., the brain). The uppercase “-R” is not for re-using a clone as the root partition…this simply points to a sample rootfs directory with a non-default location. To flash a cloned image, use “-r” lowercase instead. The missing or bad rootfs is because there is no sub-directory “jetson-tx1”.
One prerequisite of reusing a cloned partition is that the device was originally partitioned with the same exact rootfs partition size. If one Jetson is flashed with size “-S 14580MiB” and the other is flashed with either default size or “-S 14GiB”, then it might not work right. Cloned partitions can be resized with some effort, but it’s just easier to flash with the same “-S” and then clone in the backup image.
Thanks for the replies.
As predicted the -r option re-uses the image, however the process freezes as shown in this tail of the install log
[ 2.3888 ] Flashing the device
[ 2.3920 ] tegradevflash --pt flash.bin --storageinfo storage_info.bin --create
[ 2.3948 ] Cboot version 00.01.0000
[ 3.1647 ] Writing partition GPT with gpt.bin
[ 3.1655 ] […] 100%
[ 3.1717 ] Writing partition NVC with nvtboot.bin.encrypt
[ 3.4393 ] […] 100%
[ 3.4739 ] Writing partition APP with system.img
[ 3.5084 ] [ ] 000%
(Full log on request if you wish to see it.)
I waited about 30 minutes for some progress but nothing occured.
The write is from an x86_64 laptop running Ubuntu 14.04.
I am not using any VM type software.
The connection to the Jetson is direct by a single short cable to the micro USB
and lsusb reveals:
Bus 002 Device 016: ID 0955:7221
I tried the upload a couple of times to be sure and apart from having to put the Jetson bcak into recovery each time the results were the same.
The image I used this time was: tx1_backup_v0.10.img.tar.gz 2016-06-28 04:44 5.1G
However I got the same result using the default system.img on Friday.
Any guidance would be most appreciated particularly as the Jetson now doesn’t boot up in normal mode so I’m off to try a rebuild using the standard Jetpack approach.
An update to the previous post.
I tried an upload with the original system.img from the bootloader directory and this is the result:
Command ran as before and got to:
[ 5.4464 ] Writing partition APP with system.img
[ 48.6574 ] [ ] 000%
Error: Return value: 1
Command tegradevflash --pt flash.bin --storageinfo storage_info.bin --create
Failed flashing t210ref,
Does that help?
So now I am off to try a standard Jetpack install.
And here is the result of the Jetpack install attempt:
[ 24.6843 ] tegrarcm --download bct P2180_A00_LP4_DSC_204Mhz.bct
[ 24.6861 ] Applet version 00.01.0000
[ 24.8338 ] Sending bct
[ 24.8341 ] […] 100%
[ 24.9972 ]
[ 24.9973 ] Sending bootloader and pre-requisite binaries
[ 25.0007 ] tegrarcm --download ebt cboot.bin 0 0 --download rp1 tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb 0
[ 25.0021 ] Applet version 00.01.0000
[ 25.1502 ] Sending ebt
[ 26.3292 ]
Error: Return value 1
Command tegrarcm --download ebt cboot.bin 0 0 --download rp1 tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb 0
Failed flashing t210ref.
Oh dear. Now I am stuck.
A few more failed attempts later I have a work around which gets the Jetpack standard OS to flash.
Using a system.img in the bootloader directory from a previously failed Jetpack install, this command:
sudo ./flash.sh -r jetson-tx1 mmcblk0p1
with a very short i.e. 10 cm Usb cable gave a sucessful flash:
[ 240.1044 ] Writing partition RP1 with tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
[ 240.1180 ] […] 100%
[ 240.1513 ] Writing partition TOS with tos.img.encrypt
[ 240.1682 ] […] 100%
[ 240.1827 ] Writing partition DTB with tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
[ 240.1972 ] […] 100%
[ 240.2480 ]
[ 240.2513 ] tegradevflash --write BCT P2180_A00_LP4_DSC_204Mhz.bct
[ 240.2547 ] Cboot version 00.01.0000
[ 240.3559 ] Writing partition BCT with P2180_A00_LP4_DSC_204Mhz.bct
[ 240.3579 ] […] 100%
[ 240.4567 ]
[ 240.4568 ] Flashing completed
[ 240.4568 ] Coldbooting the device
[ 240.4587 ] tegradevflash --reboot coldboot
[ 240.4615 ] Cboot version 00.01.0000
[ 240.5657 ]
*** The target t210ref has been flashed successfully. ***
Reset the board to boot from internal eMMC.
After the subsequent reset the TX1 booted up to the Ubuntu GUI sucessfully.
Flushed with overconfidence I’ll try the same approach with the Arducopter image.