We plan to clone the system after building the V35.4.1 system version and the corresponding cuda environment for a jetson orin som, and burn it into other soms in batches, our board is developed by itself, and it was found that the same model of som would be stuck and error when writing APP.img before, and we can modify it to 0x808 on the Internet, how to solve this problem
ERROR LOG：
[ 435.4997 ] Writing partition APP with system.img [ 21031917188 bytes ]
Error: Return value 3 ] 000%
Command tegradevflash_v2 --pt flash.xml.bin --create
Failed flashing t186ref.
Hi,
Please provide the full log and your commands for us to review.
Thanks
Hi
We use the command
sudo ./flash.sh -r -k APP -G backup.img jetson-agx-orin-devkit mmcblk0p1
to clone the system by connecting the orin with model number P3701 to the host of ubuntu version 18.04 and then move the backup.img obtained by the above clone to Linux_for_Tegra/bootloader.
and renamed to system.img, and finally replace orin and use the
sudo ./flash.sh -r jetson-agx-orin-devkit mmcblk0p1
command to burn in the system.
This is the log
flash_log.txt (100.3 KB)
Hi DavidDDD,Is there any easy way to solve this problem?We need a solution in order to carry out mass production.
Hi,
Please refer to README_backup_restore.txt workflow3
Workflow 3: To massflash the backup image.
Also refer to related doc
Thanks
Just a note maybe related to this (or maybe not): If the cloned partition size differs from the default size which would be produced from an ordinary command line flash, then the partition write might fail due to reaching its extents and not having room to continue writing the original partition. A normal flash with the “-r” option to reuse implies the partition is already the correct size, and that all content surrounding the partition will be newly added using that default size. The exact byte size of the raw clone (the sparse clone is the size of content within the raw size, but approaches the raw size as the filesystem fills to 100%) is the size which is required.
The “-S <size>” option is based on multiples of 1024 bytes. If you take the exact raw size and divide twice by 1024, this is MiB; if you divide three times by 1024 and get an exact number (no decimal), then this is the size in GiB. Imagine your raw image is 19327352832 bytes. If you divide by 1024 twice, it is the same as 18432MiB (I’m not positive, but I think there is no space between the number and the abbreviation for the -S argument); divide again for a third division and this is 18GiB. For that you could specify in the flash.sh command line “-r -S 18GiB” or “-r -S18432MiB”.
The backup and restore script works on everything and not just the rootfs. Still, the rootfs clone is quite useful. You might try with the “-r -S <size>” option, but there are other changes which might end up making you use the backup and restore script (e.g., I don’t know what happens if you have an “A/B” partition scheme).