A default flash (which is what you described) generates a new rootfs image each time it runs. If you are using the same image each time, then you can stop generating the new image and just flash.
During flash a raw image is created at “Linux_for_Tegra/bootloader/system.img.raw”. From this a smaller image is created, “Linux_for_Tegra/bootloader/system.img” (it is a “sparse” image). The raw image is mostly generated from the “Linux_for_Tegra/rootfs/” content, although some adjustments are made for the target and device chosen (such as the extlinux.conf, and if you changed from flashing the particular target to a different target, then it would also change PINMUX/device tree and kernel). If you are modifying rootfs/ each flash, then you need to generate a new image. If you are modifying kernel and device tree between flashes, then you also need a new image each time.
The "-r" option says to reuse the "system.img" file. No system.img.rawwould be created, and no sparse image generated...it just uses what is there from the previous flash (incidentally, if you had a clone, you could put this in place assystem.imgand you'd be flashing the exact clone). Example:sudo ./flash.sh -r jetson-xavier-nx-devkit-emmc mmcblk0p1`
The above will flash everything, but it won’t generate a new system.img.
I want to point out that if you are at “Linux_for_Tegra/”, and you use this command:
ls -l jetson*.conf
…then what you will find are all flash targets. the “jetson-*.conf” targets are just the human readable names. The alias which points at more obscure file names are just the combination of module specification and carrier board specification. These, in turn, are all human-readable script. If you were to copy one of these, and rename it slightly, then that file (without the .conf suffix) becomes a flash target.
If you were to copy jetson-xavier-nx-devkit-emmc.conf to a new name, e.g., jetson-xavier-nx-devkit-emmc-custom.conf, you could edit that file. If you follow what files are included in that file, and then copy those files to a “-custom.conf” name, then you could also edit those files (the files become more specific to module, or SoC, or carrier board). If you find the location which names which device tree is copied into the “rootfs/” (or kernel Image), then the -custom.conf file could be edited to point directly at this. From then on you wouldn’t need to flash separately for PINMUX. Or kernel Image.
In fact, the device tree (PINMUX) rarely has to be flashed at all. It depends on some details. Some content is available both in partitions for boot and in the rootfs. The partition content (only on eMMC models, but yours is that) must be signed before it is accepted, and this is performed automatically during flash. If you have not burned security fuses, then the default NULL key is used. During boot signed partitions for kernel and device tree can be used, and those partitions are updated only via flash most of the time. However, content in “/boot” takes priority over partitions if the fuses are not burned.
Examine your “/boot/extlinux/extlinux.conf”. If there is an FDT key/value pair entry, then it names the location of the .dtb file to be used (overridden only if security fuses are burned or the file is not found). The same is true of the kernel Image file: If it is listed in the extlinux.conf, then that takes priority over any partition content (unless security fuses are burned).
If you were to log flash on command line (I very highly recommend you do this once to keep a record) you would see exactly which kernel and device tree and extlinux.conf is copied into “rootfs/” before generating a new rootfs image. Example to log:
sudo ./flash.sh jetson-xavier-nx-devkit-emmc mmcblk0p1 2>&1 | tee log_flash.txt
Example to log which reuses the rootfs image (“bootloader/system.img”):
sudo ./flash.sh -r jetson-xavier-nx-devkit-emmc mmcblk0p1 2>&1 | tee log_flash.txt
If you were to clone one of your Jetsons after doing everything you want, e.g., updating packages, maybe adding custom programs or new libraries, you could then copy the raw or sparse clone to “bootloader/system.img” and this would be used again. You could skip package updates and any customization that was in the clone.
A raw clone is the exact bit-for-bit image of the rootfs partition. It is the exact size of the partition, so if the partition is 20 GB, then the clone will take up 20 GB on the host PC. That’s an enormous file, but it can be loopback mounted, examined, edited, used as a sysroot for cross compile, so on. A sparse image is generated from the raw image and excludes “empty” space. Thus, a sparse clone size approaches the size of a raw clone as the space is filled. If you were to clone a full filesystem, then the raw plus sparse size would be double the size of the partition. Flash does not care if you flash the raw clone or if you flash the sparse clone, the result is the same, but you can’t use a sparse clone the way you can a raw clone.
There is a tool available to convert a raw clone to a sparse clone, “Linux_for_Tegra/bootl,oader/mksparse”. Just use the NULL byte fill pattern (“0”).
Flashing a raw clone takes more time than flashing a small sparse clone. All of that content goes over the USB cable. This is why the sparse clone exists: A faster flash. On the other hand, you’re generating a new system.img.raw and a new system.img is being derived from that every time you flash with the command you provided. Then the sparse clone is being used to flash.
If you were to clone, then you would need to beware that this is a full exact clone. User accounts and their passwords would be the same on all of the flashes. If you have a udev rule for a custom USB device setup, e.g., one that depends on a MAC address of a specific network adapter, then that too would be cloned. If you ship to the state of California, then you are not allowed to use default admin passwords, which is why the first boot account setup method was added and Jetsons long ago stopped using default accounts and passwords.
If you are ok with using the file version of your device tree, just copy it into the location named by the FDT key/value pair of extlinux.conf and don’t bother flashing (the old tree would still be in the partition, but if you adjusted flash target specification, the new tree would already be there anyway). Burning of security fuses will limit options.