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.