Flashing and cloning custom AGX Xavier


I am a user using the MIC-730AI (MIC-730AI - AI Inference System based on NVIDIA® Jetson AGX Xavier™ - Advantech), which is essentially a ruggedized version of AGX Xavier.

I will need to work with a large number of devices, and all of them need the same software and files for deployment. I will need to flash all of them with Jetpack 4.6 and then install certain python packages and copy some files in (basically my python scripts).

I looked at Any fast way for cloning AGX Xavier? for a way to clone devices.

I have a few questions:

  1. There is a command “sudo ./flash.sh -r -k APP -G my_backup.img jetson-xavier mmcblk0p1”. It says “jetson-xavier” should be changed if model is different, e.g., a commercial module would have a different name versus a dev kit model. How do I know is this model for MIC-730AI? Is it jetson-agx-xavier-industrial as described here: Quick Start — Jetson Linux<br/>Developer Guide 34.1 documentation
  2. Will cloning this way onto another device mean the device on which the old device was cloned to will be exactly the same? LIke, can I run all my software? Do I still need to copy files in, make installations? What exactly is a clone? Thank you.

When you go to the “Linux_for_Tegra/” directory after install of JetPack 4.6 you will see a number of “*.conf” files. Many are just common names aliased to point at numeric designations of the same module and carrier board combination. For example, in one case:

# ls -l jetson-xavier.conf
jetson-xavier.conf -> p2822-0000+p2888-0004.conf

When flashing to “jetson-xavier”, it implies this file is used for configuration. The more obtuse file name is a combination of the designation for the module (perhaps with revision) and the carrier board. Any time you flash a given module, but a different carrier board, you will see only the carrier board half of the naming change. You can read those files and see what configuration is being specified. You could also copy such files and make your own “.conf” file for some sort of a custom flash based on specifications of your module plus carrier board.

When you clone a Jetson you don’t need any particular carrier board. Recovery mode, if the correct pins are connected for the USB, will clone without caring about device tree or modifications to the carrier board. Cloning is read-only, so there isn’t any reason you couldn’t test your cloning. If it fails, no harm done. If your module can be found by naming “jetson-xavier”, then you don’t need to do more, just clone.

I don’t know how to detect a specific carrier board. However, the manufacturer of that carrier will provide flash software of their own (a board support package) if there is any difference between this and the dev kit (there would be a different device tree, and thus a different PINMUX_CONFIG…see the .conf file). What target does the carrier board manufacturer use? Look at the .conf file they provide for that designation (assumes they tell you command line name, or else there is an obvious .conf file with their software).

The clone is a bit-for-bit exact copy of the rootfs (APP label) partition. The clone produces both a “raw” clone (named something.img.raw) and a “sparse” clone (named something.img). The smaller sparse file is used for flashing and has a size approximately equal to the content of the partition. The larger raw file can be loopback mounted, edited, so on, and is the exact size of the entire partition. Either one can be used to flash with when placed as the appropriate name in the appropriate location and flash is told to “reuse” the image, but the smaller one is faster. The size of the smaller sparse image approaches the size of the raw image as the partition fills up and approaches 100% capacity. You can also use the mksparse application (with NULL filler bytes) to create a sparse partition from a raw partition. I throw away the sparse one and keep only the raw one. They take a long time to move or compress, but when not in use, I compress it with “bzip2 -9”.

If you mass produce based on a clone consider that this will also clone account names and passwords. The reason why NVIDIA stopped using default names and passwords, and instead went to first boot user setup, is because of California laws, so keep that in mind.

When you flash a rootfs/APP partition to a Jetson it must match the release paired to it for boot content. If a unit was previously flashed with the same release of everything non-rootfs, then you could just flash that partition. However, if anything might differ in other boot content, then you need to flash everything (but rootfs can be your clone so long as the rest of the content is from that same JetPack 4.6 release). Also, if you’ve burned security fuses, then of course those need to be used with the non-rootfs content, and some of the “/boot” content will then be ignored even if it exists.

If security fuses are not burned, and if you’ve set up for boot via files named in extlinux.conf, and if those files are in “/boot”, then a clone will boot the same way on every unit with correct “other” boot partition content installed.

Incidentally, the R34.1 guide will be wrong for JetPack 4.6. R34.x+ (there is now an R35.x) provides an L4T R32.x release of L4T. JetPack/SDK Manager is a front end to flash software, and L4T is what gets flashed. L4T itself is just Ubuntu plus NVIDIA drivers and boot content. There are major differences in many ways between R32.x and R34.x+.

1 Like

Got it. So I will just try the different names to see if my module can be found.

Can I check what you mean by “When you flash a rootfs/APP partition to a Jetson it must match the release paired to it for boot content”. How do I check this?

The L4T release is given from “head -n 1 /etc/nv_tegra_release”. I don’t know if you can find that release version from the non-rootfs content. Basically though, one would flash with that release when installing a clone from what is shown in the nv_tegra_release. If you go to the list of L4T releases it will lead to the JetPack/SDKM release (they are tied together):

Just flash everything, and reuse the rootfs, and when using the correct release, it’ll “just work”. Incidentally, you can normally start a more recent JetPack/SDKM like this to see other releases:
sdkmanager --archivedversions
(you can usually get the older release with the newer JetPack/SDKM if you tell it that you are interested in the older releases)

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.