Ethernet Port Not Waking Up in Custom Carrier Board

Hi,

I designed a custom carrier board. The Ethernet port and routing of MDO signals are the same of your original carrier board together with the pinmux file. The only difference is that I am not using any of the PCIe ports, so everything related to PCIe (except for the PCIe wake signal strapped high) is not connected. All ports (USB and DisplayPorts…) are working fine except for the Ethernet Port, which differently from the PCIe ones, I do need.
I noticed this error when debugging the board through the UART interface: “tegra194-pcie 14160000.pcie: Phy link never came up”. I know the Ethernet controller in your module is connected by means of the PCIe bus.
I was wondering if you have any glance why this is happening. Some thoughts & questions on the issue:

  1. Is there any enable pin for ethernet which needs to be high which I missed?
  2. is there any power sequencing requirement for that PCIe link (C8) connected to Ethernet to wake up?

I already tried all the debug steps in the developer guide documentation.

Thanks in advance for the kind support

Hi Riccardo,

Which adapter type and switch are you using? Are these Nvidia products?

I am using the Jetson Orin Nano module, it has the Ethernet Bridge Embedded, I am not using any other external switch or adapter. My Custom Carrier Board has just the RJ45 connector routed to the same pins of your reference carrier board.

Hi, kind reminder. I just want to know whether any PCIe control pin (PERST, WAKE, CLKREQ, ecc…) needs to be at a determined state to wake up the Ethernet Controller or the power sequencing timings have any impact on the waking up of the Ethernet Controller on the Jetson Orin Nano Module. Thanks.

Just a clarification.

Orin Nano module is using PCIe for the ethernet. This part is a fixed software solution which you should not modify. If you already modify something, please restore it back.

Also, the PCIe for this Etherent is C8 but the log you are worried here is C4, which means totally not need to care about it.

“tegra194-pcie 14160000.pcie: Phy link never came up”. (THIS IS PCIe C4)

Hi,

It’s not just PCie 14100000; also other PCIe relevant links as140a0000 don’t come up. We have not modified anything at the sw level relevant to PCIe .

Just to check the status of the link we tried adding/removing the wifi module, the original carrier board was functioning correctly, whereas for the custom carrier board the link was never up.

PCIe With original carrier-Wi-Fi module connected With Original carrier –Wi-Fi module disconnected With custom carrier -wifi module disconnected With custom carrier -wifi module connected
14100000 Link up Link never up Link never came up Link never came up
14160000 Usb-(link never up) Usb-(link never up) Link never came up Link never came up
140a0000 Link up Link Up link never came up link never came up

Please find log taken from the uart serial console when our custom carrier board was interfaced with a wifi module.
custom_carrier with wifi.txt (45.5 KB)

Hi,

Then I think you should review the hardware design with design guide document.

Also, please try focus on one pcie controller to handle first. Do not try to resolve everything all at once.

BTW, I am not quite sure about the some content of the table you shared either.
For example, what is usb-link never up?

Hi,

The Design guide document was changed recently, where the part relevant to power sequencing was updated. Could you please confirm us if the behavior of the PCIe controller is impacted by how the power sequencing occurs.

What are the hardware level details to take into account in a custom carrier board when dealing with the PCIE controller of the ethernet bridge?

Please ignore the USB link part ,it was only an observation collected in tabular format of the different tests we have done.

Thanks in advance,

Is there any software change when using on NV devkit and when using on your custom board related to PCIe C8?

We did not change anything on the software side related to PCIe C8

Then there should be some hardware difference b/w your design and reference that caused such issue. The difference may be not limited to Ethernet or PCIe design itself. You can refer to the checklist sheet, which is attached in the Design Guide doc, to review your design based on the items in the sheet one by one.

These unused pins can be left unconnected as you can see in the chapter 14.1 Unused Multi-Purpose Standard CMOS Pad Interfaces in Design Guide.

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