Is it true that the so-called copying the App partition means copying the entire nano?

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

Hello,

Is it true that the so-called copying the App partition means copying the entire nano?

image
image1295×164 20.4 KB

Thank you.

3

hello neuezeal,

it’ll copy APP partition to another new file if you’re performing an image clone.
that’s not copy entire Nano, there’re still several images.
you may refer to flash configuration file for the partition layouts,
for example,
$OUT/Linux_for_Tegra/bootloader/t210ref/cfg/flash_l4t_t210_emmc_p3448.xml

4

Hello,

We are going to make a mass flashing blob with the image created through image duplication and use it for mass production.
Is this possible?
Isn’t it an incomplete copy if it’s not copying the entire nano?

Thank you.

5

hello neuezeal,

there’s readme file you may found, README_Massflash.txt

1 Like
6

You might find it useful to know that the APP partition is the operating system and user files. All other partitions are the equivalent of a motheroard’s CMOS BIOS plus bootloader. If you have customized the device tree or boot in some way, then your updates go into the host PC at various places under “Linux_for_Tegra/”, and this automatically gets applied to non-APP content. Since some of that content is signed as it is installed, this is the best way to do this. Copying something signed for another system, if it depends on keys in that other system, will fail.

1 Like
7

Hello,

Thanks for the reply.

I didn’t understand the following sentence and I’m not particularly sure what’signed’ means.

Thank you. 👍😊

8

Hello,

Does’updates’ mean executing ./apply_binaries.sh here?

Thank you.

9

the app partition is mmcblk0p1
while the entire space is mmcblk0
typically there are about 12 -14partitions : mmcblk0p1 - mmcblk0p14
all of them but the APP are kind of system/ supplementary
only the APP has users apps/data
partitions could be listed using
lsblk

1 Like
10

Prior to L4T R32.x secure boot and other methods of authenticating boot content had not yet been put in place, at least not by default. Those non-APP partitions are essentially the equivalent of CMOS BIOS and bootloader. Within R32.x that other content began to be cryptographically signed. That content can depend on a key within the Jetson if enabled. Different Jetson with different keys implies what is signed for one will not work with another. This will not apply in all cases. This will always apply in cases where the fuse has been burned. Prior to burning a fuse it is possible to read some content used in comparing signatures, and after burning the fuse, none of that content is readable by the outside world. So far as I know (I don’t have units to test fuse burning with), it is possible to require a correct signature prior to burning the fuse. If the signature is bad it would refuse to boot, but you would still have a chance in this case to fix the problem; once the fuse is burned the only chance you have is to know the key content without reading it from the Jetson.

During a normal flash for R32.x+ many of the partitions will have a pregenerated “standardized” image copied from the host machine to the Jetson. During the copy the content has a signature added to it. The final partition size will require, at minimum, the byte size of the image plus the byte size of the signature (in reality the partition will be bigger, with excess space filled in with NULL bytes).

No. “apply_binaries.sh” is is part of NVIDIA’s creation of a boot image, and yes, this has to occur. However, when I say “your” updates, I am implying any custom device tree, and any custom bootloader. Most people with a custom carrier board need a device tree update, but usually do not need a bootloader update. Another example of a customization which would be added to the host PC is a custom splash image. The point is that when using actual flash software, and not using a prebuilt image, that the boot content of non-APP partitions is generated, and customizations within certain parts of the “Linux_for_Tegra/” subdirectory will propagate to the flashed Jetson. Often those customizations go somewhere in “Linux_for_Tegra/bootloader/” or “Linux_for_Tegra/kernel/”.

The next time you flash a Jetson on command line I recommend that you log the flash and save the log. This can be used as a reference to see which files are used, signed, and flashed, for your configuration. Example with logging (note the extra “2>&1 | tee log_flash.txt”):
sudo ./flash.sh jetson-nano-emmc mmcblk0p1 2>&1 | tee log_flash.txt

1 Like