PCIe Network Card is not getting Detected by SOM with Custom carrier board of Jetson AGX orin which is running with Jetpack 5

we have designed Carrrier board for the Jetson AGX orin from the reference of P3737 design files.
we have changed the PCIe Connector from the X16 to X8 , anyway we connecting x8 bus to the SOM right in the P3737 also.
I have tested that all required voltages for the 12V 3.3V and +3.3V aux also coming up to the PCIe slot. then why adaptor is not getting enumarated by the SOM.

FYI, i am not getting “PCIE_3V3_EN” so, i have removed that Ic U127 and shorted pin 5 to pin1. so that 3.3V aux also going to PCIe slot.

actaully this is the actually what we have changed with x8 PCIe connector from x16.
Jeston_custom_PCIe_x8_connector.pdf (142.1 KB)

please inspect these logs provided below, this on custom carrier board
pci_log.txt (23.9 KB)

this is from Dev kit carrier board, but with same SOM.
pci_log_on_dev_kit.txt (25.5 KB)

actually, i have tested PCIe card with Dev Kit, their SOM is able to enumerates the Card.

are any Device tree configuration needs to be changed to PCIe to work with x8 PCIe slot?

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, I’ll address the question and provide a comprehensive answer.

The issue at hand is that the custom-designed carrier board for the Jetson AGX Orin, which is based on the P3737 reference design, is not enumerating the PCIe adapter. The design changes made include:

  1. Changing the PCIe connector from X16 to X8.
  2. Connecting the X8 bus to the SOM.
  3. Verifying that the required voltages (12V, 3.3V, and 3.3V aux) are present at the PCIe slot.
  4. Removing the U127 IC and shorting pin 5 to pin 1 to ensure the 3.3V aux voltage is present at the PCIe slot.

Despite these changes, the SOM is not enumerating the PCIe adapter.

To troubleshoot this issue, let’s compare the custom design with the original P3737 reference design:

  1. PCIe connector: The original P3737 design uses an X16 PCIe connector, while the custom design uses an X8 connector. Although the X8 bus is connected to the SOM, it’s essential to verify that the device tree configuration is updated to reflect the change in PCIe lane configuration.
  2. Device tree configuration: The device tree configuration might need to be updated to accommodate the change in PCIe lane configuration. The original P3737 design might have a device tree configuration that assumes an X16 PCIe connector. The custom design should update the device tree configuration to reflect the X8 PCIe connector.
  3. PCIe voltage rails: The custom design has verified that the required voltage rails (12V, 3.3V, and 3.3V aux) are present at the PCIe slot. However, it’s crucial to ensure that these voltage rails are properly connected to the PCIe adapter and that the adapter is powered correctly.
  4. U127 IC removal: The removal of the U127 IC and shorting pin 5 to pin 1 might have affected the PCIe adapter’s power-up sequence. It’s essential to verify that the PCIe adapter is powered correctly and that the power-up sequence is not affected by this change.

To resolve the issue, I recommend the following steps:

  1. Update the device tree configuration: Update the device tree configuration to reflect the change in PCIe lane configuration from X16 to X8. This might involve modifying the device tree source files or updating the device tree binary.
  2. Verify PCIe voltage rails: Double-check that the PCIe voltage rails (12V, 3.3V, and 3.3V aux) are properly connected to the PCIe adapter and that the adapter is powered correctly.
  3. Verify PCIe adapter power-up sequence: Ensure that the PCIe adapter’s power-up sequence is not affected by the removal of the U127 IC and the shorting of pin 5 to pin 1.
  4. Test with a different PCIe adapter: Try testing the custom carrier board with a different PCIe adapter to rule out any issues with the specific adapter being used.

By following these steps, you should be able to identify and resolve the issue preventing the SOM from enumerating the PCIe adapter.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

please do not grep anything. Just share the full log.

dmesg_log_with_PCIe_card.txt (66.2 KB)
dmesg_log_without_PCIe_card.txt (65.9 KB)
please review this.

Did you configure the device tree for this regulator after you remove this hardware design from your board?

We did not configure anything.

Does it really required to configure in device tree to disable this.
If we are not doing it. Will not PCIe work?

Just we are bypassing the controller of 3.3V supply to the PCIe card right? Does it matter to disable?

Thanks

Default device tree explicitly configure a GPIO to control that 3v3 regulator.

If you don’t change device tree, then our software will still try to configure that hardware pin during init. I would say you better removing it.

Okay, thank for the response.

I will do that.

Even if we are not doing also, we should get the PCIe card detection right.

Thanks

Even if we are not doing also, we should get the PCIe card detection right.

Nope, I don’t guarantee that.

Okay,

How to disable that. I hope this disable this feature is not mentioned in the adaptation and bring up guide.

Could you provide the steps to do it?

Thanks

In pcie C5 141a0000,

                    vpcie3v3-supply = <0x116>;

change this regulator to a always-on regulator one if your design is a always on one.

And regulator is part of linux kernel. If you don’t know how it worked, then reading online Linux kernel tutorial might help.

Sure, I will do and let you know

Thanks

I’m now able to get the PCIe card detected. I did not change any configurations for this — it turned out to be a hardware issue. The PCIe connector was not soldered properly.

Thank you very much for all the support you provided throughout this troubleshooting process.

Thanks again,
S. Sai Kiran

1 Like

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