Similar to these two issues 1 and 2, My custom carrier card flashed with JetPack r35.4.1 will not boot from our soldered on NVMe drive. The flashing process finishes successfully and we had previously used the nvme drive as storage on the Xavier NX but are now having to use it as the primary boot drive for the Orin Nano.
The device shows in uefi shell when running pci. I enabled many uefi logs and found this error in them.
Can you please boot the device with a USB drive, login to the system, and see if the NVMe drive can be detected as /dev/nvme0n1?
Or verify the same NVMe drive with a DevKit as the carrier board.
I don’t feel like you are supposed to do this before validating the compatibility.
I can try and boot with a usb drive. We have been using this carrier card successfully with the TX2 NX and Xavier NX, but both booted from emmc and used the nvme IC for extra storage.
Notably the Admin section says there is 1 queue for submission and completion, but the source code for the Creation of the completion queue has a for loop that goes around twice 1 to index < NVME_MAX_QUEUES which is 3. On the second iteration there is a failure to send the Command Packet using the Passthru protocol.
I was able to boot the NVMe drive by making modifications to the edk2 source code. The core change was reducing the loop upper bound from NVME_MAX_QUEUES to 2 in both the NvmeCreateIoCompletionQueue and NvmeCreateIoSubmissionQueue functions. I also added a bunch of print statements for locating the issue. Use this patch at your own risk, but it did work for me to get around this issue temporarily. I have no idea what effects it will have on other NVMe drives.
Do you know what firmware version you updated to? I did just today find out that there was a firmware update available but it didn’t appear to list my issue in it’s changelogs.
I used the “M05” version, specifically from a file named “2100AI-AT_FFU_to_MU05.zip”. I see Micron has released a M05.1 version recently, but I haven’t tried that yet.