I want to create a diskdump as a backup of the emmc of a xavier-nx. Usually I do it at other systems by booting from a plugged live-linux-usb-device and do the diskdump while the partition is unmounted. At the xavier nx this is not possible. Is there another way to create a diskdump of the eMMC partition ? Thanks :-)
I recommend the rootfs/APP partition be dumped via flash software cloning. This means you wouldn’t get files changing in the middle of operation. You could also use ordinary “rsync” backups with a destination over ssh or to a local USB storage.
There are ways to use clone software to also clone individual partitions, but I’m not sure how functional that is since most people only clone the rootfs.
On a running system one can also use dd to clone other partitions (ones which are not changing while cloning, e.g., everything except the rootfs). An example, if you have a USB thumb drive which has partition “/dev/sda1” mounted on “/mnt”, cloning mmcblk0p2:
sudo dd if=/dev/mmcblk0p2 of=/mnt/p2.img bs=10M
The “bs=10M” is just for performance reasons. It won’t change the output.
It is also possible to dd through ssh to another computer. Let’s say for example that your host PC has IP address 192.168.55.100 and your user name is “nvidia”. Also, your host PC has sufficient space, and you want to image to nvidia account’s “~/Downloads” directory. On the Jetson:
sudo dd if=/dev/mmcblk0p2 | ssh nvidia@192.168.55.100 dd of=~/Downloads/p2.img
Note that binary partition clones of non-rootfs might not always be useful. Every partition (other than rootfs) has a signature added prior to flashing. On Jetsons without the security fuse burned this is just a NULL signature, but it is still there. You might run into signature issues if you are adding partitions to different Jetsons. Those partitions are normally not needed other than as stock, but if you are customizing, then try cloning and restoring before you depend on it.
Thanks for the answer and the suggestions.
I have found this:
https://docs.nvidia.com/jetson/archives/r34.1/DeveloperGuide/text/SD/FlashingSupport.html#to-clone-a-jetson-device-and-flash
The command is "sudo ./flash.sh -r -k APP -G <clone> <board> mmcblk0p1"
[linuxdev]>> I recommend the rootfs/APP partition be dumped via flash software cloning.
You are talking about the script flash.sh when you suggesting “flash software” ?
This looks quite good. I just have to find out what is the correct value for <board> ,
maybe “jetson-xavier-nx-devkit” but its not a native devkit, but a 3rd party from everfocus with xavier nx
In the “Linux_for_Tegra/” directory look at all of the “*.conf” files. Many of these are just symbolic links, but alias a more common name. These are target boards if you remove the “.conf” on the file name. For example, if you see “jetson-xavier-nx-devkit-emmc.conf”, then that would be board “jetson-xavier-nx-devkit-emmc”. Similar for “jetson-xavier-nx-devkit-qspi” (SD card models use QSPI memory for boot instead of eMMC). If this is an eMMC card model NX dev kit (uses QSPI):
sudo ./flash.sh -r -k APP -G <clone> jetson-xavier-devkit-emmc mmcblk0p1
Looking at where each symbolic link points you might find more than one acceptable flash board name for a given board. Keep in mind that you don’t need the flash tools to clone the rootfs (APP) of an SD card model…just clone directly with dd on a host PC when the partition is not mounted.
Incidentally, when reading a clone it tends to not matter which carrier board is used. So long as the board can be put into recovery mode and detected on the host PC the carrier board won’t play much of a part. However, if you want to flash the clone to a new board, then this matters a lot since rootfs and non-rootfs content must be compatible during normal boot. Should you happen to know that all software in non-rootfs partitions is correct to use with a clone, then flashing just the rootfs (and leaving other partitions alone) should work fine regardless of whether the carrier board is somewhat different. However, if you wish to use a clone on a new Jetson module on a custom carrier board, then you must be certain that the non-rootfs content is correct.
Do take a look at the “.conf” files. You could create a custom version of this for your particular case, but if this is a third party carrier board, then that manufacturer probably provides a board support package which is almost the same as the dev kit flash software, although with a different .conf file. If that carrier happens to be an exact match to the dev kit layout, then you could just use the NVIDIA software without a third party BSP.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.