,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.
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.
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)
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.
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.