Flash Jetpack stripped version into Nano SoM

I have stripped version of Jetpack to be flashed into Jetson Nano SoM with 16gb emmc . How to flash the ISO into Nano SoM mounted on carrier board , as with the SDK manager I only see regular jetpack versions not the stripped version of Os

I’m not sure I understand what you are asking, but will give it a try. If you use command line, then flash will add whatever image you have. The trick is that you have to name the right target, and have your custom o/s image in place. What flash.sh looks for is a recovery mode Jetson of the correct type. You specify the target in the flash command, and flash.sh uses lsusb to see if the recovery mode Jetson of that type is present.

To illustrate, assuming you are using the eMMC model, a normal flash (from the Linux_for_Tegra/ directory, which happens to be the “driver package”, and is what SDKM uses as the back end during flash) would go something like this:
sudo ./flash.sh jetson-nano-emmc mmcblk0p1

If there is already a “Linux_for_Tegra/bootloader/system.img” file, then you could “reuse” this (or phrased differently, not erase what is already there and not replacing it with a new one generated from the “Linux_for_Tegra/rootfs/” content) with “-r”:
sudo ./flash.sh -r jetson-nano-emmc mmcblk0p1

When a normal flash occurs an ext4 formatted loopback file is generated which is the exact size of the partition (so approximately a bit less than 16GB file in your case). That content is mainly from a recursive copy (preserving permissions) from the “rootfs/” content, but flash.sh options will result in some boot content edit to “rootfs/” prior to that copy (e.g., the kernel Image file and an extlinux.conf file).

The generated image is renamed “bootloader/system.img.raw”, and then a smaller “sparse” image is generated at “bootloader/system.img” (the raw image is momentarily using that same name until it completes and is moved to a new name). The actual image to flash works perfectly well either as a raw or sparse image so long as it is named system.img and in the right place. Time to flash can go up a lot if using a raw image, but flash still succeeds without any other difference between raw and sparse.

The raw image exact byte size will be evenly divisible by 1024 either twice (MiB) or three times (GiB). If you use a raw image which is not the default size, then you would want to specify this in the flash command using the “-S size” option. For example, if the image size is 30064771072 bytes, then this is divisible by 1024 three times, resulting in 28, and is therefore “-S 28GiB”. Normally a custom system.img is created via a clone, but you might have a manually created image as well.

If your image does not have the updated “rootfs/boot/” content, then you could skip “-r” and placing the custom system.img, and could instead let system.img be created based on a modified “Linux_for_Tegra/rootfs/” content. Normally that content is the sample rootfs (pure Ubuntu) plus NVIDIA-specific hardware drivers (added with the “sudo ./apply_binaries.sh” step prior to flash), but you could use your custom image. The resulting new build of system.img would be a near exact match of your filesystem. The arguments to flash.sh would however copy some boot content in to your custom “rootfs/”, such as kernel Image and extlinux.conf, and flash this.

If your content is some stripped subset of the default content, and for example it might even have some “apt-get upgrade” in it or custom settings, then this content would be preserved. If your stripped image includes boot content, e.g., a custom Image, then this would need to be replaced in other subdirectories prior to flash if and only if your content is in “rootfs/”.

All I have is a single .img purge image .

As I was able to flash non stripped image from SDK manager , I have a folder :


Then I copied purged .img provided by Nvidia into bootloader/system.img

sudo cp /media/harshit/Data2/jetpack4.4-dp-nano-purge-sd.img bootloader/system.img

After that I run this command :

sudo ./flash.sh -r -k APP jetson-nano-emmc mmcblk0p1

Will appreciate any help/pointers

After I flashed using above steps , I cannot find anything on the display neither i can start oem-config

I think of “purged” as deleted or removed, so I’m not sure what you mean by purged. Possibly the “sparse” version which is smaller by not including empty filesystem?

The oem-config only runs on a Jetson which was freshly flashed and doing first boot. If you have a cloned image from a system which was already set up, then first boot already occurred and there is no use/need for another oem-config…the login account and settings are already in place for this case.

If the cloned image was from a system which had issues with oem-config, then the flashed system will also have the same issues when created from that clone.

If you flash with “-r”, then your image will be used instead of a newly generated image. The “-k APP” limits flash to just the rootfs partition, but this may not be what you want. The non-rootfs partitions must be valid as well, and there is little or no reason to not flash those other partitions along with the rootfs. If for some reason your clone is not the default size, and the other partitions are not flashed, then it is possible for partitions to overlap and corrupt. When flashing all of those other partitions at the same time, then you will know with certainty that the partitions fit together correctly in size. Try flashing with the “-r”, but leave out the “-k APP”, and see if this works better.

Additionally, make sure that the flash software is from the same release as that which created the original Nano install from which the clone was created.

Note that an SD image won’t work with an eMMC model. I see in the end you are trying to flash an eMMC model, but your earlier file name hints that this was from an SD card model.

1 Like

Thanks really appreciate for your help

Currently stuck with this : Jetpack 4.4 goes in restart loop after emmc falsh using sdk manager v (4.2)

could you extend what does “stripped image” mean, please?

I received purged image from someone in Nvidia which occupies less space on disk , stripped as in stripped file system .

But right now just trying to use default image whatever is downloaded using sdk manager

This is just the “sparse” clone, versus “raw”.

yes; there exist two type sof a filesystem image:
e.g. a clone image could be raw, e.g. made with dd,
or sparse - first made with dd, then processed by./mksrapse from Jetpack package. The latter is dramatically less in size