You can clone the Jetson you are interested in and use that for the image. Some procedures depend on release, and so without knowing more details some specifics cannot be answered. However, this will be basically correct for cloning on several recent releases:
On R32.1 (see “head -n 1 /etc/nv_tegra_release”) you probably need this patch to flash.sh:
If you’ve ever flashed a release, then flash.sh will be in the “Linux_for_Tegra/” directory. Always flash with the same release the clone is from.
Beware a clone can also copy some hardware specific files. Most of the time this won’t happen, and perhaps the biggest issues are:
- Accounts and passwords will clone.
- Custom udev rules may depend on something on the particular hardware.
Example: A udev for network device renaming might depend on a MAC address.
- Histories and logs will clone.
If you clone you will get both a raw “backup.img.raw” file and a sparse “backup.img” file. I throw away the sparse file and use only the raw file. Either one, when placed in “Linux_for_Tegra/bootloader/system.img” will flash, but raw files take longer. Raw files can be turned into sparse files if you wish using the mksparse utility (fill pattern null bytes). Raw files can be loopback mounted, edited, examined, updated from an original to a host via rsync, so on.
The flash.sh option “-r” prevents a new “bootloader/system.img” from being produced. An existing image would be used if it is there. The clone can be used to replace system.img, but be sure to save a safe backup since doing things wrong could destroy the clone. This is a very large file and it will take time to copy it anywhere.
You could loopback mount the image, e.g., “sudo mount -o loop ./backup.img.raw /mnt” (puts on “/mnt”). If you were to mount the image on “Linux_for_Tegra/rootfs/”, then this would be used instead of the sample rootfs. You would need to be careful if not using command line since JetPack/SDK Manager might update the location with the sample rootfs…which would overwrite your clone. Using on “rootfs/” need to be read-write since “rootfs/boot/” content is overwritten. To that extent, if your “/boot” content is not custom, this wouldn’t be an issue, but if the kernel is custom, then this would overwrite your kernel. Then a new system.img would be generated based on your loopback mount to “rootfs/”. I suggest just using the “-r” option.