I’ve never used mass flash, so I can’t comment on that. I can tell you a bit more about the image.
FYI, JetPack/SDKM is just a front end to the actual flash software. Utilities such as “
flash.sh” are what do the real work during a flash, even if behind the scenes.
Normally the sample rootfs is populated into “
Linux_for_Tegra/rootfs/”. After this the “
Linux_for_Tegra/apply_binaries.sh” script is used to install some of NVIDIA’s direct hardware accelerated libraries/drivers into this. It is at this point the content changes from just generic “Ubuntu” to “Linux for Tegra” (“L4T”). This step only needs to be performed once, and from then on images created are based on this, although with some boot content edits.
The boot content edits depend on the arguments passed to
flash.sh. Much of that editing goes into “
Linux_for_Tegra/rootfs/boot/”. Typical edits are to the
extlinux.conf file, the kernel, or device tree. Those particular edits are because changes exist depending on carrier board or other options, and so those edits occur every single flash if that flash generates a new image.
That new (raw) image becomes “
Linux_for_Tegra/bootloader/system.img.raw”, and from this a “sparse” (smaller) version of this is created, “
Linux_for_Tegra/bootloader/system.img”. You could use either raw or sparse image at “
Linux_for_Tegra/bootloader/system.img”, and the flash would succeed and do the same thing since the Jetson can flash with either raw or sparse and “do the right thing”.
flash.sh uses the “
-r” option it does not generate a new
system.img. Whatever is there already gets reused.
If you were to put a clone in place of
system.img, then the clone would be flashed as the rootfs without any edits. If you were to put a clone’s content (e.g., loopback mounted or rsync’d) in “
Linux_for_Tegra/rootfs/”, then this would be a nearly exact match for the clone. The generated clone would have some edits added for boot content prior to generating a new image (you’d not use the “
As an example of usefulness, I tend to have saved directory trees (including preserved permissions) with network settings, ssh keys, so on. If I unpack the generic Ubuntu sample rootfs, run the
apply_binaries.sh script, and then recursively copy my content in, then upon first boot I have my account already set up, network already set up, and can ssh right in without any extra steps and using a key instead of password.
If you wish to mass flash and use the same image, then there is one thing you need to be careful of when customizing: Sometimes settings are device dependent and would need to change for each device. The most glaring illustration is that some content in “
/etc” might depend on the device’s MAC address (e.g., to rename an interface depending on MAC address) and fail if the MAC is not there, or a udev rule might depend on some device’s UUID or serial number…which would probably differ from one device to the next.
I have never used mass flash, so I can’t provide any details of how the image might be edited or used differently on multiple devices.