I’m not sure if JetPack 3.2.1 (L4T R28.x) uses the same clone command as R32.x (JetPack 4.x); cloning evolved slightly different command lines during R32.x release. If you cloned an R28.x rootfs using an R32.x flash.sh, there should not be any issue; cloning a partition shouldn’t care which release the clone is from (the “driver package” is what provides flash.sh and does not care about what flashed the Jetson if it is only reading partitions). It is the restoring of a clone partition where release matters since non-rootfs partitions and rootfs have dependencies.
If I read this correctly, then “#1” implies R28.x. If you restored an R28.x clone using the same R28.x driver package, then it should work, especially if you used a full flash which includes not only the rootfs, but also the other partitions. The goal is to guarantee all of the non-rootfs partitions are of the same version as the clone, and restoring with just the “-r” option implies all of the other content is freshly installed. Old content in non-rootfs partitions could be incorrect.
In the R28.x series the way to know what release the rootfs is from is “head -n 1 /etc/nv_tegra_release” (and if this is loopback mounted on the host PC just adjust for where the mount location is). Some time in R32.x (not the first release) dpkg started being used and /etc/nv_tegra_release was no longer used (that file goes away in releases using dpkg/apt for NVIDIA-specific content).
You are correct that the boot content varies drastically between older and newer L4T releases. I do not know how to find out what the release is for the non-rootfs part of boot. This is why I suggest doing a full flash where only the “reuse rootfs” option (“sudo ./flash.sh -r jetson-tx2 mmcblk0p1” after placing the clone as “bootloader/system.img”) is used to make certain the rootfs itself is from the clone…the other content is guaranteed to be overwritten with a consistent and correct release from that driver package (and thus you won’t need to examine the non-rootfs content version).
Note: Much boot content change was driven by adding support for Trusty/boot content signing and failover partitions.
Originally all of the Tegra flash software created a full Linux partition via loopback on the host PC during flash. This image is a bit-for-bit exact copy of what the flashed partition will be, and this is a rather large file on the host PC. This is “raw”. However, this takes a long time to copy so many gigabytes of data over a USB2 cable, and so a form of ext4 filesystem storage, known as “sparse”, stores only the parts of the ext4 filesystem which have content…the empty space is restored later with an algorithm instead of copying bytes. Think of this as the “poor man’s” compression for ext4 images. If an ext4 raw image has almost no content, then the sparse image will be almost zero size. If an ext4 raw image is filled with content, then the sparse image approaches the size of the raw image. The Jetson itself is able to flash using raw or sparse images, they are interchangeable.
I have not found any open source tools which work with this version of sparse image. The “mksparse” tool is used to create the sparse image, but converting sparse back to raw is in the realm of the recovery mode Jetson. Once you have a sparse version to work with it is written in stone, whereas a raw version allows using loopback.
The size of the raw image is always the exact size of the rootfs partition in the final eMMC content after flash.
I’m not sure if this is what you mean by “not available”, but the older driver package and JetPack should be available. If not, then someone will probably check why not, and get it back to the web site.
Any system using U-Boot should have an ability to interrupt prior to loading the kernel (via serial console), but this does not mean you’ll be able to make minor adjustments to get R28.x and R32.x to live with each other. The part of U-Boot environment you can easily change are the environment variables. An example of what would be easy to change there is the order of detecting boot devices or perhaps timeouts. You would need to give much more detail about what you want to change before anyone could say if interrupting boot would help, but making R28.x and R32.x compatible is not one of those.