I’d start by recursively saving everything in the working sample’s “/boot” directory. Also save a copy of its “/etc/nv_tegra_release” and “/etc/nv_boot_control.conf”. Create an extracted device tree and save this somewhere:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
On the working system, also post the output of “lsblk -f -T”. This should give a slight safety if something goes wrong.
Incidentally, the developer’s kit is what the NVIDIA flash software is based on. This implies (for this model) no eMMC, and booting to the SD card slot (which would be on the module, not on the carrier board). The flash target changes slightly if you have a commercial module, but the NVIDIA software works for commercial modules on dev kit carrier boards.
Where this differs/diverges is the device tree changes for the carrier board. There are ways to flash using your own device tree. Although the extracted tree from above might have edits (the boot stages can edit prior to passing on to Linux), but it is a good thing to have a copy of what that tree is on the working one.
The device tree typically helps find components of the carrier board which are not plug-n-play, but which must be accessed at some physical address. To that extent, if a third party creates a new carrier board with the same electrical layout (physical layout isn’t important), meaning the same hardware at the same address, then the NVIDIA device tree and software will work as is.
Once the hardware differs, e.g., putting an SD card slot on the carrier board instead of being on the module, the device tree (firmware) must be updated to show that change. If one has a carrier board which is the same in most electrical layout as the dev kit carrier board, then those subsets which were the same feature layout will still work, and only the ones which have changed will fail. If that turns out to be a different memory address (or anything major), then boot will probably fail without that update. If this is some non-critical item, e.g., a serial UART which isn’t required for boot, then you wouldn’t notice the failure until you went to use that part.
I noticed some bar codes on the carrier board itself. You wouldn’t care about the bar codes on things like the separate m.2 module, but a smart phone with a bar code reader might tell you something about the bar code which is on the carrier board itself near the mounting hole.
Incidentally, you could rsync copy the entire filesystem, which would be useful, but there are also other partitions. This wouldn’t be enough by itself, but it could save some effort since you could study this on a desktop Linux PC without worrying about changing the Jetson.
