Agx orin,35.4.1,After the backup was completed, the system.img card on the write device got stuck and wouldn't move

Hello NV Teams

,After the backup was completed, the system.img card on the write device got stuck and wouldn’t move.
Below are the device flashing log (flashlog) and the debugging serial port log (uartlog) that I have obtained.

flashlog.txt (20.6 KB)

uartlog.txt (18.2 KB)

I would like to add that I have already tried this method but it still didn’t work.

Hi yc13,

Are you using the devkit or custom board for AGX Orin?

[ 430.7110 ] Writing partition APP with system.img [ 295923712 bytes ]
[ 430.7223 ] [                                                ] 000%

From the log you shared, it seems you hit the issue during flashing APP partition.

Could you share the detailed steps how do you backup and restore?

Thank you for your reply.

Hello KevinFFF
Could you please help analyze what the reason might be? There are about 60 orins on the client side that require version 35.4.1.
I also tried the REMAME option under xxx/tools/backup_restore, but it didn’t work either.

Are you mixing a rootfs clone.img from different major releases of L4T? For example, an R36.x clone put onto an R35.x boot content? You can’t mix a rootfs from one major release to a different major release.

Also, if the clone is not the same size as the default flash image size, then you have to tell the flash software the size of partition with the “-S <size>” option.

Thanks for your reply

Hello

I conducted a test here.

Check the size of the image

clonesize
Use the following command to restore:

sudo ./flash.sh -r -S 3554631680 y-c8-agx-orin-3541 mmcblk0p1

The error message is as follows

err

Then I tried reducing or increasing the size of -S by 1048576, but encountered the following error message:

image

Please help me check if there are any other methods. I’ll also conduct another test simultaneously.

When I reduced it a little, the error message appeared as followsimage

Hello KevinFFF
I had a test on the official base platform this afternoon, but it didn’t work either. Was it a bug in this version?

The size is in units of 1024 (or multiples of 1024). KiB is 1024, MiB is 1024*1024, GiB is 1024*1024*1024. Since “3554631680” can be divided evenly only once with 1024 this would be “-S 3471320KiB”. I have not used this in a long time, but see how that works instead.

Also verify that the raw clone.img (or system.img if you directly copied it there) can be loopback mounted:

sudo mount -o loop ./clone.img /mnt
ls /mnt
sudo umount /mnt

(this is just a sanity check on the clone image itself)

Thanks for your reply

I’ll give it a try right away and let you know the result later.


I just tried it out. The command I used was:
sudo ./flash.sh -r -S 3471320KiB y-c8-agx-orin-3541 mmcblk0p1

Still getting an error. May I ask if you could test it with the official suite on your end?

What’s the exact size of your system.img.raw?

What’s the exact size of your APP partition before flash?

Thanks for your reply

3

Can you tell us more about the flash target “y-c8-agx-orin-3541”? If it were just a dev kit you’d be using the AGX Orin dev kit target.

For reference, 62024007168 is not the same as what I saw earlier. This cannot be divided evenly by 1024 even a single time, so something has changed. I’m not sure what the cause of that would be, or how well that change can be accommodated by the flash software.

“y-c8-agx-orin-3541” is our self-developed baseboard. Compared with the official baseboard, it only has expanded the interfaces.

Because two days ago, I kept testing with our official baseplate, but before your reply, I had been constantly trying. 62024007168 is the result of my device flashing with the devkit, backup, and then restoration yesterday.

I’ll look for another machine today. Let’s synchronize the base plate and the devkit. I’ll send you the Image size shortly.

Hello KevinFFF
When I use devkit
The backup command and results are as follows:

When I Use custom board:

The backup command and results are as follows:

Please take a look at it. If possible, you can also test this version.
Thank you

Hello KevinFFF
I have always failed when using virtual machines. Today, I replaced it with a physical machine and it worked successfully. I’ll do some more testing.

It is interesting that it isn’t divisible by 4096 or 1024. On the system which is the “donar” of the partition being cloned I’m guessing it was supposed to be a block size of 4096. On that donar system (the source of the clone image) what do you see from:

cd
stat -f .

I am also curious if changing your carrier board results in a “normal flash” (not a clone restore and not a partial flash) have any difference in the partition size (the bootloader/system.img.raw) or block size.