We are deploying and managing over 200 Jetson Xavier NX devkits with eMMC, distributed in industrial environments. All units are standardized and optimized to run JetPack 5.0.2 / L4T R35.1.0. For certification and operational reasons, upgrading JetPack is not an option.
We require a reliable method to clone and restore a fully configured Xavier NX device onto another identical unit, typically received in factory state (empty eMMC).
SDK Manager used: Yes, version from the official SDK archive
No matter the method — backup_restore.sh, flash.sh, or dd cloning — we cannot restore a functional system onto a new Xavier NX.
We seek official guidance on how to make image restoration feasible under these constraints.
All restore attempts consistently fail at the bct_mem step, even with seemingly identical boards.
Example error:
[ 6.2103 ] 000000008c8c0302: E> NV3P_SERVER: Failed to verify image bct_mem.
How can we reliably restore a backup from JetPack 5.0.2 to a factory-new Jetson Xavier NX eMMC device?
Why does a full dd clone not boot, even though the image is byte-identical?
Is there a known incompatibility or verification step tied to hardware fuse or SKU that prevents restoration?
This issue sounds not related to what method you are doing here.
The reason here is because of PCN update in new Xavier NX. Please check PCN announcement and see if all your new XNX modules are for one specific kind of PCN updte.
Thank you for your response and your support — we truly appreciate it.
We’re not experts in the low-level hardware changes on Jetson modules, so your hint about the PCN was very helpful.
After further investigation, we’ve confirmed that the cloning failure is indeed tied to a hardware revision difference. Specifically, we’ve compared two modules:
The older Jetson Xavier NX units (which clone and restore successfully) report EEPROM strings like: 699-13668-0001-301 G.0
The newer ones (where cloning fails) report: 699-13668-0001-302 B.0
These appear to be the result of a PCN update, which likely includes changes to memory configuration or other key hardware components that require updated BCTs.
We are working with JetPack 5.0.2 because our production environment is deeply integrated with it. Unfortunately, upgrading is currently not feasible due to extensive customization and validation requirements.
We’ve tried multiple approaches:
backup_restore.sh
Full dd disk clones
Flashing using flash.sh -r
Recovery mode dumps via tegraflash.py
All fail when targeting the newer modules, due to what appears to be a memory configuration mismatch during BCT verification (bct_mem fails to load).
Would NVIDIA be able to provide:
A technical note or patch to adapt JetPack 5.0.2 to support the newer PCN hardware?
Or, at the very least, the correct memory configuration files (BCTs) for the 302 B.0 variant?
Confirmation of whether JetPack 5.0.2 is fundamentally incompatible with these newer units.
Thanks again — any guidance you can offer would be incredibly valuable, as time is becoming a critical factor in our deployment pipeline