I am working with a custom carrier board and using three Jetson AGX Orin Industrial modules.
For convenience, I will refer to them as Module A, B, and C.
Using the l4t_backup_restore.sh tool, I successfully created a backup image from Module A and attempted to restore it to both Module B and Module C with the following command:
However, the restore to Module C failed with the following output:
Waiting for device to expose ssh ......Waiting for device to expose ssh ...
Device has booted into initrd. You can ssh to the target by the command:
$ ssh root@fc00:1:1:0::2
Cleaning up...
Log is saved to Linux_for_Tegra/initrdlog/flash_3-3_0_20250909-082200.log
Run command:
ln -s /proc/self/fd /dev/fd && mount -o nolock [fc00:1:1::1]:/home/jo/Linux_for_Tegra/tools/backup_restore /mnt && /mnt/nvrestore_partitions.sh -e mmcblk0 -n
on root@fc00:1:1::2
/mnt/images ~
nvrestore_partitions.sh: Use the default nvpartitionmap.txt as the index file.
nvrestore_partitions.sh: You are trying to flash images from a board model that does not
match the current board you're flashing onto.
To investigate, I dumped the EEPROM contents of Module A, B, and C.
I noticed that the BOARDREV field is different between them:
Module A and B : S.0
Module C : P.0
My Questions are:
Exactly what difference in Module C (compared to A/B) is causing the restore failure?
What steps should I take if I want to restore the backup image from Module A onto Module C?
*** Please note that this reply is generated by LLM automatically ***
Based on the provided information, I’ll address your questions and provide a comprehensive answer.
Difference in Module C compared to A and B:
The BOARDREV field in the EEPROM contents of Module A and B is “S0”, while in Module C, it’s “P0”. This indicates a difference in the board revision between Module C and Modules A and B.
Causing the restore failure:
The restore failure is likely due to the difference in the BOARDREV field. The l4tbackuprestore tool might be checking the BOARDREV field to ensure compatibility between the backup image and the target module. Since Module C has a different BOARDREV value (“P0”) compared to Module A and B (“S0”), the tool is preventing the restore operation to ensure that the image is not flashed onto an incompatible module.
Steps to restore the backup image from Module A onto Module C:
To restore the backup image from Module A onto Module C, you have a few options:
Update the BOARDREV field in Module C’s EEPROM: If you are certain that Module C is compatible with the backup image from Module A, you can update the BOARDREV field in Module C’s EEPROM to match the value in Module A’s EEPROM (“S0”). However, this should be done with caution, as it may affect the module’s functionality or compatibility with other components.
Create a new backup image from Module C: If updating the BOARDREV field is not feasible or recommended, you can create a new backup image from Module C using the l4tbackuprestore tool. This will ensure that the backup image is compatible with Module C’s specific configuration.
Use the --force option with l4tbackuprestore: You can try using the --force option with the l4tbackuprestore tool to override the BOARDREV field check. However, this should be done with caution, as it may lead to compatibility issues or other problems.
Before attempting any of these steps, it’s recommended that you consult with NVIDIA support or the module’s manufacturer to ensure that you are taking the correct approach and to avoid any potential risks or compatibility issues.
In summary, the difference in the BOARDREV field between Module C and Modules A and B is causing the restore failure. To resolve this, you can update the BOARDREV field in Module C’s EEPROM, create a new backup image from Module C, or use the --force option with the l4tbackuprestore tool, but with caution and after consulting with the relevant support teams.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
