GPIO management problem

aarribas · November 15, 2025, 3:34pm

Hello,

We are using apalis i.mx6 modules. Our kernel versions are 5.7.6 and 6.1.83. We use Apalis i.mx6 modules. Until now we were able to manage all gpios that we need, but we are going to manage gpios 176, 178, 180 and 188 and we aren´t able to manage them.

We don´t know if these gpios need something special to be configured. But as with the others gpios we are using sysfs to manage.

In our device tree overlay we have set

&usdhc2     {
    status = "disabled";
};


            MX6QDL_PAD_SD2_DAT2__GPIO1_IO13     0x130b0  /* SODIMM  176 */        
            MX6QDL_PAD_SD2_DAT3__GPIO1_IO12     0x130b0  /* SODIMM  178 */        
            MX6QDL_PAD_SD2_CMD__GPIO1_IO11      0x130b0  /* SODIMM  180 */        
            MX6QDL_PAD_SD2_DAT1__GPIO1_IO14     0x130b0  /* SODIMM  188 */

These are the steps that we follow:

GPIO 176 
echo 13 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio13/direction
echo 1 > /sys/class/gpio/gpio13/value
echo 0 > /sys/class/gpio/gpio13/value 

GPIO 178
echo 12 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio12/direction
echo 1 > /sys/class/gpio/gpio12/value
echo 0 > /sys/class/gpio/gpio12/value 

GPIO 180
echo 11 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio11/direction
echo 1 > /sys/class/gpio/gpio11/value
echo 0 > /sys/class/gpio/gpio11/value 

GPIO 188
echo 14 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio14/direction
cat /sys/class/gpio/gpio14/value

The problem that we face is that the real voltage at the gpio is always 3.3v. No changes are shown.

From documentation those gpios are configured to be GPIOS, so none peripheal takes control of them

This is the result from using ‘gpioinfo 0’ command before we try to configure them

gpiochip0 - 32 lines:
line 0: “MXM3_84” “regulator-usb-host-vbus” output active-low [used]
line 1: “MXM3_4” unused input active-high
line 2: “MXM3_15/GPIO7” unused input active-high
line 3: “MXM3_96” unused input active-high
line 4: “MXM3_37” unused input active-high
line 5: unnamed unused input active-high
line 6: “MXM3_17/GPIO8” unused input active-high
line 7: “MXM3_14” unused input active-high
line 8: “MXM3_12” unused input active-high
line 9: “MXM3_2” unused input active-high
line 10: “MXM3_184” unused input active-high
line 11: “MXM3_180” unused input active-high
line 12: “MXM3_178” unused input active-high
line 13: “MXM3_176” unused input active-high
line 14: “MXM3_188” unused input active-high
line 15: “MXM3_186” unused input active-high
line 16: “MXM3_160” unused input active-high
line 17: “MXM3_162” unused input active-high
line 18: “MXM3_150” unused input active-high
line 19: “MXM3_144” unused input active-high
line 20: “MXM3_154” unused input active-high
line 21: “MXM3_146” unused input active-high
line 22: unnamed unused input active-high
line 23: unnamed unused input active-high
line 24: “MXM3_72” unused input active-high
line 25: unnamed “phy-reset” output active-high [used]
line 26: unnamed unused input active-high
line 27: unnamed unused input active-high
line 28: unnamed unused input active-high
line 29: unnamed unused input active-high
line 30: unnamed unused input active-high
line 31: unnamed unused input active-high

For the GPIO 180 this is the gpioinfo 0 result after configured it

line 11: “MXM3_180” “sysfs” output active-high [used]

So could you help us and tell us if we are doing something wrong or if we have missed somethig?

Best Regards and thank you.

ToradexAI · November 15, 2025, 3:40pm

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

GPIO Configuration Issue on Apalis iMX6

Based on your description, the GPIO lines are being properly exported and configured through sysfs, but you’re not seeing the expected voltage changes on the physical pins. Let me help you troubleshoot this issue.

Pin Mapping Verification

According to the Apalis iMX6 datasheet(1), all GPIO pins can be used as general-purpose input/output, and all GPIO pins can be used as interrupt sources(1). The GPIO functionality should work as expected when properly configured.

For your specific GPIO numbers (176, 178, 180, 188), you need to verify the correct mapping between the MXM3 connector pins and the GPIO numbers. The relationship between module pin names, pin numbers, SoC pin names, and GPIO numbers can be found in the module’s datasheet(2).

Troubleshooting Steps

Verify Pin Configuration: Check that these pins are not being used by other peripherals or have conflicting device tree configurations.
Check Device Tree: Ensure that the pins are properly configured as GPIO in the device tree and not assigned to other functions.
Pin Multiplexing: The pins might be configured for alternative functions. You need to verify that the IOMUX is set to GPIO mode for these specific pins(2).
Hardware Verification: Since you’re seeing 3.3V constantly, check if there are pull-up resistors on these pins or if they’re being driven by another source on your carrier board.

Alternative GPIO Access Method

Note that using GPIO via sysfs is deprecated in recent Linux versions(3). For better compatibility and future-proofing, consider using the modern GPIO character device interface or libgpiod tools instead of the sysfs interface.

Pin Assignment Reference

You should consult the Apalis iMX6 datasheet’s pin assignment tables to verify the exact mapping between your desired MXM3 pins (176, 178, 180, 188) and their corresponding GPIO controller numbers(2). The datasheet contains detailed tables showing the relationship between module pin names, pin numbers, SoC pin names, and GPIO numbers(2).

Recommendations

Double-check the pin assignment tables in the Apalis iMX6 datasheet
Verify that no other peripherals are claiming these pins
Check your carrier board design for any hardware conflicts
Consider using modern GPIO tools instead of the deprecated sysfs interface

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

aarribas · November 17, 2025, 11:57am

This is useful, but right now we have done these steps and nothing has changed, we continue with the problems to manage those gpios. We are using Apalis evaluation board to verify the correct management of those pins. Also we have tried with toradex minimal image.

lucas_az.tx · November 25, 2025, 12:45pm

Hi @aarribas!

Have you tried with libgpiod? Refer to this article for more information about how this library works.

Best regards.

aarribas · November 25, 2025, 5:53pm

Hello @lucas_az.tx,

Thanks for the reply. We have used both, libgpiod and sysfs. In both cases we were not able to manage those gpios. But we were able to manage other gpios with both libgpiod and sysfs with your evaluation board and our custom board and with your example images and our custom yocto images.

Could you try to manage thos specific pins in your lab, please?

Best Regards,

alex.tx · November 25, 2025, 6:35pm

To re-purpose SD2 pins as GPIO your DT overlay should be like this one

/dts-v1/;
/plugin/;

/ {
    compatible = "toradex,apalis-imx6";

    /* Disable USDHC2 to free the SD2 pads */
    fragment@0 {
        target = <&usdhc2>;
        __overlay__ {
            status = "disabled";
        };
    };

    /* Create GPIO pinmux group in IOMUXC */
    fragment@1 {
        target = <&iomuxc>;
        __overlay__ {

            apalis_imx6_gpio_sd2_pins: apalis-imx6-gpio-sd2-pins {
                fsl,pins = <
                    MX6QDL_PAD_SD2_CMD__GPIO1_IO11   0x130b0
                    MX6QDL_PAD_SD2_DAT3__GPIO1_IO12  0x130b0
                    MX6QDL_PAD_SD2_DAT2__GPIO1_IO13  0x130b0
                    MX6QDL_PAD_SD2_DAT1__GPIO1_IO14  0x130b0
                >;
            };
        };
    };

    /* Activate the GPIO pinmux group */
    fragment@2 {
        target-path = "/";
        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <&apalis_imx6_gpio_sd2_pins>;
        };
    };

};

aarribas · November 26, 2025, 10:05am

Hello @alex.tx

Thanks for the response. We will code your suggestion and come back with the result.

Best regards,

aarribas · December 23, 2025, 12:44pm

Hello @alex.tx

We have tested your suggestions but we are not able to manage those pins. They remained in 3.3v always. We don´t know if we are checking the right pins in our Apalis evaluation board, because the labels in MXM3_178…MXM3_188 indicate as SD1_xx and those pins are usdhc2

Could you give us any advice?

Thanks and best regards