Tegra194-pcie 14160000.pcie: Phy link never came up Error on jetson orin nano custom carrier board

We have designed the custom carrier board taking as a reference the Jetson Orin Nano’s dev kit reference carrier board (P3768-0000) schematics.
Our Custom carrier board’s main differences with respect to reference carrier board (P3768-0000)
• Doesn’t have EEPROM.
• HDMI port instead of DP
I have flashed the p3509+p3767 config to use with hdmi port as discussed in other topic.

I connected the module to jetson orin dev kit’s carrier board and noticed pcie link was up and running in the uart logs .However with the our custom carrier board i notice this error “tegra194-pcie 14160000.pcie: Phy link never came up”.
We have compared the hw schematics and so far do not notice any differences on the pcie relevant signals.
Could you please help me in debugging on the FW side regarding this pcie issue (like any feedback ,or info from the drvier pointing out the root cause).I am sharing the dmesg logs of Jeston orin nano+ customer carrier and also jetsonorin nano +dev kit carrier.
with jetson orin nano carrier_dmesg.txt (69.8 KB)
custom carrier _dmesg.txt (61.9 KB)
Thank you for your time

Hello,

Your topic will be best served in the Jetson category.

I will move this post over for visibility.

Cheers,
Tom

If we don’t care about HDMI for now and flash with p3768+p3767 board config, will your PCIe C4 work?

Hi,
Yes i have tried with the original dev board config files and the PCIe C4 gave the same Phy link never came up Error.

Try other pcie device to test first.

Hi ,Its not very clear to me you suggestion to test with a pcie device, could you please elaborate on how to check the pcie link issue of the jetson module when interfaced with our carrier board.
Thank you

Some basic checks that no need extra knowledge.

  1. Not every PCIe device may work fine. That is why you need to change pcie device to test. But not always keep using same device.
    Again, it is just for checking pcie controller configuration. Just debug purpose.

  2. If (1) is correct and other pcie device can work, then software side configuration is done. No need to dig into device tree or pinmux. They are correct.

  3. If (1) does not work either, review your hardware design first because same software configuration could work on NV devkit. As I already asked you to flash with p3768 board config.

Hi Wayne,

Currently we do not have any pcie device connected to the custom carrier board.
We tried the SW with the jetson orin dev kit with out any pcie device and noticed that PCIe link comes up during boot .
Its not a single device that doesnt work ,we are trying to debug why the PCIelink never comes up with our carrier board (We have not modified the pcie part on our carrier board ).
We notice that nothing attached to PCie bus comes up at all that are present on the module.
We are unable to connect to ethernet on our carrier board ,i was wondering if this has something to do with PCIe link never being up .

Thank you for your time

What does that mean link comes up when there is no PCIe device connected?

What signal are you using to tell it is up or it is not up?

Hi Wayne,
We have Jetson orin nano dev kit (p3767- SoM and p3768 Carrier board) and then we have our custom carrier board (CCB).
We know that on the SoM there is an ethernet NIC connected to the processor via PCie bus ,while the ethernet connector is on the carrier.

On our CCB we have no PCIe peripherals connected, we have only replicated the barebone circuitry need to place the ssd slots but nothing is connected to them.
We also have the Ethernet connector attached to the same NIC that is present on SoM .

Using the same SW image on the SOM, the pcie behaves differently when we connect to the P3768 Carrier and our ccb:

  • on p3768 pcie comes up normally, NIC is working and showing up in lspci.
  • on ccb, nothing is showing in lspci, and we have that error in the log ("Phy link never came up ").
    I have attached logs at the beginning of the post.

We are trying to understand where the problem is ,and how our CCB is preventing the PCIe host from working at all (because it’s preventing a device (eth NIC) that is not on the carrier from working). We have replicated the HW design regarding the PCIe connectivity as it is from the P3768 carrier board, so we expected it to work the same way.

Thank you

Hi,

Just to clarify…

  1. Each PCIe controller is independent. Your topic was for PCIe C4 and now you are asking question for PCIe C8. Try not to miss the target here. Your fix on ethernet NIC (pcie C8) won’t really fix the issue n PCIe C4.

  2. PCIe C8 is most likely a hardware issue. This part of software is already done. No need further change. (Unless you messed up the pinmux of this part).

  3. There is PCIe debug tips over here.

https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/HR/JetsonModuleAdaptationAndBringUp/JetsonAgxOrinSeries.html?highlight=pcie#debug-pcie-link-up-failure

Hi Wayne,

Apologies for the confusion ,Just to clarify none of the PCIe links are coming up (C1,C8,C4) on our CCB when interfaced with SoM.
We noticed that (C1,C8 )PCIe links are up when the SoM is interfaced with the P3768.

I am wondering why both the C1,C8 links are not up on our custom carrier board ,if they are independent .
For the CCB we kept the same pinmux as the P3768 as the pin connections and schematics are same.

Thanks

For such case… read above debug tips and measure from hardware signal first…