Jetson orin nano cannot create clone.img

Hi,

I try with “sudo ./flash.sh -r -k APP -G clone.img jetson-orin-nano-devkit nvme0n1p1” using jetpack 5.1.2 on the devkit but stuck as below.

[ 45711.7039 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 46728.5130 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 47743.3194 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 48760.1289 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 49774.9355 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 50791.7456 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 51806.5521 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 52823.3611 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 53838.1678 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 54854.9775 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 55869.7836 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 56886.5928 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 57901.3996 ] tegrarcm_v2 --chip 0x23 0 --ismb2
[ 58918.2093 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[ 59933.0162 ] tegrarcm_v2 --chip 0x23 0 --ismb2

This is not supported.
You need to do either:
https://docs.nvidia.com/jetson/archives/r35.5.0/DeveloperGuide/SD/FlashingSupport.html#cloning-rootfs-with-initrd
, or:
https://docs.nvidia.com/jetson/archives/r35.5.0/DeveloperGuide/SD/FlashingSupport.html#to-back-up-and-restore-a-jetson-device

Hi DaveYYY

I tried with initrd.
I having issue with mksparse system.img.raw to system.img

Error I got is “size of system.img.raw is not mulple of 4096”

The backup/restore tool should be more reliable.

Hi Dave,

My issues for the “size of system.img.raw is not mulple of 4096” already get rid of this issues. Able to clone but not flash, flash error is QSPI fail.

backup/restore I am successful to clone and restore with no disk encryption. I haven’t try with disk encryption optee.

Do you know is it possible? As I plan to flash 1 device and install all necessary in house software, then clone it and for production to flash all devices with disk encryption

Put the log here.

I think we also haven’t verified this usecase, but you can give it a try.
Ideally, the tool does not care what’s inside the image so disk encryption may not make an impact.

I tried with disk encryption by using backup_restore. It’s seems cannot find the key for decrypt.
Attach the UART log below.
encrypted_restore.log (88.4 KB)

My end goal would like to clone/backup encrypted disk and flash/restore to all the production unit.

What did you get from the script running on the host?

which script you means? backup_restore or initrd?

for backup restore i didn’t saw any error.
I think it’s don’t backup the key from the device and restore the ekb key/sym2 key to the device.

YES, I mean the log of this script.
Did you get the backup image correctly under Linux_for_Tegra/tools/backup_restore/images/?

backup.log (92.7 KB)
attached with log above.
I believe i got the correct image in backup_restore/images
as there is QSPI, nvparitionmap.txt and lot of .img i believe

Do you have any details of -u and -v argument for backup_restore?
-u pkc key file
-v sbk key file
there is nothing about -u and -v in README file.

I tried with -v sbk key, as i don’t have pkc key.
the script will giving error of missing pkc key.

hello mrcloud,

hold-on…
it’s bad practice to have a single image for mass-production with disk encryption mechanism.

it’s not support to use generic passphrase, please have unique ECID to enable disk encryption.
according to developer guide, the Jetson Linux reference implementation only generates per-device encrypted disk images.

please refer to Details of Operation in disk encryption section for more details.
you may see-also similar discussion threads, such as Topic 263337, and Topic 265989.
thanks

Hi Jerry,

I understand what you means about best practice or bad practice about the passphrase.

My use case is only to configure once (deploy software) the device and replicate it across all the unit during the production with different encryption key. (not to configure (deploy software) every device after the complete flashing with disk encryption.
Do you know possible or how I can achieve it?

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