How to backup TX2

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

I’m looking at editing some kernel code and rebuild it to solve several USB issues I have with regards to Intel RealSense R200 camera, RPLidar and Zed Cameras, including adding the ACM module onto my TX2.

However, reading threads here and articles on eLinux are quite ambiguous as some steps are missing. I cant make the link between entering Force Recovery Mode from [url]http://developer2.download.nvidia.com/embedded/L4T/r27_Release_v1.0/Docs/Jetson_X2_Developer_Kit_User_Guide.pdf?7mKmfPMrI_2WG3oa8t1CUTtXzCb9Q6tILK0PQ7-maPbdrWLEXDmS7J7L3WGwLmYvQvwFhBflgfG92cT711SXhQFKpreWfiIwzKV9eXdp7ybs0EOy0kSd1UHytR_lJV2235Bdd_xUGPBfQ1UGUR32iAmSlCAC_oETU2Lu8STI5wI7-rm9zDX8Ng[/url] ( I have no way of knowing if I did it right) and the first instructions [url]https://elinux.org/Jetson/TX2_Cloning[/url] How do i find this “L4T” directory and cd into it?

I am looking to backup my current setup before attempting any new kernel builds

2

Hi ryanz2v0a, you should have a JetPack or L4T install on your host PC from when you last flashed the device. JetPack creates a folder on the host called 64_TX2/Linux_for_Tegra, the flash.sh script is located here.

If you don’t have the JetPack-L4T on the host from previous flashing, download the version of L4T corresponding to what’s currently on your Jetson and extract it, the flash.sh script will be there. You can run this command from your Jetson to tell the L4T version it currently has installed:

$ cat /etc/nv_tegra_release
3

Would it solve the Intel RealSense and Zed camera issues? I haven’t found conclusive solutions yet and wondering what the state of development or fix is. I have solved the RPLidar issue with the AMC mod installed

4

I’m not sure about the RealSense issue, have you contacted Stereolabs support about the ZED issue? They should be able to say about which JetPack or kernel config to use. The rpLIDAR driver I’m familiar with because I use those too!

p.s. even with cloning, I recommend you manually back up your source code / config files before flashing just to be careful.

5

How to backup the whole emmc not only mmcblk0p1?

I use

sudo ./flash.sh -S 14000MiB jetson-tx2 mmcblk0p1

to part the emmc into two disks, the other is mmcblk0p29, I install some big complex files in the mmcblk0p29, so I want backup the whole emmc datas, not only mmcblk0p1 as well as mmcblk0p29.

Jetson/TX2 Cloning - eLinux.org just point out how to backup mmcblk0p1.
Is there any ways to clone the whole emmc?

6

You could create a bootable SD card and then use dd. If networking is up you can use dd to read from the TX2 and write to a PC host. On the other hand, I’m not sure how you would use a “whole” image to do a restore. Unless you are doing something custom (e.g., some sort of secure boot), then only mmcblk0p1 will matter.

Here’s a URL to someone doing this:
https://unix.stackexchange.com/questions/132797/how-to-dd-a-remote-disk-using-ssh-on-local-machine-and-save-to-a-local-disk

Just FYI, if you have SSH keys instead of passwords, then this is trivial. What I do on my embedded systems is to set a password for root, unlock root, do the ssh-copy-id from my host to root@the_remote_address, and then re-lock root. After this a command such as this from my host PC has no password requirement and “just works”:

ssh root@the_remote_address "dd if=/dev/mmcblk0 | gzip -3 -" | dd of=backup_of_mmcblk0.img.gz

FYI, if you have a bootable SD card, then you could in theory restore this by this method as well.

Just to point out something subtle, a mounted file system is a moving target. Any clone of a mounted file system is bound to fail…usually when trying to restore in panic mode. This is one reason to first boot to a rescue SD card.

A second reason is that you are interested in what is on the partition, and if there is something mounted on a subdirectory of the partition, then rsync and anything using the file system itself (instead of the raw partition) will only see the top-most mount files. As an example, if there are device special files in “/dev/” of the partition, and then udev mounts something on “/dev/”, then rsync will fail to find what was on the eMMC. Rsync is usually told to not cross partition boundaries, so you wouldn’t even get the mounted “/dev/” files. If rsync were told to allow crossing boundaries, then you would still get the wrong files…you’d end up with what udev added, and you would miss everything on the actual eMMC which the “/dev” mount has hidden from view.

The root partition is the only one which is actually mounted once boot is complete. You could experiment with and copy other individual partitions without an SD card rescue.

7

Hi linuxdev,
I had used

ssh root@the_remote_address "dd if=/dev/mmcblk0 | gzip -3 -" | dd of=backup_of_mmcblk0.img.gz

to backup the image, but when I use

sudo ./flash.sh -r jetson-tx2 mmcblk0p1

, to flash to tx2 board, the TX2 can’t boot.

When I try using the below cmd

sudo ./flash.sh -r jetson-tx2 mmcblk0

, this commander can’t work as well, so how can I flash the backup image to the tx2 board?

8

The “backup_of_mmcblk0.img.gz” would have to be decompressed first…“gunzip backup_of_mmcblk0.img.gz”.

If this is a backup of the entire eMMC, then you can’t use the “-r” option to flash it…you would need to extract just mmcblk0p1 from this (“system.img” is just the rootfs, not the entire eMMC). It is possible to extract individual partitions from an image of the entire eMMC, especially if you have the partition table (then it just becomes a matter of using dd to extract from start offset to end offset of partition 1). Was this the entire eMMC and not just the rootfs partition? If so, then you have work ahead of you.

Assuming this is actually mmcblk0p1 (rootfs), then it would have to be renamed as “system.img”, and placed in the “Linux_for_Tegra/bootloader/” directory prior to flash with the “-r” option (be very careful to not overwrite your only backup copy…if you leave out “-r” you’ll overwrite that copy).

Assuming this is actually mmcblk0p1 (rootfs), what is the exact byte size of the image after it is decompressed? Use “ls -l backup_of_mmcblk0.img”.

Another issue is that a rootfs clone image is designed to work with the same release that is flashed (there are other partitions beyond rootfs…these are designed to work ). So for example you cannot clone R28.1 and expect it to work with R28.2.1 (some parts might work). Having the clone makes it easy to rsync large parts of this, but some of the system specific files must match the release version.

Was the image decompressed and in the “bootloader/” subdirectory? Or is this an image of the entire eMMC?

9

I used this cmd to get the image

ssh root@the_remote_address "dd if=/dev/mmcblk0 | gzip -3 -" | dd of=backup_of_mmcblk0.img.gz

so the this an image of entire eMMC. After decompressed backup_of_mmcblk0.img.gz , the size is 31.3GB. Yes I placed the image in “bootloader/” subdirectory.
I tried to use the to flash the image, but it returned an error, the image size is larger than actual size.

sudo ./flash.sh -r jetson-tx2 mmcblk0p1

So I use the

sudo ./flash.sh  jetson-tx2 mmcblk0p1

to flash the tx2, but the project created an new system.img(3.3GB).

10

Using the entire eMMC image in “bootloader/system.img” is not valid. “system.img” should represent only the rootfs partition, and not the entire eMMC. If you have saved the entire disk you will need to extract the rootfs from this if restore is to be via flash.sh.

So far as I know, the flash tool does not have a means of restoring the entire eMMC from a single contiguous image. You would have to boot on a rescue disk (e.g., USB SATA or SD card), and then use “dd” in what is essentially the reverse of what you did to save the entire eMMC as a single image. In the event that you cannot get a rescue SD card or similar working, then you can extract the part of the full eMMC which is just the rootfs (this part would be compatible with using flash.sh to restore).