AM62 – GPIO0_33 (SODIMM_48) not drivable

I am working with a Verdin AM62 on the Mallow carrier board and configured the pin SODIMM_48 / GPMC0_OEn_REn.GPIO0_33 as GPIO output in my device tree (stellihorn.dts).

My current setup in the DTS:

&mcasp1 {
     status = "disabled";
 };
&main_pmx0 {
    backup_battery_pins: pinmux-backup-battery {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x0088, PIN_OUTPUT, 7) /* (L24) GPMC0_OEn_REn.GPIO0_33 */
        >;
    };
};

On my system I have three GPIO controllers:

gpiochip0 [4201000.gpio] (24 lines)
gpiochip1 [600000.gpio] (92 lines)
gpiochip2 [601000.gpio] (52 lines)

The pin in question corresponds to gpiochip1 line 1.
Using gpioset --mode=signal gpiochip1 1=1 or the gpio-hog configuration, I would expect to see the I/O voltage (~VIO) at the pin. However, I always measure only ~0.5 V, both when setting the pin high or low.

I have verified that:

  • gpioinfo shows the line as unused input if not forced,
  • pinmux is set to mode 7 (GPIO),
  • behavior does not change whether I configure the pad as PIN_OUTPUT_PULLDOWN or PIN_OUTPUT.

So it looks like the pin is not actually drivable as GPIO.

Questions:

  • Is this pin (GPIO0_33 / SODIMM_48) really available as a usable GPIO on the Verdin AM62 modules, or does it have hardware/power rail limitations that prevent it from being used as an output?
  • If it should be available, are there any additional steps or configurations needed to properly enable it?

Thanks!

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 Configuration Issue on Verdin AM62 SODIMM_48

Based on the Verdin AM62 datasheet, SODIMM_48 corresponds to the SoC ball name GPMC0_OEn_REn and can be configured as GPIO0_33 using the ALT7 function (1). Your device tree configuration appears correct for enabling this pin as a GPIO output.

Pin Configuration Analysis

Your current device tree configuration looks appropriate (2):

&main_pmx0 {
    backup_battery_pins: pinmux-backup-battery {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x0088, PIN_OUTPUT, 7) /* (L24) GPMC0_OEn_REn.GPIO0_33 */
        >;
    };
};

However, you need to ensure this pin group is properly assigned to a GPIO controller (2). The pin group by itself doesn’t activate the GPIO functionality - you must assign it to the appropriate GPIO controller node.

Required Additional Configuration

To properly enable the GPIO, you need to add your pin group to the GPIO controller’s pinctrl-0 property (2):

&main_gpio0 {
    pinctrl-0 = <&pinctrl_ctrl_sleep_moci>,
                <&pinctrl_gpio_5>,
                <&pinctrl_gpio_6>,
                <&pinctrl_gpio_8>,
                <&backup_battery_pins>;
};

Potential Conflicts

Since SODIMM_48 corresponds to GPMC0_OEn_REn, you should verify that no other device node is using this pin (2). Check if the GPMC (General Purpose Memory Controller) interface is enabled and potentially conflicting with your GPIO configuration. You may need to disable any GPMC-related nodes that might be claiming this pin.

Testing the GPIO

Once properly configured, you can test the GPIO using libgpiod tools (3):

gpioset gpiochip1 33=1

Note that the line number should correspond to GPIO0_33, which would be line 33 on the appropriate GPIO controller (3).

Hardware Considerations

The ~0.5V measurement you’re seeing suggests the pin may not be properly configured as an output or there might be a hardware conflict. Ensure that:

  1. Your pin group is assigned to the GPIO controller
  2. No other peripheral is claiming the same pin
  3. The pin is not being overridden by bootloader settings

If the issue persists after proper device tree configuration, verify the pin assignment in the Verdin AM62 datasheet to ensure there are no hardware-specific limitations for this particular pin (1).

Best regards, Toradex AI Assistant.

Hi @Manuele!

The answer given by the Toradex AI is correct. You must add the pin group to the GPIO controller to activate this pin with the function selected.

Could you try to follow the steps in the link I sent and see if it solves your issue?

Feel free to ask if you face any doubts or issues.

Best regards.

Hi @lucas_az.tx,

No, I haven’t solved my problem yet. I’m having a lot of trouble correctly setting up the DTS for my board.

I’m starting from Linux, and what I want is for the pin to be set low in U-Boot and then set high in Linux.

Here’s my current device tree configuration:

/dts-v1/;

#include "k3-am625.dtsi"
#include "k3-am62-verdin.dtsi"
#include "k3-am62-verdin-nonwifi.dtsi"
#include "k3-am62-verdin-mallow.dtsi"

/ {
    model = "Toradex Verdin AM62 on Mallow Board";
    compatible = "toradex,verdin-am62-nonwifi-mallow",
                 "toradex,verdin-am62-nonwifi",
                 "toradex,verdin-am62",
                 "toradex,stellihorn",
                 "ti,am625";
};

/* Disable MCASP1 to free up pins */
&mcasp1 {
    status = "disabled";
};

/* Configure SODIMM_48 as GPIO output for backup battery */
&main_pmx0 {
    backup_battery_pins: pinmux-backup-battery {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x0088, PIN_OUTPUT, 7) /* (L24) GPMC0_OEn_REn.GPIO0_33 */
        >;
    };
};

/*
This works manually with:
    gpioset gpiochip1 33=1
&main_gpio1 {
    pinctrl-0 = <&backup_battery_pins>;
    pinctrl-names = "default";
};
*/

/* This forces the kernel to set high, but it doesn’t work with line 33 on gpiochip2 */
&main_gpio1 {
    pinctrl-0 = <&backup_battery_pins>;
    pinctrl-names = "default";

    backup_battery_enable {
        gpio-hog;
        gpios = <33 GPIO_ACTIVE_HIGH>;
        output-high;
        line-name = "backup-battery-enable";
    };
};

/* Optional: set SD frequency */
&sdhci1 {
    max-frequency = <50000000>;
};

Please note that once a GPIO is hogged, it is typically claimed by the system and may not be easily accessed or reconfigured by other drivers or user-space applications without causing conflicts. In other words, you will not be able to change its state after boot

I connected this pin to the enable pin of an TPS6120. Currently, the pin does not automatically select the correct chip, although I can control it manually. I want it to stay low during boot, then go high once the kernel is running and remain high until shutdown. It should go low again to turn off the system powered by the backup battery. In the next board revision, I may introduce a pull-down resistor to handle this more reliably.

Hi @Manuele!

Sorry for the delayed answer.

Were you able to solve the issue?

I haven’t tested it, but it should be possible to achieve this behavior using scripts (see an example here) to set the pin high once Linux starts.

Best regards