Difference Between Using SDK Manager and SD Card Method to Install JetPack?

I was trying to install JetPack 4.6.1 on a Jetson Nano dev kit using the SD card method and ran into some problems finalizing the setup (just like this one), so I thought I would try the SDK Manager method. That worked fine, and the Jetson was able to complete the setup and boot properly without much hassle.

However, when I took the SD card and moved it to another Jetson, it wouldn’t boot. So is there a difference between how the SDK manager flashes the Jetson and how Etcher/dd does it? My ultimate goal is to have a base JetPack image + some custom code that I can create an image of and clone across multiple SD cards.

By the way, I eventually went back and was able to complete the SD card method with JP4.6.1 by finishing the setup in headless mode.

You can divide the software into basically two parts: (A), The part which is used for boot, and (B), the part which is the root filesystem/rootfs and which Linux runs from. The boot part of an SD card model actually resides on the module itself in QSPI memory, and only the rootfs lives on the SD card (in older releases part of the boot software also lived in partitions of the SD card, but even then it was only part of this).

The software living in QSPI can only be updated with JetPack/SDKM. The release version of the QSPI does not change a lot, but it does need to match a certain range of releases the SD card is flashed with. You can choose to flash just the QSPI with a given release, and then your SD card will work with that unit.


Thanks for the great explanation @linuxdev!

So if I were to follow the SD card installation method on a dev kit, how does the module make sure it’s QSPI version is compatible with whatever I put on the SD card?

I will have to try updating just the QSPI via SDKM as you suggested.

If you use sdcard image that is after (including) jp4.6 version, and then if your device is able to boot into ubuntu, the sdcard image will upgrade the QSPI sw version in the background. This will make sure the QSPI version is 100% matched.

If you cannot boot into system, then you know the version is not compatible.

If you want to make sure it would 100% work, then directly use sdkmanager, it will make sure the version is matched.

1 Like

I see. I am upgrading from JP 4.4.1 to 4.6.1 and can’t boot, so that must be a good indicator that the QSPI version is mismatched.

Thanks again for the explanations!

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