Issue with overriding GPIO Pull-Up to Pull-Down on Verdin AM62/Dahlia Board

Hello,

We are using the Verdin AM62 with the Dahlia Board and are currently experimenting with GPIO behavior for our tests.

There is a GPIO pin (SODIMM_206) defined as an input with pull-up enabled in the device tree. I would like to change this configuration to pull-down from the Linux terminal using the gpioget tool.

The target pin is AM62 SODIMM_206, which corresponds to X20.27 on the Dahlia Board.
We refer to it as GPIO_1 → gpiochip1, line 1.

Here is the relevant part of the device tree:

&mcu_pmx0 {
	/* Baseboard GPIO_1 */
	pinctrl_gpio_1: mcu-gpio0-1-default-pins {
		pinctrl-single,pins = <
			AM62X_MCU_IOPAD(0x0004, PIN_INPUT_PULLUP, 7) /* (B8) MCU_GPIO0_1 */ /* SODIMM 206 */
		>;
	};
..
}

When the board boots, I measure 1.8V on the pin, which confirms that the pull-up is correctly enabled.

When I check the configuration using gpioinfo, here is the output:

root@verdin-am62-15564022:~# gpioinfo -c1
gpiochip1 - 24 lines:
        line   0:       "GPIO_9"                input
        line   1:       "GPIO_1"                input     <<<-- pull-up enabled in device tree, but not shown here
        line   2:       "GPIO_2"                input
        line   3:       "GPIO_3"                input
        line   4:       "GPIO_4"                input
        line   5:       "GPIO_10"               input
        line   6:       "GPIO_11"               input
        line   7:       "GPIO_12"               input
        line   8:       "GPIO_13"               input
        line   9:       unnamed                 input
        line  10:       unnamed                 input
        line  11:       unnamed                 input
        line  12:       unnamed                 input
        line  13:       unnamed                 input
        line  14:       unnamed                 input
        line  15:       unnamed                 input
        line  16:       "GPIO_14"               input
        line  17:       unnamed                 input
        line  18:       unnamed                 input
        line  19:       unnamed                 input
        line  20:       unnamed                 input
        line  21:       unnamed                 input
        line  22:       unnamed                 input
        line  23:       unnamed                 input

Next, I try to change the bias to pull-down with the following command:

root@verdin-am62-15564022:~# gpioget --bias pull-down -p30000 -c1 1&
[1] 26623
root@verdin-am62-15564022:~# gpioinfo -c1
gpiochip1 - 24 lines:
        line   0:       "GPIO_9"                input
        line   1:       "GPIO_1"                input bias=pull-down consumer="gpioget"
        line   2:       "GPIO_2"                input
        line   3:       "GPIO_3"                input
        line   4:       "GPIO_4"                input
        line   5:       "GPIO_10"               input
        line   6:       "GPIO_11"               input
        line   7:       "GPIO_12"               input
        line   8:       "GPIO_13"               input
        line   9:       unnamed                 input
        line  10:       unnamed                 input
        line  11:       unnamed                 input
        line  12:       unnamed                 input
        line  13:       unnamed                 input
        line  14:       unnamed                 input
        line  15:       unnamed                 input
        line  16:       "GPIO_14"               input
        line  17:       unnamed                 input
        line  18:       unnamed                 input
        line  19:       unnamed                 input
        line  20:       unnamed                 input
        line  21:       unnamed                 input
        line  22:       unnamed                 input
        line  23:       unnamed                 input

As shown, the bias is now reported as pull-down. However, when measuring the pin, I still see 1.8V, which indicates that the pull-up is still active despite the tool reporting otherwise.

Info about the board:

root@verdin-am62-15564022:~# tdx-info

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.94-7.4.0-devel #1 SMP PREEMPT Wed Aug 20 11:57:36 UTC 2025
Kernel command line:      root=PARTUUID=04e80fcc-02 ro rootwait console=tty1 console=ttyS2,115200
Distro name:              NAME="TDX Wayland with XWayland"
Distro version:           VERSION_ID=7.4.0-devel-20250815115749-build.0
Distro variant:           -
Hostname:                 verdin-am62-15564022
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 REFERENCE BOARD using Verdin AM62
Toradex version:          0076 V1.2A
Serial number:            15564022
Processor arch:           aarch64
------------------------------------------------------------

Thank you.

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:


GPIO Pull-Up/Pull-Down Configuration Issue on Verdin AM62

The behavior you’re experiencing is expected and relates to how the AM62 SoC handles GPIO configuration. The gpioget command with bias settings cannot override the hardware pin configuration that was set during boot through the device tree.

Understanding the Issue

When you configure a pin with PIN_INPUT_PULLUP in the device tree, this setting is applied at the hardware register level during boot (1). The gpioget --bias pull-down command only affects the software GPIO subsystem’s understanding of the pin configuration, but it cannot override the physical pad configuration registers that were set during device tree initialization.

Solution: Modify Device Tree Configuration

To change the pull-down configuration, you need to modify the device tree. Based on the Verdin AM62 pin configuration documentation, you can create a device tree overlay to change the pin configuration (1)(2).

Here’s how to create an overlay to change SODIMM_206 to pull-down:

/dts-v1/;
/plugin/;

#include "k3-pinctrl.h"

/ {
    compatible = "toradex,verdin-am62";
};

&mcu_pmx0 {
    pinctrl_gpio_1_pulldown: mcu-gpio0-1-pulldown-pins {
        pinctrl-single,pins = <
            AM62X_MCU_IOPAD(0x0004, PIN_INPUT_PULLDOWN, 7) /* (B8) MCU_GPIO0_1 */ /* SODIMM 206 */
        >;
    };
};

&mcu_gpio0 {
    pinctrl-0 = <&pinctrl_gpio_1_pulldown>,
                <&pinctrl_gpio_2>,
                <&pinctrl_gpio_3>,
                <&pinctrl_gpio_4>,
                <&pinctrl_pcie_1_reset>;
};

Pin Configuration Macros

The AM62 uses specific macros for pin configuration (1):

  • PIN_INPUT_PULLUP - Input with pull-up enabled
  • PIN_INPUT_PULLDOWN - Input with pull-down enabled
  • PIN_INPUT - Input with pull disabled

Important Notes

  1. Hardware vs Software Configuration: The device tree sets the physical pad configuration registers, while gpioget --bias only affects the software GPIO framework’s view of the pin (3).

  2. Overlay Application: You’ll need to compile this overlay and apply it using TorizonCore Builder or deploy it to your system to take effect (2).

  3. Pin Multiplexing: The configuration shown uses function 7 (ALT7) which corresponds to the GPIO function for this pin (1).

Alternative Approach

If you need dynamic control of pull-up/pull-down settings, consider using a different pin that supports this functionality, or implement the changes through proper device tree modifications rather than runtime GPIO commands.

The libgpiod tools are excellent for GPIO control, but they cannot override hardware pad configuration that was established during boot (3).

Best regards, Toradex AI Assistant.

Hello @Fide,

I think that the configuration for the bias from libgpiod depends on support for the specific platform.
Your current behavior would indicate that support for changing this hardware register is not available for the AM62.

Do you need to change the pull-up/pull-down behavior of GPIO pins at runtime for your application?
If not, setting the appropriate value on the device tree should be enough to get the expected behavior.
Also note that usually these are weak pull-ups or pull-downs, so depending on your use case an external pull-up or pull-down may be recommended.

Best Regards,
Bruno

Hello @bruno.tx

I looked into TI AM62 GPIO driver, which is located at ./drivers/gpio/gpio-davinci.c.
Unfortunately, it only implements the direction_input, direction_output, set, and get interface functions.

On the other hand, the ./drivers/gpio/gpio-omap.c driver as an example is more complete and provides the set_config interface, which is required for configuring bias settings:

It’s a pity that TI doesn’t seem to follow consistent internal standards when developing drivers for their MPUs. I think this should be reported to TI.

Thank you,
MF.

Hello @Fide,

Thanks for pointing to the actual driver that has the difference.

If reconfiguring the bias of the GPIO at runtime is needed for your use-case, could you share why?
The reason I ask is that having a use-case behind a request for implementations is important to show the value of adding new functionalities to drivers.

Best Regards,
Bruno

Hello @bruno.tx ,

Our company has eight different products based on the Toradex BSP. We are now working on setting up a common infrastructure for all of them using the AM62 SOM (previously we used VF50). Although the electronic hardware of these products differs, they all make use of the same modules: GPIO, SPI, I2C, UART, OSPI, and PWM. Some products require more GPIOs, some fewer.

For this reason, in the Device Tree we defined all GPIOs (whether used or unused) as inputs with pull-up enabled, to avoid leaving any pins floating when they are not assigned. However, we would like our application development team to be able to later adjust these settings (pull-up/down, input, output, open drain/source) according to their needs, without depending on the kernel team.

That’s why I am testing the relevant functions in the libgpiod library. On VF50 with kernel 4.4, we managed this through sysfs pinctrl, and when switching to libgpiod, we had hoped that these functions would work.

Best regards,
MF

Hello @Fide,

Thanks for the information.
I will raise this internally.
It is important to note that even if TI eventually adds such feature to these drivers, this is not something that will be done in the short term.

For now, if you really need to do such configuration at runtime, direct register manipulation or a simple custom kernel module would be needed.

Best Regards,
Bruno

1 Like