-
Correct, TK1 was not signed. Technically you could copy the signed partition of other releases, but the content would be useless for restoring to a different Jetson.
-
Correct in the sense that there is no way to perform a useful clone of the non-rootfs partitions. Note though that all of those non-rootfs partitions are part of boot, and yet ignored after boot loads the Linux kernel. Although I phrased that those “other” partitions are used because of a lack of a BIOS, they are intermingled in function and none are specifically a “BIOS”. The “gdisk -l” could show binary partitions, but even PC boot uses more than individual partitions (a PC boot disk will have content not visible as a partition, and may use other partitions during boot, but partitions do not contain everything used for PC boot). Either way, other than customization of boot properties, the rootfs will contain the entire operating system. The only part which is “normally” modified by end users would be the kernel or device tree.
If kernel and device tree are combined into the flash software (the “driver package”) on the PC, then any flash will contain those updates. If you also replace the system.img with a clone of the rootfs, then you will correctly flash all of these modifications to the next Jetson you flash. The process will properly sign partitions. If you didn’t modify the kernel or device tree, then you will get 100% cloning by simply telling the flash to reuse the rootfs which you provided from the clone (caveat: the JetPack/SDKM release should match the release which was used on the system you cloned).
Notes:
Beware that you cannot clone (at least in a useful way) the non-rootfs partitions. This is the job of the “driver package” (which JetPack/SDK Manager downloads and is a front end to). While flashing the rootfs from the correct version of JetPack/SDKM/L4T those other partitions will be correctly added (the rootfs can be from a clone).
So far as the rootfs goes you definitely don’t want to clone all files since not all files are actual files. Many files, including those in “/dev”, “/sys”, and “/proc”, do not exist on the disk/eMMC. Those files are actually drivers in RAM programmed to have a file interface.
As an example, consider if a naive file backup program were to create a file named “/backup/dev/random”, and tried to back up by coping all content inside of the real “/dev/random” to “/backup/dev/random”. The file will produce data until the end of time. Similar for “/dev/zero”. Backing up files requires a special tool, e.g., “rsync”, which understands files versus pseudo-files.
Note that if you dd a corrupt copy of a partition, then you will get a corrupt copy. If you use dd on a filesystem while it is changing and being used, then most likely you will get a corrupt (or at least incorrect) clone. If temp files or anything else changes on the filesystem while you use dd to copy it, expect errors. The clone process gets around this (if the filesystem is not corrupt) by not using the rootfs in recovery mode (there is a mini-operating system with minimal function while in recovery mode, and that operating system does not depend on eMMC).
The process of flashing provides a fresh install of all of those non-rootfs partitions. So long as you use the same release you can consider this a restore to the same version you had originally. Boot content modifications, such as a changed kernel and device tree, would need to be considered separately.
This process you mentioned is correct if you want the pristine non-rootfs partitions along with a clone of the original rootfs (warning, I amended this since rootfs is mmcblk0p1…I failed to read this closely enough):
$ sudo ./flash.sh -r <s>-k kernel-dtb</s><b>-k APP</b> -G backup.img jetson-tx2 <s>mmcblk0p28</s>mmcblk0<b>p1</b>
$ sudo cp backup.img bootloader/system.img
$ sudo ./flash.sh -r <s>-k kernel-dtb</s> jetson-tx2 <s>mmcblk0p28</s>mmcblk0<b>p1</b>
EDIT: The kernel-dtb can be flashed as originally named, but won’t be cloned in that manner since it is signed. One would add the unsigned dtb to the right place in the “Linux_for_Tegra/” tree of the driver package on the host PC prior to flash, or you would flash the modified (not cloned) device tree as you first mentioned. The point is that you can flash the dtb using the flash.sh tools, but you cannot clone in a useful way with those tools. Only the rootfs can be cloned in a useful way since it is not signed. If you want more information on device trees though, just ask.
Note: Clone will also produce “backup.img.raw”. This too could be used in place of “bootloader/system.img”. The result will be the same, except that the “backup.img.raw” is much larger and is very useful for examining, modifying, so on (the smaller file is of use because it flashes faster and takes less disk space on the host PC…when it expands the two are an exact match).
Note: You can fsck.ext4 the loopback mounted backup.img.raw. The “backup.img” can only be used for flash. You can create a new “backup.img” from the “backup.img.raw” using the “bootloader/mksparse” program (with NULL byte fill pattern, the default of mksparse).