R32.3.1 sdkmanager will flash a tx2-4g, flash.sh fails

Autonomous Machines Jetson & Embedded Systems Jetson TX2
#1

tried to use “sudo ./flash.sh -r jetson-tx2-4GB mmcblk0p1”
and system gets into an endless loop

[0000.665] I> Loading partition secure-os at 0x8530f600
[0000.670] E> Cannot find partition secure-os
[0000.674] W> Partition secure-os not found
[0000.678] E> Failed to load binary(14)
[0000.681] E> Top caller module: LOADER, error module: PARTITION_MANAGER, reason : 0x0d, aux_info: 0x00
[0[0000.146] I> Welcome to MB2(TBoot-BPMP)(version: 01.00.160913-t186-M-00.00-mo bile-7d3edb9d)

help
Terry

#2

I cannot give a complete answer, but this would in part depend on release. Which JetPack/L4T/SDKM release?

Additional questions:

  • Are you simply reusing an image from a previous flash, or are you using your own system.img?
  • If using your own system.img, is this image the default size, or is the size customized?
  • If using your own system.img, is the L4T/JetPack/SDKM release which originally produced the image from the same release as that which is being used to perform the flash?

Much of what those above questions are looking for is to know if partition sizes might have differed, or been rearranged based on release version.

#3

I am using jetpack 4.3 and r32.3.1. I have found that can only create a 4gb system using the sdkmanager, I tried to use flash.sh in the same dir and the system does not work.

had a system and kernel and device tree changes, tried to clone it. system.img is result of sudo ./flash.sh -r -k APP -G backup.img jetson-tx2-4GB mmcblk0p1

after moving backup.img to bootloader/system.img sudo ./flash.sh -r jetson-tx2-4GB mmcblk0p1 did not work. Then I lost my backup.img and I am starting over

#5

I don’t know the answer either. Maybe you could backup system.img again, put it to somewhere and try full flash first.

If there is no problem in full flash, then copy your system.img back and then run the flash.sh -r again and see if any problem.

#6

just trying the sdkmanager followed by the flash.sh -r fails without even touching system.img.

#7

Do you have any way to find the “raw” system.img size? I am hoping you have some reference to that size, but I suppose if the original backup was lost, then there is no way to know (a clone produces both a “.img” file and a “.img.raw” file). The sparse image won’t have a predictable size, but if you know the cloned “.img.raw” size, then it could be confirmed if maybe it was something as simple as a partition size change. I could see the possibility of strange things happening when the flashed image does not fit correctly into the partition scheme.

FYI, the raw image works as well as the sparse for flash, but takes longer since it is large. If you look at a raw image, and the size is twice divisible evenly by 1024, then that is the size in “MiB”; if divisible evenly three times by 1024, then the size is in “GiB”. The flash.sh “-S size” can be manually specified, e.g., “flash.sh -S 28GiB -r ...”. If you don’t have that information, then I do not know where to go from there.

#8

I am using sudo ./flash.sh -r -k APP -G backup.img jetson-tx2-4GB mmcblk0p1

Of course I copy the backup.img to the bootloader dir and rename it

and this to reflash the system
sudo ./flash.sh -r jetson-tx2-4GB mmcblk0p1

is jetson-tx2-4GB the correct name to use to rebuild the complete system? Or does sdkmanager use a different system name?

this works correctly to redo the device tree, sudo ./flash.sh -r -k kernel-dtb jetson-tx2-4GB mmcblk0p1

This is in my bootloader dir for the system that works.
ls sys*
-rwxr-xr-x 1 root root 4504857116 Jul 28 16:07 system.img*
-rwxr-xr-x 1 root root 15032385536 Jul 28 16:05 system.img.raw*

Thanks,
Terry

#9

Hi,

If the backup system is already copying to somewhere else, how about doing a full flash without “-r” and see if it can normally pass?

#10

FYI, if this is the flashed image size, then “15032385536” bytes is equivalent to “-S 14GiB” (15032385536 bytes divided by 1024 three times). If the original image produced a partition of “15032385536” bytes, then any flash of the rootfs via option “-S 14GiB” would guarantee reserving the right amount of space (obviously the flash script knows the size of the file when generating it, but I’m not sure that under all options/conditions a “reused” image will fit since some options do not write all partitions of the eMMC…specifying size makes sure the script knows this information).

If it turned out that your clone was not 15032385536 bytes, then your script would likely have overlapping partitions and corrupt data, or perhaps flash would fail.

#11

Solution, I was trying to use a nvidia dir that was originally for the tx2 8g to clone to a tx2 4g, after diffing the two dirs I changed all files to match the tx2 4g dir and things started working, maybe the sdkmanagers on the two dirs were different versions.

1 Like