Xavier NX JP 5.1.1 ASSERT[nvmExpressDxe] in NvmExpressHCI.c(772)

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

I have successfully flashed a Xavier NX eMMC on a p3509 carrier, and it boots to desktop just fine.
Then, when I move the SOM over to my custom carrier board, it doesn’t boot.
I connected the UART logs, and get the attached log (which starts mid-reboot and goes to the hang just before bootloop).

After the line:
Jetson UEFI firmware (version 3.1-32827747 built on 2023-03-19T14:56:32+00:00)

There are many LF characters, and a delay of about 10 seconds, then
ASSERT [NvmExpressDxe] /out/nvidia/bootloader/uefi/Jetson_RELEASE/edk2/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c(2

I have tried:

  • Editing the L4TConfiguration.dtbo as described here, file by decompiling, changing the boot order to “emmc,sd”; and recompiling.
  • Re-building the UEFI in debug mode, as described here:

Neither of these helped. I still get the same assert on custom board.

Are there any options I can change to remove NVMe support entirely? We do not plan on booting from or using an NVMe drive, so if there is a way to remove all NVMe code, that would be fine with me. We just need to boot from eMMC.

Another note: this build works fine on p3509, whether it has an NVMe SSD loaded or not.
There is no NVMe on my custom board.

2

Disable pcie controller in your device tree. UEFI will also get PCIe disabled too.

3

Wayne,
Ok, I can try that. However, we do use PCIe in the application OS. We don’t use NVMe, but we do need to communicate over x4 lanes of PCIe.
How can I load PCIe later, in the OS, to use it?

4

Hi,

Basically you are doing same thing as this post but just different interface. This post is UART and your case is PCIe.

5

Wayne, thanks for the link, that did solve my problem!
This is what I did to fix it:
I removed the check on board type in flash.sh by commenting line 2327 and 2329:

mkfilesoft tscfwfile    "${TSECFW}"  "";
mkfilesoft tbcdtbfile "${TBCDTB_FILE}" "${DTB_DIR}/${DTB_FILE}";
#if [ "${CHIPID}" = "0x23" ]; then
mkfilesoft tbcdtbfile "${TBCDTB_FILE}" "${DTB_DIR}/${TBCDTB_FILE}";
#fi;
if [[ ("${target_partname}" == "" || "${target_partname}" == "recovery-dtb") \

Next, I ran

dtc -I dtb -O dts -o toEdit.dts bootloader/tegra194-p3668-<myCustomBoard>.dtb

Then I opened the file in a text editor, and found all instances of “pcie@xxxxxxxxxxx”. Under each instance, I changed each line
status=“okay”;
to
status=“disabled”;
Then re-compile the DTB with a new name

dtc -I dts -O dtb -o /bootloader/tegra194-p3668-<myCustomBoard>_TBC.dtb toEdit.dts

Then I edited <myCustomBoard>.conf.common, changing the line for TBCDTB_FILE to
TBCDTB_FILE=tegra194-p3668-<myCustomBoard>_TBC.dtb
So now I have the original tegra194-p3668-<myCustomBoard>.dtb next to the tegra194-p3668-<myCustomBoard>_TBC.dtb, for the UEFI.

When I ran a full flash. I saw it use the TBCDTB_FILE, and UEFI did not hang. It booted to desktop for configuration!
Once configured and logged in, I ran

cat /sys/firmware/devicetree/base/pcie@xxx/status

and some reported okay as before, like the desktop OS should!
Since there were no errors in UEFI boot any more, and PCIe worked in desktop mode, it looks like this is the answer.
Thank you.

1 Like
6

Glad my issue helped others :)

2 Likes
7

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