TX2 Cloning

Excellent information guys. The cloning process can save a lot of headache for developers who wish to take a complete backup of the TX2. Thanks.

It seems -k ALL doesn’t work - prints “ALL not supported”. I am currently using Jetpack3.0, but I am going to upgrade now. Is it fixed there? I use orbitty board with custom BSD (so USB3 would work and also changes so ttyTHS2 would show) and none of these changes get copied with APP. So I need total cloning. Any ideas?

You can name each individual partition and clone one at a time, but I’m not sure how to read the partition table (and this would tell you what partition names are for the clone app).

Does anyone know if there is an option to clone the partition table? If not, is this something we can get? It would also be a good addition to add the “ALL” target to copy the entire eMMC in one shot the way it could be done with a TK1.

@linuxdev,

parted -ms /dev/mmcblk0 print
1:17.4kB:15.0GB:15.0GB:ext4:APP:msftdata;
2:15.0GB:15.0GB:2097kB::TBC:msftdata;
3:15.0GB:15.0GB:4194kB::EBT:msftdata;
4:15.0GB:15.0GB:2097kB::BPF:msftdata;
5:15.0GB:15.0GB:6291kB::WB0:msftdata;
6:15.0GB:15.1GB:4194kB::RP1:msftdata;
7:15.1GB:15.1GB:6291kB::TOS:msftdata;
8:15.1GB:15.1GB:2097kB::EKS:msftdata;
9:15.1GB:15.1GB:2097kB::FX:msftdata;
10:15.1GB:15.1GB:21.0MB::SOS:msftdata;
11:15.1GB:15.1GB:67.1MB::EXI:msftdata;
12:15.1GB:15.2GB:67.1MB::LNX:msftdata;
13:15.2GB:15.2GB:4194kB::DTB:msftdata;
14:15.2GB:15.2GB:2097kB::NXT:msftdata;
15:15.2GB:15.2GB:6291kB::MXB:msftdata;
16:15.2GB:15.2GB:6291kB::MXP:msftdata;
17:15.2GB:15.2GB:2097kB::USP:msftdata;
18:15.2GB:15.8GB:520MB::UDA:msftdata;

Hello,

how is a back up and restore is accomplished when the development is by utilizing the eMMC while in production we move to SD-Card?

Please advise on the procedure? is the eMMC utilized any way? or is there some hybrid utilization?

Thanks,

Igal

Except for the rootfs partition eMMC is always used. There are many “hidden” partitions on eMMC.

Case 1: A “normal” flash looks for the extlinux.conf file for final boot configuration on the rootfs partition of the eMMC. extlinux.conf is on eMMC in the eMMC “/boot”.

Case 2: A “normal” flash is edited and extlinux.conf of eMMC is the only edit. You can then rename the “root=/dev/whatever” to point at a different rootfs source. The “/boot” of eMMC continues to be used, but all files outside of “/boot” go to the new device. Example: “root=/dev/mmcblk0p1” is eMMC rootfs, “root=/dev/mmcblk1p1” is SD card rootfs. In both cases this is first partition…I believe other partitions are not supported.

Case 3: The flash.sh script no longer names “mmcblk0p1”, instead SD card “mmcblk1p1” is named. This would cause the boot loader to look for extlinux.conf (and thus all of “/boot”) on the SD card. Normally this command puts mmcblk1p1 as the device in the SD card’s extlinux.conf, but you could edit the SD card version of extlinux.conf for this case and send rootfs back to eMMC by changing it to “root=/dev/mmcblk0p1”…in this case the “/boot” of eMMC would be ignored and only the SD card “/boot” would be used.

Flash option (“flash.sh” command line) controls which “/boot” is used; the used “/boot” extlinux.conf determines where the rest of rootfs is from. In all cases eMMC has supporting hidden partitions. If both SD card and eMMC boots use the same L4T release version, then the two are interchangeable just by changing the extlinux.conf of the valid “/boot” to the “root=” of the target root partition. It is not possible to reliably mix hidden partitions of one L4T release version with a rootfs not designed for that release version…you could experiment and maybe it will work, but boot loader differences probably imply such a mix will fail.

NOTE: It is nice to have eMMC even if you are booting purely to SD card…it makes a nice rescue system.

linuxdev, thanks for the thorough reply.

You are correct that it is nice to have an eMMC for recovery but for production it is much easier (and quicker) to prepare SD cards independently and then provide them to each produced system.

Igal

1 Like

@ linuxdev, i’ve a simple idea that when i boot from SD card, i could use dd to clone the whole emmc disk. and im trying now…

dd does work if not running off the eMMC (it’s hard to dd an image from a file system while it changes). If you were to flash the Jetson and not boot it after the flash (or boot it in such a way that the eMMC rootfs is never touched…the simple act of mounting a journaling file system changes the metadata), and then do both clone and dd of the rootfs, you would find that the dd is an exact match (e.g., via sha1sum) to the “bootloader/system.img.raw” file and the clone.

A flash changes more than just the rootfs partition though…this is why flash is somewhat different than dd. Clone might be considered putting the system into a specialized rescue mode and using dd through the USB cable (notice that whenever the flash software is used it loads a fastboot image even though installation uses U-Boot…there is a very primitive operating system running in rescue mode once fastboot loads).

[ 11.5482 ] Reading partition
[ 11.8030 ] tegradevflash_v2 --read APP /home/evrendaglarli/Downloads/64_TX2/Linux_for_Tegra_tx2/system.img
[ 11.8041 ] Bootloader version 01.00.0000
[ 12.1560 ] File Write failed… ] 049%
[ 2943.7738 ]
Error: Return value 10
Command tegradevflash_v2 --read APP /home/evrendaglarli/Downloads/64_TX2/Linux_for_Tegra_tx2/system.img
*** The :APP has been read successfully. ***
Converting RAW image to Sparse image…

---- Raw to Sparse Image Converter v1.0 ----------------------------
0: RAW: 4276224( 1044 blks) ==> 28:4276236
1: SKP: 53248( 13 blks) ==> 4276264:12
2: RAW: 3555328( 868 blks) ==> 4276276:3555340
3: SKP: 638976( 156 blks) ==> 7831616:12
4: RAW: 12288( 3 blks) ==> 7831628:12300
5: SKP: 29347840( 7165 blks) ==> 7843928:12
6: RAW: 11223040( 2740 blks) ==> 7843940:11223052
7: SKP: 85110784( 20779 blks) ==> 19066992:12
8: RAW: 12288( 3 blks) ==> 19067004:12300
9: SKP: 4186112( 1022 blks) ==> 19079304:12
10: RAW: 733184( 179 blks) ==> 19079316:733196
11: SKP: 667648( 163 blks) ==> 19812512:12
12: RAW: 86016( 21 blks) ==> 19812524:86028
13: SKP: 24576( 6 blks) ==> 19898552:12
write raw data fail - Success

I am receiving the above message. What does it mean ? is the cloning progress unsuccessful or not ?

This failed. Are you using a VM? These have flaws in the USB.

I presumed that. I got it. Thanks …

There may be some tips on using a VM which would help you. Check this out:
https://devtalk.nvidia.com/default/topic/1002081/jetson-tx2/jetpack-3-0-install-with-a-vm/

hi, I have a question, if I made an application based on jetson tx2, is that mean anybody could copy or change my application by clone APP partition, how could I resolve this problem ?

I think clone or copy would be possible on any system, regardless of whether it is a Jetson or desktop PC. It’s the nature of mass storage…if you have a file, then the file can be retrieved if there is physical access (and often with remote access).

One method of dealing with this would be an encrypted file system. Then the persistent storage memory could not be copied unencrypted unless the system is running…during recovery mode for clone encryption would make the data useless. However, there are all kinds of weaknesses with this since you won’t have physical security and control. For example, an encrypted file system requires a key to mount (or password). How you would provide this such that the key itself could not be copied and used is an issue.

You’ll see topics about preventing a system from being modified, e.g., secure boot. It’s a very broad topic. You’ll see some hardware vendors use “dongles” which must be in place for the program to run, and it is the dongle from which license keys are distributed. You’ll see “sandbox” environments to resist tampering with the environment. You might see heap randomization if you are worried about buffer overflow attacks.

Much depends on detailed knowledge/nature of what parts of your program need to be protected, e.g., data, executable code, so on…answers would be difficult even if you gave more detail, but without detail on exactly what kind of protection you need I don’t think there is a possibility of constructive suggestions. Secondarily it needs to be stated what kind of attacker you expect…the skill set.

I used these instructions in the hope of cloning one TX2 to another TX2. I’m am using R28.1. I was able to create an system.img using the updated flash.sh with the -G option. Then I used corresponding .raw image to update the second TX2. I am able to ssh to the second TX2 after the reflash, however it does NOT look like any of the nvidia drivers are installed (lspci returns nothing) and there is no activity on the monitor. Not sure what I’m missing. Below are the steps I used from my Host PC.

sudo ./flash.sh -r -k APP -G my_backup.img jetson-tx2 mmcblk0p1

Put second TX2 into recovery mode, and swap USB cable from first TX2
Rename my_backup.img.raw to bootloader/system.img before flashing

mv my_backup.img.raw bootloader/system.img

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

ideas?
-Rich

There is a script for installing nvidia specific stuff:

sudo ./apply_binaries.sh

Then flash again.
You may check: https://devtalk.nvidia.com/default/topic/1009158/jetson-tx2/cloning-or-taking-snapshot-of-tx2-board/post/5149602/#5149602

Note 1: lspci only shows something if there is something connected to the PCIe bus.
Note 2: Drivers can be validated via “sha1sum -c /etc/nv_tegra_release”.

I think the problem is actually with the monitor. If the monitor is plugged in during reboot, then I do not see any activity on the screen. Simply unplugging the hdmi connector and reinserting it, after reboot, resolves the problem. I did not have this issue with Jetpack 3.0. It’s an older monitor with DVI input, I use a HDMI->DVI cable.

Some DVI adapters do not pass through the “DDC” wire. This wire sends “EDID” data when queried by the video card, and without this wire the monitor would be equivalent to an older 15-pin D-sub VGA connector. Without this wire the video software cannot determine what the monitor capabilities are and auto configuration is guaranteed to fail…I don’t know if your cable passes this through or not. Regardless, it is possible to get lucky and have the default mode the video card uses happen to be something the monitor supports. The first thing to do is to see if the monitor has EDID data passed through. To do this see if you can find file “edid” in “/sys”:

sudo find /sys -name edid

If the file is missing, then you know your HDMI-DVI adapater is missing this wire (the file will be there if the right driver is present). If the file is there, then you still need to see if it has actual content (a side effect of the actual i2c query of EDID data):

sudo -s
cat `find /sys -name edid`
exit

If you have the hexadecimal values, then the final test would be to paste them into http://www.edidreader.com and see if the checksum is valid.

If this is in place with a valid checksum, then you know auto configuration is available and that the monitor provides valid data.

HDMI itself is hot-plug. This means it is possible for the connector to inform the video card of a plugin or unplug event. When this happens the video card sends a query to the DDC wire to see what monitor spec it is talking to. Different stages of boot may use different queries of EDID via different software, and may also have different ideas of what is valid or not, e.g., consoles use only certain framebuffer resolutions and software, whereas X11 uses various graphical modes via different software. In theory there would be an intersection of values valid for console and values valid for GUI. This is not always the case, and it is possible for one to work, but not the other.

There may also be bugs which are resolved by unplugging and replugging since this event can construct a new instance of the driver environment. Consider that if there was an old mode running and you plug in a new monitor, and if the hot-plug software does not detect this, then old mode will be preserved…but in some cases where a new monitor is plugged in and the system knows this, then there may still be values set up in hardware which the new plugin does not set up (this would be a bug)…these too would be preserved unless the hardware is rebooted. This is something which might be debugged with output from “dmesg --follow” during boot with and without the monitor, and from manual plugin and unplug.

You can also add this to Section “Device” of /etc/X11/xorg.conf to get the driver to tell you what it thinks of each mode the monitor claims it can work with:

Option   "ModeDebug"

Normally “/var/log/Xorg.0.log” does not tell you anything about rejected modes, but with this option in place the log will tell you why it rejects any mode…perhaps EDID works, but all modes were rejected. This is how you understand why otherwise valid modes are or are not rejected.