[Jetson AGX Orin] How to Identify MMIO Address and Verify Pinmux for DP83867 Reset via GPIO

I am attempting to control the TI DP83867 reset pin using a GPIO from the SoC.

Specifically, I connected soc_gpio18_pg5 to the DP83867 reset pin and tried to toggle it via software. However, it doesn’t seem to behave as expected.

So I configured the pinmux as follows:

soc_gpio18_pg5 {
nvidia,pins = “soc_gpio18_pg5”;
nvidia,function = “rsvd0”;
nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_DISABLE>;
nvidia,lpdr = <TEGRA_PIN_DISABLE>;
};

Now I would like to verify if this configuration has been correctly applied by reading the MMIO registers directly.

What is the MMIO address of this pin (soc_gpio18_pg5)?

I want to read the pinmux register value and understand what each bit means.

I also don’t understand why this information is not clearly documented in the datasheet or TRM.

From the kernel logs or GPIO debug, the GPIO number appears to be 388.

Additionally, I would like to know:

The base MMIO address of the GPIO controller handling GPIO 388.

The offset address of the output register for this GPIO.

The expected values when the pin is set to low or high output.

Any help or references to the register map would be greatly appreciated.

I am using JetPack 6.0 / L4T R36.4.3 on Jetson AGX Orin.

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

To address your questions and provide a comprehensive answer, we’ll break down the process into steps, comparing and contrasting where necessary, and providing detailed explanations.

Understanding the GPIO Number

First, you’ve identified the GPIO number as 388 for the pin soc_gpio18_pg5. This is crucial because it allows you to find the specific MMIO addresses for controlling this GPIO.

Finding the Base MMIO Address

The base MMIO address of the GPIO controller can be found in the kernel boot log or through the use of gpio debugfs. For the Jetson AGX Orin, the base address for the GPIO controller is typically noted in the kernel boot log as tegra234-gpio at base index 348. This value is specific to the Tegra234 SoC used in the Jetson AGX Orin.

Calculating the Pin Number and Understanding the GPIO Controller

You’ve already calculated the pin number using the formula base + port_offset + pin_offset, which resulted in GPIO number 388 for soc_gpio18_pg5. This calculation is essential for navigating the GPIO controller’s register space.

MMIO Address for the GPIO

The MMIO address for a specific GPIO pin can be calculated by adding the base address of the GPIO controller to the offset of the register that controls the pin. For Tegra SoCs, the GPIO registers are typically laid out in a specific pattern:

  • The output register for a GPIO is usually at an offset of 0x00 from the base address of the GPIO bank that the pin belongs to.
  • Given that the GPIO number is 388, and assuming a standard 32-bit register width, you would first need to determine which GPIO bank this pin belongs to. The Tegra234 GPIO controller is divided into banks, each controlling a range of GPIOs.
  • The offset within the bank for the output register of a specific GPIO can be calculated or looked up from the datasheet or reference manual. However, the exact offset might depend on the specific SoC and its configuration.

Expected Values for Low or High Output

When reading or writing to the output register for a GPIO, the expected values depend on the configuration of the pin:

  • Low Output: Typically, setting the corresponding bit in the output register to 0 will set the pin to a low output.
  • High Output: Setting the bit to 1 will set the pin to a high output.

However, the actual bit-to-pin mapping and the behavior (e.g., open-drain vs. push-pull) depend on the pin’s configuration, which can be set using the pinmux as you’ve done.

Documentation and References

The lack of clear documentation in the datasheet or TRM (Technical Reference Manual) for specific MMIO addresses and register maps is not uncommon. SoC vendors like NVIDIA often provide detailed documentation, but the complexity and customization options of these devices mean that not all information can be easily found in a single document.

For the Jetson AGX Orin and other Tegra-based devices, NVIDIA provides various resources, including the TRM, datasheets, and developer forums, which can be invaluable for finding the necessary information. Additionally, the Linux kernel source code and device tree files can provide insights into how the hardware is configured and accessed.

JetPack and L4T Versions

You’re using JetPack 6.0 / L4T R36.4.3 on Jetson AGX Orin. These versions are specific and might have their own set of documentation, patches, or known issues that could affect how GPIOs are accessed or configured. Always refer to the latest documentation and release notes for your specific version of JetPack and L4T.

Conclusion

To verify your configuration and read the MMIO registers directly for soc_gpio18_pg5 (GPIO 388), you would:

  1. Find the Base Address: Confirm the base MMIO address of the GPIO controller from the kernel boot log or gpio debugfs.
  2. Calculate the Offset: Determine the offset within the GPIO bank for the output register of GPIO 388.
  3. Read/Write the Register: Use the calculated MMIO address to read or write the output register, setting the pin high or low as needed.
  4. Consult Documentation: Refer to the Tegra234 TRM, Jetson AGX Orin documentation, and Linux kernel documentation for detailed information on GPIO configuration and access.

Given the complexity and the specificity of the question, direct calculation or lookup from provided documents might not yield the exact MMIO address without additional context or clarification on the GPIO bank structure and register layout of the Tegra234 SoC.

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

Hi thpark19,

Above response should give you some insights of GPIO.

Are you using the devkit or custom board for AGX Orin?

Jetpack 6.0 is L4T r36.3.0
Jetpack 6.2 is L4T r36.4.3
Which one are you using?
Please run cat /etc/nv_tegra_release to check

This pin is configured as unused in pinmux spreadsheet by default.
image
Please run the following command to check its pinmux register:

$ sudo busybox devmem 0x02434078

I am using a custom board that is based on the official development kit.
We replaced the DisplayPort with micro HDMI,
and changed the Ethernet PHY from Marvell to TI’s DP83867ISRGZ.

The reset pin of the Ethernet PHY is controlled using a SoC GPIO,
but it is not behaving as expected, so I am seeking assistance for debugging.

We are currently using JetPack 6.2 with L4T R36.4.3 for Industrial
(apologies for providing inaccurate version information in a previous inquiry).
If development time allows, we plan to upgrade to R36.4.4.

You previously shared the MMIO address of the pinmux register.
When I read the register using:

sudo busybox devmem 0x02434078
I get:
0x00000008
We are using the following pinmux configuration file for the industrial version:

tegra234-mb1-bct-pinmux-p3701-0000-a04.dtsi
In that file, I configured the pin as follows:

soc_gpio18_pg5 {
nvidia,pins = “soc_gpio18_pg5”;
nvidia,function = “rsvd0”;
nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_DISABLE>;
nvidia,lpdr = <TEGRA_PIN_DISABLE>;
};

My Questions:

  1. What value should be written to the PADCTL register for the configuration above?
    The current value 0x00000008 seems incorrect.
    I expected this pin to be configured as GPIO output with pull-up,
    but based on the bit fields, 0x08 may indicate something else.

  2. Could you clarify the PADCTL register bit field format?
    This would help us better understand whether the configuration is being applied correctly.

From other sources, the PADCTL (Pad Control) register format is said to be:

Bit Range Field Name Description
[1:0] PULL 00 = none, 01 = pull-down, 10 = pull-up
[2] TRISTATE 0 = output enabled, 1 = tri-state
[3] ENABLE_INPUT 0 = input disabled, 1 = input enabled
[4] LPDR Low Power Driver enable
[6:5] SCHMITT Schmitt Trigger enable
[9:7] DRIVE_STRENGTH Drive strength
[12:10] FUNCTION Pin function (000 = GPIO, 001 = SFIO, etc.)

According to the PADCTL register format, the expected value for my current configuration is 0x00000002.
However, the actual value read is 0x00000008, which does not match the expected setting.

  1. Why is the signal level LOW even though pull-up is enabled and tristate is disabled?
    This pin is not used by the devkit, but we are using it on our custom board as a GPIO output to control the reset line of the TI DP83867ISRGZ.

Even though we have enabled internal pull-up and configured it as output,
the oscilloscope still shows the pin level as LOW, which is unexpected.
Also, when I check the value in the kernel using gpio_get_value(388), it returns “0”.

This behavior contradicts expectations and is very confusing.

  1. Could you also provide the MMIO address to read or write the GPIO output value for GPIO 388?
    We would like to directly verify the GPIO output register,
    aside from relying only on gpio_get_value() in the kernel.

Thank you in advance for your support and clarification.

It indicates RSVD0, PULL_UP, PASSTHROUGH, DISABLE INPUT, GPIO.

It matches your configurations.

You have to configure Output/Drive 1 in pinmux spreadsheet as following.
image
Please also check tegra234-mb1-bct-gpio-p3701-0000-a04.dtsi for GPIO related configurations.

No, [1:0] as 00 means RSVD0 while [3:2] as 10 means pull-up.

Do you want to perform DRA to control GPIO for PG.05?

Sorry about the confusion earlier.

I also just confirmed from the documentation that 0x00000008 is indeed the expected value.

According to the Orin Technical Reference Manual (Orin-TRM_DP10508002_v1.2p.pdf), on page 6118 under section “8.4.4 G3 PAD Control Registers”,
the expected value appears to be 0x00000008.

Here is the bit field definition from the document:

Bit Field Name Description / Value Range
[12] E_SCHMT 0 = Disable, 1 = Enable
[11] RSVD0 Reserved
[10] GPIO_SF_SEL 0 = GPIO, 1 = SFIO
[9] RSVD1 Reserved
[8] E_LPDR 0 = Disable, 1 = Enable
[7] E_LPBK 0 = Disable, 1 = Enable
[6] E_INPUT 0 = Disable, 1 = Enable
[5] RSVD2 Reserved
[4] TRISTATE 0 = Passthrough, 1 = Tristate
[3:2] PUPD 0 = None, 1 = Pull-down, 2 = Pull-up, 3 = Reserved
[1:0] PM 0–3 (Reserved for use)

So at this point, I believe the PAD control is configured correctly.

Now, I would appreciate it if you could provide the MMIO (Memory-Mapped I/O) register address to read the GPIO output value.

The SoC has an internal pull-up enabled, and the TI PHY reset pin also has an internal pull-up.
So, I would expect the level to be HIGH when checked with an oscilloscope.
However, it shows LOW.

While looking through the kernel source code, I found that the function ether_open(struct net_device *dev) seems to perform the reset and register the Ethernet PHY.
I called gpio_get_value(388) during that process, and it returned 0, indicating that the GPIO is LOW.

This behavior is very confusing and goes against my expectations.
Even though I intended the pin to be HIGH, it remains LOW, and I currently don’t understand why.

As my understanding, Pull-Up here is only valid for Input pin.
For the Output pin, you should configure Drive 1 in pinmux spreadsheet.

You can simply run the following command to check if there’s any driver is using this pin.

$ sudo cat /sys/kernel/debug/gpio|grep PG.05

Please refer to Calculating/Getting register adresses of gpio pins - #10 by KevinFFF for this use case.

There is something unclear in your response.
============ Response =============================================
As I understand it, the Pull-Up here is only valid for input pins.
For output pins, you should configure Drive 1 in the pinmux spreadsheet.

As previously explained,
According to the document (Orin-TRM_DP10508002_v1.2p.pdf), on page 6118 under section “8.4.4 G3 PAD Control Registers”,

The Pinmux register is as shown below and there is no “Drive length” field.
How exactly should I configure it to Drive 1?

Here is the bit field definition from the document:

Bit Field Name Description / Value Range
12 E_SCHMT 0 = Disable, 1 = Enable
11 RSVD0 Reserved
10 GPIO_SF_SEL 0 = GPIO, 1 = SFIO
9 RSVD1 Reserved
8 E_LPDR 0 = Disable, 1 = Enable
7 E_LPBK 0 = Disable, 1 = Enable
6 E_INPUT 0 = Disable, 1 = Enable
5 RSVD2 Reserved
4 TRISTATE 0 = Passthrough, 1 = Tristate
3:2 PUPD 0 = None, 1 = Pull-down, 2 = Pull-up, 3 = Reserved
1:0 PM 0–3 (Reserved for use)

It is configured in pinmux spreadhseet as the following I shared.

It would add the pin to gpio-output-high field of gpio.dtsi generated by pinmux spreadsheet

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