L4t_backup_restore.sh not working when flashing bigger NVMe

Autonomous Machines Jetson & Embedded Systems Jetson Orin NX
1

Dear NVidia Team

We face an issue when taking a backup of a 1TB NVMe on our custom Orin NX platform and then flashing the image to another Orin NX with a 1 TB NVMe. The 1 TB NVMe is not booting and the device goes straight into the efi shell, even tough that the NVMe is seen inside the EFI Menu. When choosing it as Boot device, the efi menu pops up again right away. From the debug port we do not get any helpful information.
The weird thing now is, that when we flash the 1 TB NVMe with a freshly built image with the kernel_flash tool , the system boots up without any issue. And after we have done that once, we can also restore the NVMe with the previous taken image and the system then boots also up.

Here our commands for the backup and restore:

./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -b brla4n-orin-nx
./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -r brla4n-orin-nx

Is there something that does not get written to the flash when using the backup_restore tool but only when the kernel_flash tool is used?
Thank you for your help.

Kind regards

3

Hi sevm89,

What’s the Jetpack version in use?

It seems it would work after you’ve used command to flash the NVMe directly to a fresh module.

Your issue may relate to that QSPI of the module is not flashed if you just use backup package to flash NVMe SSD.

It will flash both QSPI and also NVMe SSD.

4

Hi KevinFFF

Thank you for the fast reply.
We are using JetPack 6.0. With older JetPacks, we never had such an issue. Should the backup_restore tool not also flash the QSPI? At least it is part of the image files:

$> ls tools/backup_restore/images/
gptbackup.img nvme0n1p10_bak.img nvme0n1p12_bak.img nvme0n1p14_bak.img nvme0n1p1.tar.gz nvme0n1p3_bak.img nvme0n1p5_bak.img nvme0n1p7_bak.img nvme0n1p9_bak.img QSPI0.img
gptmbr.img nvme0n1p11_bak.img nvme0n1p13_bak.img nvme0n1p15_bak.img nvme0n1p2_bak.img nvme0n1p4_bak.img nvme0n1p6_bak.img nvme0n1p8_bak.img nvpartitionmap.txt tmp

Also we flash new Orin NX modules (factory state) only with the backup restore tool and QSPI seems to be programmed, as the system is able to boot into the efi shell.
Let us know if you need further information.

5

No, it would not flash the partitions in QSPI.

Could you help to compare those 2 logs to find the difference? They should use the similar script and the process to perform backup/restore.

I’m not sure if they have been flashed in factory or somewhere.

You can try using the following command to flash QSPI only and check if you could still reproduce the issue in JP6.

$ sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit internal
7

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.