The custom carrier board for Jetson Orin NX supports only PCIe 3.0

[yhlee1]

Hello,

The custom carrier board for Jetson Orin NX supports only PCIe 3.0. Flashing does not work with a message that the board information cannot be retrieved during the flashing step. Can I flash by accessing PCIe 3.0?

Thank you.

[WayneWWW]

Don’t know what you are talking about.

We only support to flash board with usb…

[yhlee1]

Hello,

sorry. I’ll give you the information again.
The m.2 SSD interface of our custom carrier board supports only PCIe3.0.
When you install an SSD that supports PCIe 4.0 on an m.2 SSD and try to flash Orin NX, the following PCIE error appears and flashing is not possible.

My guess is that the problem occurred because an SSD that supports PCIe 4.0 was installed on the m.2 E key interface, which only supports PCI3.0.
Can you give me some information that may help solve the problem? If there is any information you need, I will share it with you.

Thank you.

[WayneWWW]

Hi,

Yes, I need you to at least share the flash error log from both host side and uart…

[yhlee1]

Hello,

host side : start_the_flashing_process.txt (2.3 KB)
uart : pcie_error_log.txt (2.3 KB)

Thank you.

[WayneWWW]

Hi,

Always share your log from the beginning of flash or boot but not just give me a partial log…

[yhlee1]

Hello,

Sorry, but can you tell me where the flashing failure or success log is saved in the l4t directory?

Thank you.

[WayneWWW]

There is no such place… the log printed on the terminal after you run the flash command…
You need to copy it by yourself…

[yhlee1]

Hello,

host side :
OrinNX_flash_log.txt (257.7 KB)

jetson uart :
orin_nx_flash_uartteraterm.log (1.0 MB)

Thank you.

[WayneWWW]

Hi,

This issue is not related to flash. But just a pcie issue.

I am not sure if your PCIE3.0 is related to issue or not. The full analysis can only be done by dumping the PCIe LA trace.

If you don’t have equipment, please try other kind of NVMe and see if issue is still there.

Or you can try same nvme on Orin Nano devkit and see if devkit can hit this issue or not. If devkit cannot, then it would be your hardware problem.

[linuxdev]

Incidentally, if signal quality is a problem, then each faster PCIe version will fall back to a slower one. For example, if PCIe v4 is either not supported or not working due to signal quality, then it will fall back to PCIe v3. This is not an error. The AER (Advanced Error Reporting) log shows an actual error. Just to emphasize what @WayneWWW is saying, this is not related to v3 or v4. It is something else.

If this happens to have an effect on flash, which it should not (since flash might set up basic operation in recovery mode, but not actually rely on PCI), then it means something more fundamental is wrong. It could be wired wrong, or it could be that some device setup during flash is wrong. If this were a normally running Jetson, then I’d say that the device tree has likely routed lanes or physical addresses or other setup (such as BAR) incorrectly.

I have no idea if any device tree from flash is actually installed and run during the flash. So now I am curious, and have a question for WayneWWW: Is there ever a time during a recovery mode flash in which the flash software performs a device tree (or similar) install which actually has an effect during the flash (versus after flash)?

[yhlee1]

Thank you so much.