When you go to the “Linux_for_Tegra/” directory after install of JetPack 4.6 you will see a number of “*.conf” files. Many are just common names aliased to point at numeric designations of the same module and carrier board combination. For example, in one case:
# ls -l jetson-xavier.conf
jetson-xavier.conf -> p2822-0000+p2888-0004.conf
When flashing to “jetson-xavier”, it implies this file is used for configuration. The more obtuse file name is a combination of the designation for the module (perhaps with revision) and the carrier board. Any time you flash a given module, but a different carrier board, you will see only the carrier board half of the naming change. You can read those files and see what configuration is being specified. You could also copy such files and make your own “.conf” file for some sort of a custom flash based on specifications of your module plus carrier board.
When you clone a Jetson you don’t need any particular carrier board. Recovery mode, if the correct pins are connected for the USB, will clone without caring about device tree or modifications to the carrier board. Cloning is read-only, so there isn’t any reason you couldn’t test your cloning. If it fails, no harm done. If your module can be found by naming “jetson-xavier”, then you don’t need to do more, just clone.
I don’t know how to detect a specific carrier board. However, the manufacturer of that carrier will provide flash software of their own (a board support package) if there is any difference between this and the dev kit (there would be a different device tree, and thus a different PINMUX_CONFIG…see the .conf file). What target does the carrier board manufacturer use? Look at the .conf file they provide for that designation (assumes they tell you command line name, or else there is an obvious .conf file with their software).
The clone is a bit-for-bit exact copy of the rootfs (APP label) partition. The clone produces both a “raw” clone (named something.img.raw) and a “sparse” clone (named something.img). The smaller sparse file is used for flashing and has a size approximately equal to the content of the partition. The larger raw file can be loopback mounted, edited, so on, and is the exact size of the entire partition. Either one can be used to flash with when placed as the appropriate name in the appropriate location and flash is told to “reuse” the image, but the smaller one is faster. The size of the smaller sparse image approaches the size of the raw image as the partition fills up and approaches 100% capacity. You can also use the mksparse application (with NULL filler bytes) to create a sparse partition from a raw partition. I throw away the sparse one and keep only the raw one. They take a long time to move or compress, but when not in use, I compress it with “bzip2 -9”.
If you mass produce based on a clone consider that this will also clone account names and passwords. The reason why NVIDIA stopped using default names and passwords, and instead went to first boot user setup, is because of California laws, so keep that in mind.
When you flash a rootfs/APP partition to a Jetson it must match the release paired to it for boot content. If a unit was previously flashed with the same release of everything non-rootfs, then you could just flash that partition. However, if anything might differ in other boot content, then you need to flash everything (but rootfs can be your clone so long as the rest of the content is from that same JetPack 4.6 release). Also, if you’ve burned security fuses, then of course those need to be used with the non-rootfs content, and some of the “/boot” content will then be ignored even if it exists.
If security fuses are not burned, and if you’ve set up for boot via files named in extlinux.conf, and if those files are in “/boot”, then a clone will boot the same way on every unit with correct “other” boot partition content installed.
Incidentally, the R34.1 guide will be wrong for JetPack 4.6. R34.x+ (there is now an R35.x) provides an L4T R32.x release of L4T. JetPack/SDK Manager is a front end to flash software, and L4T is what gets flashed. L4T itself is just Ubuntu plus NVIDIA drivers and boot content. There are major differences in many ways between R32.x and R34.x+.