We are setting up 50 new Orin NX 16Gb modules in our custom devices.
We have found that out of the box the modules won’t boot up (from NVME) in our devices unless they have already been flashed. Reading this topic it seems the modules need (out of the box) to first be flashed together with an SSD so they can boot from SSD:
That seems very inefficient from a production perspective as we couldn’t for example change out a faulty Orin module with a new one into an existing device unless we flashed that new Orin module with another SSD to tell it to boot from NVME?
Is that right or is there another way to flash the module without connecting an SSD? Or is there a command to run to flash just the Orin module (and not affect the SSD)? Or better still why don’t they come from the factory already set to boot from NVME?
Sorry if I’ve misunderstood something here. And if so please point me to the solution. Thank you.
I can’t give you a good answer, but this is probably relevant and useful to you (random trivia, not in a particular order):
SD card models (or I should instead say models without eMMC) all have QSPI memory on the module itself (there might be QSPI on some eMMC models as well). The SD card or external drive, so on, will contain only the rootfs (o/s) on those models.
Jetsons (and most embedded systems) don’t have a BIOS. So that content is in software, and in this case it is on the QSPI memory.
Not all QSPI software releases are compatible with all SD card releases (or SSD/NVMe), so you need to flash QSPI before you “know” it should work.
There is no guarantee of what is in QSPI when purchased. I personally consider “always flash this”.
Many people think of the boot content as only bootloader. This is far from the case, and you are essentially also performing a BIOS flash (if it had a BIOS) during normal QSPI flash. I want to emphasize that this is not just bootloader content. The state of the system created from this is inherited by the bootloader, and then the state of the bootloader is inherited by the Linux kernel. Not all content is directly set up when Linux runs, so you kind of need to make sure that everything inherited is from a compatible software release.
Since there is no BIOS, there is no real function to detect boot devices. The QSPI more or less contains a pointer as to where to look for the first boot device. Possibly that device can chain load other media, but unless you flash, it is possible the only media ever examined will be the SD card (which you might not have).
The initrd is something of an “adapter” for the transition from boot to Linux. As an example, ideally, the boot software understands the ext4 filesystem type and the GPT partition scheme. In that case it could read the Linux kernel from any partition which is ext4. However, to avoid requiring everything the kernel needs be inside the bootloader, e.g., accessing loadable modules (especially if we use a non-ext4 filesystem, and the modules are on some other filesystem type, e.g., XFS), the initrd filesystem tree is always understood by the bootloader, and a miniature boot environment can be added to the initrd (e.g., modules for reading some other filesystem type like XFS); then the module needed for future content read is loaded from a very basic environment. *Sometimes chain loading or boot options the bootloader itself cannot directly provide by the Linux kernel is added into the initrd. You will find that most external media boot mandates an initrd which is generated knowing about where pointers should aim to find the rootfs (or the initrd, or both). If there is more than one possible boot content, e.g., SD card is included, then the SD card is assumed (for SD card models, which means the SD card slot is on the module itself, and not on the carrier board; third party manufacturers with the SD card on the carrier board are not SD card models).
Note that on eMMC models that one can enable secure boot keys by burning fuses. In that case the Linux kernel and other content (prior to the rootfs) must come from partitions or QSPI. Outside of burned security fuses, one often just reads the kernel, device tree, so on, directly from the “/boot” partition. You won’t have the option to burn fuses if this is not an eMMC model.
I’m sure there’s a lot more needed, which I can’t answer, but that gives a basis to start with.