How to connect PCIe reset to any GPIO pin inside jetson virtual GPIO

[jitendra.kolhe]

Hi Nvidia,

We design our custom carrier board and using Jetson AGX ORIN Industrial Module.
We need C4 as Root Port and C5 as End point but, while designing the board our HW engineer forgot to connect
PCIe controller reset to PCIe ports.. We cant even probe those pins because its below ORIN module.
When we try to connect any PCIe device to C4 port its not detecting that device. For C5 which is end point so we connect to another motherboard which acts as Root port for C5 and there also its not detecting ORIN module.
see below schematics for reference where PEX_C4_RST, PEX_C5_RST not connected its NC.

By considering above situation our questions are -

1. Is PCIe reset is mandatory or not as per our observations its seems mandatory.
2. In TRM of ORIN under PCIe controllers section I found below page-

here its mentioned that RST as WAKE signals are connected to Virtual GPIO not Directly to SOC and some Software mechanism is doing reset task for PCIe controllers. Please correct me if I understood wrong.
3. If above mechanism is correct then there is a chance that inside SW is it possible to replace the actual reset pin with some another GPIO pins which can acts as a reset for PCIe controllers.

[carolyuu]

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

I’ll provide a comprehensive answer to your questions.

1. Is PCIe reset mandatory?

Based on your observations and the TRM (Technical Reference Manual) of the Jetson AGX Orin module, it appears that the PCIe reset is indeed mandatory. The TRM mentions that the RST (reset) signals are connected to Virtual GPIO, not directly to the SOC (System On Chip). This implies that the reset mechanism is handled by software, rather than being a purely hardware-based process.

In your case, since the PCIe controller reset pins (PEX_C4_RST and PEX_C5_RST) are not connected (NC), the PCIe devices are not being detected. This suggests that the reset signal is necessary for the PCIe controllers to function properly.

2. Understanding the reset mechanism

According to the TRM, the RST signals are connected to Virtual GPIO, which means that the reset mechanism is handled by software. This software mechanism is likely responsible for generating the reset signal for the PCIe controllers.

In the context of the Jetson AGX Orin module, the PCIe controllers (C4 and C5) are likely using a combination of hardware and software to manage the reset process. The Virtual GPIO connection suggests that the software is playing a crucial role in generating the reset signal.

3. Can the actual reset pin be replaced with another GPIO pin?

While it’s theoretically possible to replace the actual reset pin with another GPIO pin, it’s not a straightforward process. The TRM doesn’t provide explicit information on how to achieve this, and it’s likely that the software mechanism is tightly coupled with the hardware design.

However, if you’re looking to explore alternative solutions, you may want to investigate the following options:

• Check the Jetson AGX Orin module’s device tree configuration to see if there are any software configurable options for the PCIe controllers’ reset signals.
• Look into the Linux kernel source code for the Jetson AGX Orin module to understand how the PCIe controllers’ reset signals are handled in software.
• Consult with NVIDIA’s technical support or forums to see if there are any known workarounds or modifications that can be made to the software or hardware to achieve the desired behavior.

In summary, while the PCIe reset appears to be mandatory, the reset mechanism is handled by software, and replacing the actual reset pin with another GPIO pin may be possible but requires further investigation and potentially significant modifications to the software and/or hardware design.

[linuxdev]

This is not an answer, and I definitely can’t answer your specific question. However, I want to point out something which might save some time as you do resolve this: Most PCs treat the PCIe bus as hot-plug. Even after boot they are designed to detect a plug-in event. Jetsons can certainly do this, but you should know that as a power saving measure the hot-plug detect is disabled and unused PCIe is shut down once booted. This sometimes shows up because of people using FPGAs which boot slowly, and once booted the FPGA won’t show up because the plug-in detect is not on. In that case the device tree or other changes tend to be added so that PCIe can still detect a new plug-in after boot completes. Whatever the answer is, you should first make sure that lack of detection in earlier boot stages is not resulting in the detection mechanism being disabled via software as a power management option. I do not know the details of changing that.

[WayneWWW]

No, please follow our design guide and use specific pin,

It is mandatory and cannot be changed to other pin.

[jitendra.kolhe]

here I find the “reset-gpio” line in dts file what does it mean -

Instead of this >TEGRA234_MAIN_GPIO(AF, 1) pin
if I put something like this >
pcie_ep {
// …existing PCIe Endpoint node properties…
reset-gpios = <&gpio1 23 GPIO_ACTIVE_LOW>;
// …existing code…
};

lets say GPIO 23 then will this work or Jetson Architecture is not design like this?

[WayneWWW]

Hi,

Please clarify whether you are using EP mode or RP mode here.

Your first question is for RP mode. But you are checking a EP mode device tree node now.

[jitendra.kolhe]

I am using C4 as a Root Point and C5 is an End Point and both PCIe resets are NC in design.
hence I am exploring this options for both controllers that it is doable or not.

[WayneWWW]

This option is only working for EP setting.

RP side does not have such field. You must use the corresponding reset pin.

Also, “GPIO23” does not mean it is “23” in the device tree. If you just write “23”, you will just control a unknown pin.
Please modify things in the original source code but not the hex file from dtb.

[jitendra.kolhe]

So it is doable for EP as per my understanding.
Yes I agree with your 2nd point that for RP this field is not present. Hence we should use C4 reset only.

GPIO 23 is just an hypothetical example. The dts sample shared earlier it is taken from Original source from NV-public directory under Hardware directory.

we are using AGX Industrial module.

below is the current configuration loaded-
GPIO controller - GPIO_CTL3
GPIO ports - AF(40)*
Pad Control groups - PEX_CTL_2

is it possible to change this into-
GPIO controller - GPIO_CTL4
GPIO ports - G(4)
Pad Control groups - G4
GPIO pin- GPIO01 or 02

[WayneWWW]

You could move that to any GPIO. But you need to make sure the pinmux is correct by yourself.

[jitendra.kolhe]

In my design GPIO01 and 02 are test point pinmux settings for those 2 are as follows-

will this work?

[WayneWWW]

Are you talking about this GPIO setting would work or you are asking if you could use either GPIO01/GPIO02 here?

[jitendra.kolhe]

yes I am asking can GPIO01/GPIO02 will be use as reset for C5 ep or not?

[WayneWWW]

Yes you could use them.