Cloning Jetson Tx2

I try to clone Jetson Tx2, and referred
But in one of the forum post here, it is mentioned that cloning works only on rootfs.
Will it take care of dtb also get cloned? or I need to flash DTB again?

I created the cloned .raw image, by putting Jetson in recovery mode.
But after completing cloning, the Jetson is stuck “[0032.018] I> Reading APP partition.” and not booting completly. Do that need a hard reset?

Beware that different release versions may have different clone instructions (you may need to specify your release, e.g., see “head -n 1 /etc/nv_tegra_release” or “dpkg -l | grep 'nvidia-l4t-core'” on more recent releases ). Clones need a bit of explanation, it is not always simple…

The non-rootfs content is used for boot. Often there will be an indirect dependency between the non-rootfs content and the rest of the content (earlier boot stages may work with device tree content and edit that content before passing on to later boot stages or the Linux kernel). A cross between the non-rootfs content of one release and the rootfs of a different release (except for minor patches) will often cause failure to boot. Make sure the software you flash with via the clone is the same release which flashed the Jetson originally containing the clone.

The “normal” advise is to clone a rootfs, and then “reuse” that clone while flashing a new Jetson. So long as nothing was custom in the non-rootfs content, and so long as the clone and the release being flashed match, this should always work and the result will be what you expect. This guarantees that the non-rootfs content is valid, not only in content, but also that the signing of the content works for that Jetson. Valid content with invalid signing is rejected in more recent releases.

Sometimes people flash just a device tree, or just a kernel, so on (which is less likely to succeed unless everything else is correct). If everything else does not match, then boot will also fail. Do you have device tree customization? Are you using the dev kit carrier board? Did you flash everything, except use “-r” option to reuse the “bootloader/system.img” (which would have been your clone)? Or did you just replace the rootfs/APP partition?

Kindly find the reply inline… Sorry that not sure how reply/attach your reply here.
see “ head -n 1 /etc/nv_tegra_release ” or “ dpkg -l | grep 'nvidia-l4t-core'

   nvidia-l4t-core 32.3.1-20191209230245

Make sure the software you flash with via the clone is the same release which flashed the Jetson originally containing the clone.

This means if R32.3.2 is cloned that should be flashed to another Jetson having same R32.3.2. is my understanding correct?
Also, I created clone from a Jetson A and try to reflash it. But after creating clone image, the Jetson-A is stuck in booting. Just cloned, not yet actually flashed. Does the Jetson needs hard reboot? or power recycle?

. Do you have device tree customization?

YES, I have device tree customization.

Are you using the dev kit carrier board?

Yes I have Jetson TX2 dev kit carrier P3310-c03

Did you flash everything, except use “ -r ” option to reuse the “ bootloader/system.img ” (which would have been your clone)? Or did you just replace the rootfs/APP partition?

I have NOT yet flashed.
I just created the clone.img and clone.img.raw, for that I put the board in recovery mode.
I hope during clone.img creation, is just reading the board, not writing (is my understanding correct?)
After creating those files, the board is stuck at the log I specified. I thought of flashing this system.img (raw) to the board, just to validate the cloning process. I have only one Jetson board now. So all the tasks I am doing in that.


This is correct:

Cloning a Jetson will never modify the Jetson. There should never be any change between a Jetson which was cloned and one which was not cloned. Recovery mode though is not a normally running system, and any time you do anything in recovery mode you generally perform a reboot before doing something else. As an example, after you clone you must reset power to get the Jetson to boot normally. If you were to clone twice in a row, then you would have to reenter recovery mode between clones. If you were to clone and then flash, then you would need to reenter recovery mode between clone and flash.

It is best for the customization to be placed in the dtb content of the flash software, and then, other than “-r” to reuse the system.img to restore or create a similar duplicate Jetson (where system.img is now your clone), flash normally. This would put both the clone and the device tree in place, with the device tree being properly signed (which is mandatory in R32.3.1).

This is correct. Recovery mode never modifies the Jetson (although flash software can modify the Jetson in recovery mode, the mode itself does not edit anything). You just need to power cycle to reboot after the clone is done.

If you are certain you have a safe copy of the your raw clone image (or even the sparse image, but sparse images cannot be edited or modified or examined) in a safe location, then you can put a copy in “Linux_for_Tegra/bootloader/system.img” and flash on command line with the “-r” option to put everything in. If you have also optionally replaced the .dtb file which has your edits, then your edits will also be put in place. It would take more time, but you could create a log of this flash to see where each device tree file comes from, and then flash again once you’ve edited the correct tree:
sudo ./ jetson-tx2 mmcblk0p1 2>&1 | tee log_flash.txt

There are other, longer methods of making edits of the device tree in kernel source and building those files again, but if you examine this, you’ll find the default versions anyway, in binary format:
find /where/ever/it/is/Linux_for_Tegra/bootloader -name '*.dtb'
find /where/ever/it/is/Linux_for_Tegra/kernel -name '*.dtb'

You can reverse compile any of these, edit, and put this back in place (be sure to save an original). During flash the content will be installed from these after signing.

@jk.t are you trying to clone to re-use at the same device or at another device? In the former case, dd dump will do, in my opinion.