Flashing QSPI only does not enable booting from NVMe on 4.6

I’m trying to prepare a painless way to flash multiple Xavier NX eMMC SoMs with the minimum necessary content to enable it to boot directly from NVMe. The following describes my experience with a fresh SoM received from the factory.

I was hoping that this would work because we can boot directly to NVMe with Jetpack 4.6 now.

What I did was run sdkmanager from within docker (known to work to flash eMMC properly) and proceed until the “SDK Manager is about to flash your Jetson Xavier NX module” step.

Then I went into the ~/nvidia/nvidia_sdk/JetPack_4.6_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra directory and ran sudo ./flash.sh jetson-xavier-nx-devkit-qspi mmcblk0p1

This ran successfully and took 203 seconds to complete. I then try to boot it up with a known working NVMe but it shows no signs of life.

Could somebody confirm whether flashing qspi is sufficient for this use case? It sounds like something needs to be flashed to eMMC as well to make this work. This would be fine, I just want to minimize the time taken, as we have no use for booting to eMMC at all at the moment and it would be nice if the flashing could take only a few minutes rather than the full 10 or 20 minutes it takes to get the full OS onto it.

Also, I am curious about the “Step 7. Storage Device:” where “Custom” could be chosen and an example of “./nvautoflash.sh --storage nvme0n1p1”. This is mysterious. I can look at this script file but it does not explain its purpose or what can be done with it. When I run sudo ./nvautoflash.sh --print_boardid I receive back jetson-xavier-nx-devkit-emmc found. This may be useful, could some nvautoflash.sh incantation get me there?

Alternatively, I know that a massflash procedure exists. However, I’m not able to do anything with it yet because I do not understand what all the FUSELEVEL=fuselevel_production stuff means and I don’t want to brick any of the SoMs I have.

After I clicked Flash from the SDK Manager and it took 20 minutes to flash the full OS to the eMMC, it booted up automatically straight away into the environment set up on the NVMe. (By the way, I thought this was interesting given my recovery jumper was still connected at this time.) This certainly makes sense because the CBoot config by default checks NVMe first and its extlinux.conf states to boot NVMe by default.

Thanks for your attention.

flash.sh is not able to flash anything to external drive.

nvautoflash.sh is able to do, but the whole system needs to be jp4.6 version.

Thus, only qspi got updated is not sufficient.

I’m not asking about getting the OS onto the NVMe. I can clone NVMe external to these tools.


Sorry for the late response, is this still an issue to support? Thanks

Thanks for the response. I have independently conversed with user “linuxdev” in private messages and he showed me that there are many partitions on the eMMC that need to be flashed in order to support enough of the boot process to boot off NVMe. My priorities have shifted and we may not actually be booting off NVMe for the time being. We are moving forward with the massflash procedure and booting our product off eMMC. So, although this question is still open, and an authoritative answer is encouraged, I do not need assistance on this topic at this time. Thanks.

Thanks for your response, I will close this topic for now.
If required, we can re-open or have a new one.

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