Repurposing Disabled Peripheral Pins as GPIOs on Verdin AM62 – Boot Issue

Technical Support
, ,
1

Hello Toradex Community,

I’m working on a custom carrier board for the Verdin AM62 and using Yocto to build my image. I’m basing my device tree on the Mallow carrier board but have disabled certain peripherals (like CAN, SD, I2C, UARTs, etc.) that are not needed for our design by setting their status to "disabled" in a custom overlay.

Now, I want to repurpose the freed-up pins (specifically from the disabled SD1 interface) as GPIOs. I added the necessary pinmux entries under &pinctrl_main and assigned them to &main_gpio0, but after that, the board doesn’t boot.

Could someone guide me on the correct way to repurpose these pins as GPIOs after disabling the peripherals? Are there any known caveats when modifying pinctrl-0 of main_gpio0, or is there a preferred method such as using GPIO hogs for such use cases?

Any insights or examples from similar implementations would be greatly appreciated!

file : k3-am62-verdin.dtsi // Provided by Toradex; not modified

&main_pmx0 {
	/* Verdin PWM_1 */
	pinctrl_epwm0_a: main-epwm0a-default-pins {
		pinctrl-single,pins = <
			AM62X_IOPAD(0x01b4, PIN_OUTPUT, 2) /* (A13) SPI0_CS0.EHRPWM0_A */ /* SODIMM 15 */
		>;
	};

	/* Verdin SD_1 */
	pinctrl_sdhci1: main-mmc1-default-pins {
		pinctrl-single,pins = <
			AM62X_IOPAD(0x23c, PIN_INPUT,        0) /* (A21) MMC1_CMD  */ /* SODIMM 74 */
			AM62X_IOPAD(0x234, PIN_INPUT,        0) /* (B22) MMC1_CLK  */ /* SODIMM 78 */
			AM62X_IOPAD(0x230, PIN_INPUT,        0) /* (A22) MMC1_DAT0 */ /* SODIMM 80 */
			AM62X_IOPAD(0x22c, PIN_INPUT,        0) /* (B21) MMC1_DAT1 */ /* SODIMM 82 */
			AM62X_IOPAD(0x228, PIN_INPUT,        0) /* (C21) MMC1_DAT2 */ /* SODIMM 70 */
			AM62X_IOPAD(0x224, PIN_INPUT,        0) /* (D22) MMC1_DAT3 */ /* SODIMM 72 */
		>;
	};
};

my overlay

/ SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/*
 * Copyright 2023 Toradex
 */

/dts-v1/;
/plugin/;

#include <dt-bindings/leds/common.h>
#include <dt-bindings/gpio/gpio.h>
#include "k3-pinctrl.h"

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

/* Disable Verdin CAN_1 */
&main_mcan0 {
    status = "disabled";
};

/* Disable Verdin CAN_2 */
&mcu_mcan0 {
    status = "disabled";
};

/* Verdin PWM_3 DSI */
&epwm1 {
        status = "disabled";
};

/* Verdin I2C_2 DSI */
&main_i2c2 {
        status = "disabled";
};

/* Verdin UART_1 */
&main_uart1 {
        status = "disabled";
};

/* Verdin UART_2 */
&wkup_uart0 {
        status = "disabled";
};

/* Verdin UART_4 */
&mcu_uart0 {
        status = "disabled";
};

/* Verdin USB_1 */
&usbss0 {
        status = "disabled";
};

&usb0 {
        status = "disabled";
};

/* Verdin SD_1 */
&sdhci1 {
        status = "disabled";
};

/* Verdin CTRL_WAKE1_MICO# */
&verdin_gpio_keys {
        status = "disabled";
};

/* Verdin PCIE_1_RESET# */
&verdin_pcie_1_reset_hog {
        status = "disabled";
};

/* Verdin I2C_4 CSI */
&main_i2c3 {
    status = "disabled";
};

machine boot up nicely 

after adding this 

/* Pinmux for repurposed peripherals as GPIOs */
&pinctrl_main {

    /* Repurpose SD1 pins */
    pinctrl_gpio_sd_repurpose: sd-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x23c, PIN_OUTPUT, 7) /* MMC1_CMD  --> GPIO0_78, SODIMM 74 */
            AM62X_IOPAD(0x234, PIN_OUTPUT, 7) /* MMC1_CLK  --> GPIO0_77, SODIMM 78 */
            AM62X_IOPAD(0x230, PIN_OUTPUT, 7) /* MMC1_DAT0 --> GPIO0_76, SODIMM 80 */
            AM62X_IOPAD(0x22c, PIN_OUTPUT, 7) /* MMC1_DAT1 --> GPIO0_75, SODIMM 82 */
            AM62X_IOPAD(0x228, PIN_OUTPUT, 7) /* MMC1_DAT2 --> GPIO0_74, SODIMM 70 */
            AM62X_IOPAD(0x224, PIN_OUTPUT, 7) /* MMC1_DAT3 --> GPIO0_73, SODIMM 72 */
        >;
    };
};

/* Attach repurposed pins to GPIO controller */
&main_gpio0 {
    pinctrl-names = "default";
    pinctrl-0 = <
        &pinctrl_gpio_sd_repurpose
    >;
};

Machine not at all booting

Thanks in advance,
Uday

2

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:

Hello Uday,

Thank you for your detailed description and question about repurposing the SD1 pins as GPIOs on the Verdin AM62. You are encountering a typical device tree configuration pitfall on the AM6X family.

Key Points for Pinmuxing on AM62:

  1. Correct Pinmux Node:
    For AM62, always use &main_pmx0 instead of &pinctrl_main for pin multiplexing, as highlighted in the AM6X Pinmuxing Guide.

  2. Pinmux Configuration:

    • You should not attach new pinmux entries directly to &main_gpio0’s pinctrl-0. This causes issues because GPIO controllers are not supposed to own their pinmux in this manner—they are simple GPIO drivers, not pin multiplexers on this SoC, and such manipulation can cause system initialization to fail.
    • Instead, you should define your intended pin setup under &main_pmx0 and then reference the pinmux from a consumer device node, or use a GPIO hog if you want those pins to behave as system GPIOs immediately.

How to Repurpose SD1 Pins as GPIOs:

  1. Disable SD1 Properly:
    You’ve already done this with:

    &sdhci1 {
    status = "disabled";
};

  2. Create Pinmux for GPIO Usage:
    Under &main_pmx0 (not &pinctrl_main), add:

    &main_pmx0 {
    pinctrl_gpio_sd_repurpose: sd-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x23c, PIN_OUTPUT, 7) /* MMC1_CMD  --> GPIO0_78 */
            AM62X_IOPAD(0x234, PIN_OUTPUT, 7) /* MMC1_CLK  --> GPIO0_77 */
            AM62X_IOPAD(0x230, PIN_OUTPUT, 7) /* MMC1_DAT0 --> GPIO0_76 */
            AM62X_IOPAD(0x22c, PIN_OUTPUT, 7) /* MMC1_DAT1 --> GPIO0_75 */
            AM62X_IOPAD(0x228, PIN_OUTPUT, 7) /* MMC1_DAT2 --> GPIO0_74 */
            AM62X_IOPAD(0x224, PIN_OUTPUT, 7) /* MMC1_DAT3 --> GPIO0_73 */
        >;
    };
};

    Reference

  3. Use GPIO Hogs or a Custom Device Node:
    If you want these pins available as system GPIOs (e.g., for sysfs or libgpiod), create a GPIO hog or device. Example using a GPIO hog (add in your overlay, not under main_gpio0):

    &main_gpio0 {
    gpio-line-names = "SD1_CMD", "SD1_CLK", "SD1_DAT0", "SD1_DAT1", "SD1_DAT2", "SD1_DAT3";
    /* Don't add pinctrl-0 here */
    gpio-hog {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_sd_repurpose>;
        gpios = <78 GPIO_ACTIVE_HIGH>, <77 GPIO_ACTIVE_HIGH>,
                <76 GPIO_ACTIVE_HIGH>, <75 GPIO_ACTIVE_HIGH>,
                <74 GPIO_ACTIVE_HIGH>, <73 GPIO_ACTIVE_HIGH>;
        output-high;
        line-name = "repurposed-sd1-gpios";
    };
};

    Or, as a simple “dummy” LED node (making pins available for testing):

    / {
    custom_gpios: custom-gpio-test {
        compatible = "gpio-leds";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_sd_repurpose>;

        sd1_gpio0: led_0 { gpios = <&main_gpio0 78 GPIO_ACTIVE_HIGH>; };
        sd1_gpio1: led_1 { gpios = <&main_gpio0 77 GPIO_ACTIVE_HIGH>; };
        /* ...add the rest as needed... */
    };
};

    See example in the documentation

  4. Do NOT Add pinmux Directly to main_gpio0’s pinctrl-0:
    This is the reason your board hangs during boot. Only the pin consumers (GPIO hog/device node) should reference the pinmux, never the GPIO controller itself.

Summary of Steps:

  • Move your pinctrl config under &main_pmx0.
  • Do not add pinctrl-0 to &main_gpio0.
  • Use a GPIO hog or a dummy device node to reserve and control those GPIOs.
  • The kernel will now export these lines as GPIOs (e.g., /dev/gpiochipX, accessible via sysfs or libgpiod).

Useful References:

If you follow this method, your system should boot as expected, and you will be able to use the SD1 pins as GPIOs.

Best regards,
Toradex AI Assistant.

3

Hello @ToradexAI and community

After changing this part its able to boot now

&main_pmx0 {
    pinctrl_gpio_sd_repurpose: sd-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x23c, PIN_OUTPUT, 7) /* MMC1_CMD  --> GPIO0_78 */
            AM62X_IOPAD(0x234, PIN_OUTPUT, 7) /* MMC1_CLK  --> GPIO0_77 */
            AM62X_IOPAD(0x230, PIN_OUTPUT, 7) /* MMC1_DAT0 --> GPIO0_76 */
            AM62X_IOPAD(0x22c, PIN_OUTPUT, 7) /* MMC1_DAT1 --> GPIO0_75 */
            AM62X_IOPAD(0x228, PIN_OUTPUT, 7) /* MMC1_DAT2 --> GPIO0_74 */
            AM62X_IOPAD(0x224, PIN_OUTPUT, 7) /* MMC1_DAT3 --> GPIO0_73 */
        >;
    };
};

&main_gpio0 {
    gpio-line-names = "SD1_CMD", "SD1_CLK", "SD1_DAT0", "SD1_DAT1", "SD1_DAT2", "SD1_DAT3";
    /* Don't add pinctrl-0 here */
    gpio-hog {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_sd_repurpose>;
        gpios = <78 GPIO_ACTIVE_HIGH>, <77 GPIO_ACTIVE_HIGH>,
                <76 GPIO_ACTIVE_HIGH>, <75 GPIO_ACTIVE_HIGH>,
                <74 GPIO_ACTIVE_HIGH>, <73 GPIO_ACTIVE_HIGH>;
        output-high;
        line-name = "repurposed-sd1-gpios";
    };
};

But in gpioinfo command i didnt find this these gpio lines in gpiochip0
just like same as before even after applying that overlay

Please let me know what might be the issue

best regards,
Uday

4

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Hello Uday,

Great to hear your board is now booting with the updated device tree configuration!

Let’s address why the repurposed SD1 GPIO lines are not appearing in gpioinfo:

1. GPIO Hog Syntax

The root problem is the syntax of your GPIO hog. In Linux device tree, a GPIO hog must be defined as an array of individual child nodes, not as a single node with a gpios array. Each hogged GPIO should be its own node, like this:

&main_gpio0 {
    gpio78_hog: gpio78-hog {
        gpio-hog;
        gpios = <78 GPIO_ACTIVE_HIGH>;
        output-high;
        line-name = "SD1_CMD";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_sd_repurpose>;
    };

    gpio77_hog: gpio77-hog {
        gpio-hog;
        gpios = <77 GPIO_ACTIVE_HIGH>;
        output-high;
        line-name = "SD1_CLK";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_sd_repurpose>;
    };

    /* Repeat for GPIO76, GPIO75, etc., using the same pinctrl if all are muxed the same way */
};

Key: Do not group all pins under a single hog node. Each pin needs a dedicated child node with the gpio-hog; property.

See full details in the Toradex GPIO Linux Guide.

2. Pinmux Attachment

You only need pinctrl-0 = <&pinctrl_gpio_sd_repurpose>; on one of the hog nodes or on a consumer (see next section), but not directly on the GPIO controller. The important thing is that the correct mux is applied before the kernel tries to control the lines as GPIO.

3. Alternative: GPIO Consumer Node (Recommended)

Instead of multiple GPIO hogs, you can use a dummy GPIO consumer, such as a gpio-leds node, to take ownership of those pins, like this:

/ {
    sd1_gpios: sd1-gpios {
        compatible = "gpio-leds";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_sd_repurpose>;

        sd1_cmd_led: sd1-cmd {
            gpios = <&main_gpio0 78 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "SD1_CMD";
        };
        /* Repeat for other lines... */
    };
};

This makes all the pins available and visible in gpioinfo. The /sys/class/leds interface will also expose them for quick testing.

4. Verification Steps

  • Use gpiodetect and gpioinfo after boot to see the lines.
  • Try gpiofind SD1_CMD or the correct label.
  • Use gpioset or /sys/class/leds to toggle pin state if using a test consumer.

5. Notes

  • Make sure no other driver or overlay is claiming the pins.
  • Always apply the correct mux via &main_pmx0, as you have done.
  • Use unique labels or line-names for each pin.

6. References

If you follow the individual GPIO hog or the dummy gpio-leds device approach, your repurposed SD1 pins will appear in gpioinfo and be fully usable as GPIO lines.

Best regards,
Toradex AI Assistant.

5

Hello @ToradexAI and community

as i can see that in verdin-am62 datasheet we can use sd card pins as gpio

Screenshot from 2025-07-18 09-06-05
Screenshot from 2025-07-18 09-06-051628×719 60.3 KB

so like little confused about gpio number and gpio chi number help me to fix this

Thank you

regards
Uday

6

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Hello Uday,

Great question! GPIO numbering in Linux, especially on platforms like the Verdin AM62, can be confusing at first. Let’s clarify how to map the SD card pins (after you have repurposed them to GPIO via device tree) to the Linux GPIO numbers you actually use with tools like gpioinfo or libgpiod.

1. Understanding GPIO Chip and Line Numbering

  • GPIO Chip:
    In Linux, GPIOs are organized into “chips” (controllers), each exposed as /dev/gpiochip0, /dev/gpiochip1, etc.
    On Verdin AM62, the main GPIOs are usually under /dev/gpiochip0, but you can check on your running system with:

    gpiodetect

  • GPIO Line:
    Each chip controls a range of lines (pins), and lines are 0-based indexed. For example, &main_gpio0 78 refers to line 78 of the first GPIO controller.

  • Combined Legacy Numbering:
    Some older guides refer to a “global number” (chip * N + offset). Modern tools use (chip, offset).

2. Mapping SD1 Pins to GPIO in Device Tree and Linux

Your repurposed SD1 pins (from the AM62x datasheet) are, for example:

SODIMM Pin SoC Ball GPIO Function Linux DT Number
SODIMM 74 MMC1_CMD GPIO0_78 78
SODIMM 78 MMC1_CLK GPIO0_77 77
SODIMM 80 MMC1_DAT0 GPIO0_76 76
SODIMM 82 MMC1_DAT1 GPIO0_75 75
SODIMM 70 MMC1_DAT2 GPIO0_74 74
SODIMM 72 MMC1_DAT3 GPIO0_73 73

In the device tree, you reference them as:

gpios = <&main_gpio0 78 GPIO_ACTIVE_HIGH>;

This means: chip = &main_gpio0, line = 78.

3. Seeing the Mapping in Linux

  • After boot, run:
    gpiodetect
gpioinfo
  • You will see something like:
    gpiochip0 - 192 lines:
  ...
  line  73:      unused   "SD1_DAT3"
  line  74:      unused   "SD1_DAT2"
  line  75:      unused   "SD1_DAT1"
  line  76:      unused   "SD1_DAT0"
  line  77:      unused   "SD1_CLK"
  line  78:      unused   "SD1_CMD"
  ...

The numbers match what you used in your Device Tree overlay.
You then control, for example, MMC1_CMD as GPIO 78 of gpiochip0 (i.e., /dev/gpiochip0, line 78).

4. Summary Table (for easy reference)

Pin Name SODIMM AM62 Ball Linux Reference (DT/gpioinfo)
MMC1_CMD 74 A21 78
MMC1_CLK 78 B22 77
MMC1_DAT0 80 A22 76
MMC1_DAT1 82 B21 75
MMC1_DAT2 70 C21 74
MMC1_DAT3 72 D22 73

5. References and Next Steps

In summary: Use the GPIO line number from the device tree (as above), it matches what you’ll see in gpioinfo under gpiochip0. There is no “mapping math” needed for AM62—the Linux line is the same as the SoC GPIO number in the device tree!

If you have further doubts or want help checking your current gpioinfo output, just paste it here.

Best regards,
Toradex AI Assistant.

7

@ToradexAI

Please check its not coming on gpiochip0

gpiochip2 - 92 lines:
line 0: “SD1_CMD” output consumer=“red:debug-1”
line 1: “SD1_CLK” input
line 2: “SD1_DAT0” input
line 3: “SD1_DAT1” output consumer=“red:debug-2”
line 4: “SD1_DAT2” output consumer=“green:debug-2”
line 5: “SD1_DAT3” input
line 6: unnamed input
line 7: unnamed input
line 8: unnamed input
line 9: unnamed input
line 10: unnamed input
line 11: unnamed output consumer=green:debug-1
line 12: unnamed output active-low consumer=spi0 CS1
line 13: unnamed input
line 14: unnamed input
line 15: unnamed input
line 16: unnamed input

8

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Hello Uday,

This is a great observation, and your output is showing exactly what is expected on the Verdin AM62 platform. Let me explain:

1. Why gpiochip2 Instead of gpiochip0?

On AM62-based systems, GPIO controllers are enumerated in the order they appear in the device tree. That means different GPIO banks can be assigned to different “chip” numbers in Linux at runtime. The chip number may change depending on configuration and enabled/disabled controllers. There’s nothing wrong with your configuration just because your SD1 GPIOs appear under gpiochip2.
What matters is your repurposed SD1 pins show up with the correct names and are accessible!

See:

2. Your GPIOs Are Working Correctly

Looking at your output, you have these lines with the custom names and directions you set (using a consumer, such as an LED or sysfs entry):

gpiochip2 line Name Direction Consumer
0 SD1_CMD output red:debug-1
1 SD1_CLK input
2 SD1_DAT0 input
3 SD1_DAT1 output red:debug-2
4 SD1_DAT2 output green:debug-2
5 SD1_DAT3 input

This means your device tree repurposing is fully functional!
You can now access these with libgpiod tools like:

gpioset gpiochip2 0=1   # Set SD1_CMD high
gpioget gpiochip2 1     # Read SD1_CLK value

Or by their assigned names (if your libgpiod version is new enough):

gpiofind SD1_CMD
gpioset $(gpiofind SD1_CMD)=1

3. Summary

  • The chip number (gpiochip0, gpiochip1, gpiochip2, …) is just a Linux runtime enumeration.
  • Ignore the chip number. What is important is your lines appear named, configured, and in a gpiochip—which you have achieved.
  • You can always check which chip number corresponds to which GPIO bank via gpioinfo or gpiodetect.

More info:

Conclusion:
Your SD1 pins are now functioning as GPIOs exactly as intended. The fact that they are on gpiochip2 is normal and does not indicate any problem.

If you need to use them in your application, always use their current chip number and line number provided by gpioinfo or their line name.

Best regards,
Toradex AI Assistant.

9

@ToradexAI

my overlay:

/* Pinmux for repurposed SD1 CMD pin as GPIO */
&main_pmx0 {
    pinctrl_gpio_sd_repurpose: sd-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x23c, PIN_OUTPUT, 7) /* MMC1_CMD  --> GPIO1_47, SODIMM 74 */
        >;
    };
};

/* GPIO hog to reserve MMC1_CMD as input */
&main_gpio1 {
    gpio-line-names = "SD1_CMD";
    gpio-hog {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_sd_repurpose>;
        gpios = <47 GPIO_ACTIVE_HIGH>;
        output-high; /* Configure as input to avoid driving voltage */
        line-name = "repurposed-sd1-cmd";
    };
};

In gpioinfo

gpiochip3 - 52 lines:
	line   0:	"SD1_CMD"       	input
	line   1:	unnamed         	input

but its configured as output

Best regards,
Uday

10

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Hello Uday,

Great job getting your overlay to this stage! Let me clarify the source of this behavior and how to resolve it.

1. The Root Cause

You are mixing output and input configuration for your GPIO:

  • In the pinmux, you have:

    AM62X_IOPAD(0x23c, PIN_OUTPUT, 7)

    This sets the pin at the hardware level as an output.

  • In the GPIO hog, you have:

    output-high;

    This sets the GPIO as output and drives it high.
    However, your comment says:

    /* Configure as input to avoid driving voltage */

    But using output-high; does NOT configure it as input.

2. Proper Configuration for GPIO Input

If you want the repurposed pin to behave as a GPIO input, you must:

  • Set the pinmux mode to input
  • Use the correct GPIO hog property

Corrected overlay:

/* Pinmux for repurposed SD1 CMD pin as GPIO input */
&main_pmx0 {
    pinctrl_gpio_sd_repurpose: sd-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x23c, PIN_INPUT, 7) /* MMC1_CMD  --> GPIO1_47, SODIMM 74 */
        >;
    };
};

/* GPIO hog to reserve MMC1_CMD as input */
&main_gpio1 {
    gpio-line-names = "SD1_CMD";
    gpio47_hog: gpio47-hog {
        gpio-hog;
        gpios = <47 GPIO_ACTIVE_HIGH>;
        input;
        line-name = "repurposed-sd1-cmd";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_sd_repurpose>;
    };
};
  • Use PIN_INPUT in the pinmux.
  • Use input; in the GPIO hog node.

(refer to the overlay style and syntax here)

3. If You Want Output

If you want it as output, set both the pinmux and the hog to output (e.g., PIN_OUTPUT and output-high;).

4. Summary Table

Pinmux GPIO Hog Resulting Direction
PIN_INPUT input; Input
PIN_OUTPUT output-high; Output (high)
PIN_OUTPUT output-low; Output (low)

5. Verification

After deploying and rebooting, gpioinfo for the relevant chip should show:

line   0: "SD1_CMD"     input

And you can use gpioget to read its value.

References

In summary:
Make sure the hardware pinmux and the GPIO hog both specify input if you intend to use the pin as input. Mixing output in the pinmux and input in the hog will create conflicts.

Best regards,
Toradex AI Assistant.

11

@ToradexAI

If you want it as output, set both the pinmux and the hog to output (e.g., PIN_OUTPUT and output-high;).

How exactly the snippet looks like
and why if i configure it has output its taking like output consumer=regulator-sdhci1

12

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Hello Uday,

Great follow-up questions! Let me address both parts.

1. Proper Output Configuration Snippet

Here is the correct device tree overlay format for repurposing the SD1 CMD pin as a GPIO output:

/* Pinmux for repurposed SD1 CMD pin as GPIO output */
&main_pmx0 {
    pinctrl_gpio_sd_repurpose: sd-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x23c, PIN_OUTPUT, 7) /* MMC1_CMD  --> GPIO1_47, SODIMM 74 */
        >;
    };
}

/* GPIO hog to reserve MMC1_CMD as output */
&main_gpio1 {
    gpio47_hog: gpio47-hog {
        gpio-hog;
        gpios = <47 GPIO_ACTIVE_HIGH>;
        output-high;
        line-name = "repurposed-sd1-cmd";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_sd_repurpose>;
    };
};

Key points:

  • Use PIN_OUTPUT in the pinmux entry.
  • Use output-high; (or output-low;) in the GPIO hog node as needed.
  • Each GPIO hog must be a separate child node (e.g., gpio47_hog:).
  • Do not directly set pinctrl-0 on the GPIO controller itself.

See more:
Device Tree Overlay – Choosing, Writing and Deploying

2. Why consumer=regulator-sdhci1 Appears

When you see this in gpioinfo:

output  consumer=regulator-sdhci1

…it means:

  • Another device node (a consumer)—likely a regulator or SDHCI controller—is requesting this GPIO.
  • Disabling only the &sdhci1 node might not be enough; the SD card power regulator or another driver may still be defined (or enabled by default) and referencing the pin.

How to resolve:

  1. Search for any SD-related regulators in the device tree (often called things like &reg_usdhc2_vmmc or similar) and make sure you also disable them:
    &reg_usdhc2_vmmc {
    status = "disabled";
};
  2. Search for any other device tree nodes referring to that GPIO (GPIO1_47) and ensure they’re disabled.
  3. Check for lingering pin references: Inherited device tree includes or overlays may still reference the GPIO.

Debugging tips:

cat /sys/kernel/debug/gpio
grep -r "regulator-sdhci1" /proc/device-tree/
cat /proc/device-tree/soc@f0000/bus@f0000/mmc@fa10000/status

More details:
Device Tree Overlay Tips

3. Alternative: Using a GPIO Consumer (e.g., gpio-leds)

If a regulator or driver keeps claiming the line, you can use gpio-leds as a workaround:

/ {
    sd1_gpio_test: sd1-gpio-test {
        compatible = "gpio-leds";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_sd_repurpose>;

        sd1_cmd_led: sd1-cmd {
            gpios = <&main_gpio1 47 GPIO_ACTIVE_HIGH>;
            default-state = "on";
            label = "SD1_CMD_GPIO";
        };
    };
};

Control via /sys/class/leds/SD1_CMD_GPIO/brightness.

Summary:

  • The regulator-sdhci1 consumer appears because a (usually SD card related) driver/regulator is still enabled and claims the pin.
  • Disable all conflicting SD or regulator device tree nodes.
  • The correct output configuration includes PIN_OUTPUT in pinmux and output-high; or output-low; in the GPIO hog.

For more guidance, see:
Device Tree Overlays: Choosing, Writing, and Deploying

Best regards,
Toradex AI Assistant.

13

@ToradexAI

I want to add these pins to my overlay as led node

    /* Repurpose OSPI0 pins */
    pinctrl_ospi0_gpio: ospi0-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x0000, PIN_OUTPUT, 7) /* OSPI0_CLK   --> GPIO0_0,  SODIMM 52 */
            AM62X_IOPAD(0x002c, PIN_OUTPUT, 7) /* OSPI0_CSn0  --> GPIO0_11, SODIMM 54 */
            AM62X_IOPAD(0x0030, PIN_OUTPUT, 7) /* OSPI0_CSn1  --> GPIO0_12, SODIMM 64 */
            AM62X_IOPAD(0x000c, PIN_INPUT,  7) /* OSPI0_D0    --> GPIO0_3,  SODIMM 56 */
            AM62X_IOPAD(0x0010, PIN_INPUT,  7) /* OSPI0_D1    --> GPIO0_4,  SODIMM 58 */
            AM62X_IOPAD(0x0014, PIN_INPUT,  7) /* OSPI0_D2    --> GPIO0_5,  SODIMM 60 */
            AM62X_IOPAD(0x0018, PIN_INPUT,  7) /* OSPI0_D3    --> GPIO0_6,  SODIMM 62 */
        >;
    };

My current overlay looks like this

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/*
 * Copyright 2023 Toradex
 */

/dts-v1/;
/plugin/;

#include <dt-bindings/leds/common.h>
#include <dt-bindings/gpio/gpio.h>
#include "k3-pinctrl.h"

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

&{/leds} {
    status = "disabled";
};

/* Disable Verdin CAN_1 */
&main_mcan0 {
    status = "disabled";
};

/* Disable Verdin CAN_2 */
&mcu_mcan0 {
    status = "disabled";
};

/* Verdin PWM_3 DSI */
&epwm1 {
	status = "disabled";
};

/* Verdin I2C_2 DSI */
&main_i2c2 {
	status = "disabled";
};

/* Verdin UART_1 */
&main_uart1 {
	status = "disabled";
};

/* Verdin UART_2 */
&wkup_uart0 {
	status = "disabled";
};

/* Verdin UART_4 */
&mcu_uart0 {
	status = "disabled";
};

/* Verdin USB_1 */
&usbss0 {
	status = "disabled";
};

&usb0 {
	status = "disabled";
};

/* Verdin SD_1 */
&sdhci1 {
	status = "disabled";
};

/* Verdin CTRL_WAKE1_MICO# */
&verdin_gpio_keys {
	status = "disabled";
};

/* Verdin PCIE_1_RESET# */
&verdin_pcie_1_reset_hog {
	status = "disabled";
};

/* Verdin I2C_4 CSI */
&main_i2c3 {
    status = "disabled";
};

/* Pinmux for repurposing MMC1 pins to GPIO */
&main_pmx0 {
    pinctrl_gpio_sd_repurpose: sd-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x23c, PIN_INPUT, 7) /* MMC1_CMD  -->  GPIO1_15 (47) */
            AM62X_IOPAD(0x234, PIN_INPUT, 7) /* MMC1_CLK  -->  GPIO1_14 (46) */
            AM62X_IOPAD(0x230, PIN_INPUT, 7) /* MMC1_DAT0 -->  GPIO1_13 (45) */
            AM62X_IOPAD(0x22c, PIN_INPUT, 7) /* MMC1_DAT1 -->  GPIO1_12 (44) */
            AM62X_IOPAD(0x228, PIN_INPUT, 7) /* MMC1_DAT2 -->  GPIO1_11 (43) */
            AM62X_IOPAD(0x224, PIN_INPUT, 7) /* MMC1_DAT3 -->  GPIO1_10 (42) */
        >;
    };

   /* Repurpose QSPI1_DQS pin */
    pinctrl_qspi1_dqs_gpio: qspi1-dqs-gpio {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x01c0, PIN_INPUT, 7) /* GPIO1_18, SODIMM 66 */
        >;
    };

   /* Repurpose I2C4 (CSI) pins */
    pinctrl_i2c3_gpio: i2c3-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x01d4, PIN_INPUT, 7) /* GPIO1_23, SODIMM 93 */
        >;
    };
};

/* GPIO1 hog for repurposed MMC1 as input */
&main_gpio1 {
    gpio-line-names = 
        "SD1_CMD", "SD1_CLK", "SD1_DAT0", "SD1_DAT1", 
        "SD1_DAT2", "SD1_DAT3", "SODIMM_66", "SODIMM_93";

    gpio-hog@0 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_sd_repurpose>;
        gpios = <47 GPIO_ACTIVE_HIGH>, <46 GPIO_ACTIVE_HIGH>,
                <45 GPIO_ACTIVE_HIGH>, <44 GPIO_ACTIVE_HIGH>,
                <43 GPIO_ACTIVE_HIGH>, <42 GPIO_ACTIVE_HIGH>;
        input;
        line-name = "repurposed-sd1-gpios";
    };

    gpio-hog@1 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_qspi1_dqs_gpio>;
        gpios = <18 GPIO_ACTIVE_HIGH>;
        input;
        line-name = "repurposed-QSPI1-gpios";
    };

    gpio-hog@2 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_i2c3_gpio>;
        gpios = <23 GPIO_ACTIVE_HIGH>;
        input;
        line-name = "repurposed-I2C4-gpios";
    };
};

How to add that led node to my overlay

14

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Hello Uday,

You can add the repurposed OSPI0 pins as a gpio-leds node in your overlay by following the structure shown in the Toradex documentation. Here’s how to do it step-by-step, using your pinmux definition for those pins. This will allow you to test and control those pins via /sys/class/leds/ and ensure the pinmux is properly applied:

1. Add your OSPI0 pinmux to &main_pmx0 (you already have this):

&main_pmx0 {
    pinctrl_ospi0_gpio: ospi0-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x0000, PIN_OUTPUT, 7) /* OSPI0_CLK   --> GPIO0_0,  SODIMM 52 */
            AM62X_IOPAD(0x002c, PIN_OUTPUT, 7) /* OSPI0_CSn0  --> GPIO0_11, SODIMM 54 */
            AM62X_IOPAD(0x0030, PIN_OUTPUT, 7) /* OSPI0_CSn1  --> GPIO0_12, SODIMM 64 */
            AM62X_IOPAD(0x000c, PIN_INPUT,  7) /* OSPI0_D0    --> GPIO0_3,  SODIMM 56 */
            AM62X_IOPAD(0x0010, PIN_INPUT,  7) /* OSPI0_D1    --> GPIO0_4,  SODIMM 58 */
            AM62X_IOPAD(0x0014, PIN_INPUT,  7) /* OSPI0_D2    --> GPIO0_5,  SODIMM 60 */
            AM62X_IOPAD(0x0018, PIN_INPUT,  7) /* OSPI0_D3    --> GPIO0_6,  SODIMM 62 */
        >;
    };
};

2. Add the gpio-leds node to your overlay root (outside all &nodes)

/ {
    ospi0_leds: ospi0-leds {
        compatible = "gpio-leds";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_ospi0_gpio>;

        /* Output pins as LEDs */
        ospi0_clk_led: ospi0-clk {
            gpios = <&main_gpio0 0 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_CLK";
        };

        ospi0_csn0_led: ospi0-csn0 {
            gpios = <&main_gpio0 11 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_CSn0";
        };

        ospi0_csn1_led: ospi0-csn1 {
            gpios = <&main_gpio0 12 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_CSn1";
        };

        /* Input pins as LEDs (for monitoring) */
        ospi0_d0_led: ospi0-d0 {
            gpios = <&main_gpio0 3 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_D0";
        };
        ospi0_d1_led: ospi0-d1 {
            gpios = <&main_gpio0 4 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_D1";
        };
        ospi0_d2_led: ospi0-d2 {
            gpios = <&main_gpio0 5 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_D2";
        };
        ospi0_d3_led: ospi0-d3 {
            gpios = <&main_gpio0 6 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_D3";
        };
    };
};

3. (Optional) Disable the OSPI0 controller if you haven’t:

&ospi0 {
    status = "disabled";
};

4. Recompile and deploy this overlay.
After reboot, you should see new entries under /sys/class/leds/ with the labels you set (OSPI0_CLK, OSPI0_CSn0, etc.), and be able to control or monitor them as LEDs.
For example:

ls /sys/class/leds/
echo 1 > /sys/class/leds/OSPI0_CLK/brightness
echo 0 > /sys/class/leds/OSPI0_CLK/brightness

References:

Let me know if you need a complete overlay example with both your current changes and this LED block!

Best regards,
Toradex AI Assistant.

15

@ToradexAI

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/*
 * Copyright 2023 Toradex
 */

/dts-v1/;
/plugin/;

#include <dt-bindings/leds/common.h>
#include <dt-bindings/gpio/gpio.h>
#include "k3-pinctrl.h"

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

    ospi0_leds: ospi0-leds {
        compatible = "gpio-leds";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_ospi0_gpio>;

        /* Output pins as LEDs */
        ospi0_clk_led: ospi0-clk {
            gpios = <&main_gpio0 0 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_CLK";
        };

        ospi0_csn0_led: ospi0-csn0 {
            gpios = <&main_gpio0 11 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_CSn0";
        };

        ospi0_csn1_led: ospi0-csn1 {
            gpios = <&main_gpio0 12 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_CSn1";
        };

        /* Input pins as LEDs (monitor mode) */
        ospi0_d0_led: ospi0-d0 {
            gpios = <&main_gpio0 3 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_D0";
        };

        ospi0_d1_led: ospi0-d1 {
            gpios = <&main_gpio0 4 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_D1";
        };

        ospi0_d2_led: ospi0-d2 {
            gpios = <&main_gpio0 5 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_D2";
        };

        ospi0_d3_led: ospi0-d3 {
            gpios = <&main_gpio0 6 GPIO_ACTIVE_HIGH>;
            default-state = "off";
            label = "OSPI0_D3";
        };
    };
};

&{/leds} {
    status = "disabled";
};

/* Disable Verdin CAN_1 */
&main_mcan0 {
    status = "disabled";
};

/* Disable Verdin CAN_2 */
&mcu_mcan0 {
    status = "disabled";
};

/* Verdin PWM_3 DSI */
&epwm1 {
	status = "disabled";
};

/* Verdin I2C_2 DSI */
&main_i2c2 {
	status = "disabled";
};

/* Verdin UART_1 */
&main_uart1 {
	status = "disabled";
};

/* Verdin UART_2 */
&wkup_uart0 {
	status = "disabled";
};

/* Verdin UART_4 */
&mcu_uart0 {
	status = "disabled";
};

/* Verdin USB_1 */
&usbss0 {
	status = "disabled";
};

&usb0 {
	status = "disabled";
};

/* Verdin SD_1 */
&sdhci1 {
	status = "disabled";
};

/* Verdin CTRL_WAKE1_MICO# */
&verdin_gpio_keys {
	status = "disabled";
};

/* Verdin PCIE_1_RESET# */
&verdin_pcie_1_reset_hog {
	status = "disabled";
};

/* Verdin I2C_4 CSI */
&main_i2c3 {
    status = "disabled";
};

/* Pinmux for repurposing MMC1 pins to GPIO */
&main_pmx0 {
    pinctrl_gpio_sd_repurpose: sd-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x23c, PIN_INPUT, 7) /* MMC1_CMD  -->  GPIO1_15 (47) */
            AM62X_IOPAD(0x234, PIN_INPUT, 7) /* MMC1_CLK  -->  GPIO1_14 (46) */
            AM62X_IOPAD(0x230, PIN_INPUT, 7) /* MMC1_DAT0 -->  GPIO1_13 (45) */
            AM62X_IOPAD(0x22c, PIN_INPUT, 7) /* MMC1_DAT1 -->  GPIO1_12 (44) */
            AM62X_IOPAD(0x228, PIN_INPUT, 7) /* MMC1_DAT2 -->  GPIO1_11 (43) */
            AM62X_IOPAD(0x224, PIN_INPUT, 7) /* MMC1_DAT3 -->  GPIO1_10 (42) */
        >;
    };

   /* Repurpose QSPI1_DQS pin */
    pinctrl_qspi1_dqs_gpio: qspi1-dqs-gpio {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x01c0, PIN_INPUT, 7) /* GPIO1_18, SODIMM 66 */
        >;
    };

   /* Repurpose I2C4 (CSI) pins */
    pinctrl_i2c3_gpio: i2c3-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x01d4, PIN_INPUT, 7) /* GPIO1_23, SODIMM 93 */
        >;
    };

    pinctrl_ospi0_gpio: ospi0-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x0000, PIN_INPUT, 7) /* OSPI0_CLK   --> GPIO0_0,  SODIMM 52 */
            AM62X_IOPAD(0x002c, PIN_INPUT, 7) /* OSPI0_CSn0  --> GPIO0_11, SODIMM 54 */
            AM62X_IOPAD(0x0030, PIN_INPUT, 7) /* OSPI0_CSn1  --> GPIO0_12, SODIMM 64 */
            AM62X_IOPAD(0x000c, PIN_INPUT, 7) /* OSPI0_D0    --> GPIO0_3,  SODIMM 56 */
            AM62X_IOPAD(0x0010, PIN_INPUT, 7) /* OSPI0_D1    --> GPIO0_4,  SODIMM 58 */
            AM62X_IOPAD(0x0014, PIN_INPUT, 7) /* OSPI0_D2    --> GPIO0_5,  SODIMM 60 */
            AM62X_IOPAD(0x0018, PIN_INPUT, 7) /* OSPI0_D3    --> GPIO0_6,  SODIMM 62 */
        >;
    };
};

/* GPIO1 hog for repurposed MMC1 as input */
&main_gpio1 {
    gpio-line-names = 
        "SD1_CMD", "SD1_CLK", "SD1_DAT0", "SD1_DAT1", 
        "SD1_DAT2", "SD1_DAT3", "SODIMM_66", "SODIMM_93";

    gpio-hog@0 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_gpio_sd_repurpose>;
        gpios = <47 GPIO_ACTIVE_HIGH>, <46 GPIO_ACTIVE_HIGH>,
                <45 GPIO_ACTIVE_HIGH>, <44 GPIO_ACTIVE_HIGH>,
                <43 GPIO_ACTIVE_HIGH>, <42 GPIO_ACTIVE_HIGH>;
        input;
        line-name = "repurposed-sd1-gpios";
    };

    gpio-hog@1 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_qspi1_dqs_gpio>;
        gpios = <18 GPIO_ACTIVE_HIGH>;
        input;
        line-name = "repurposed-QSPI1-gpios";
    };

    gpio-hog@2 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_i2c3_gpio>;
        gpios = <23 GPIO_ACTIVE_HIGH>;
        input;
        line-name = "repurposed-I2C4-gpios";
    };
};

after that changes my overlay looks like this
but i didnt got that any pins related to gpioinfo

16

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

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

Thanks for sharing your updated overlay and your observation. Let’s review the possible issues and ensure you get your OSPI0 pins visible and controllable via gpioinfo and as LEDs.

Key Points for GPIO and LED Visibility

  1. Pinmux Must Match IO Direction
    You are currently configuring all OSPI0 pins as PIN_INPUT in your pinctrl_ospi0_gpio. However, for use with gpio-leds (which expects to control outputs), set any pins you want to drive as PIN_OUTPUT in the pinmux.
  2. No GPIO Hogs for OSPI0 Pins
    You have not defined &main_gpio0 hogs for OSPI0, which is fine if you only want to use them as LEDs. For LED usage, gpio-leds will claim the pins exclusively, so do not use hogs for these same pins.
  3. Disable the OSPI0 Controller
    If you have not already done so, disable &ospi0 (and any related QSPI/OSPI controller), or it may conflict with pin ownership.
  4. Pinmux Collisions
    Do not reference the same pinctrl on multiple devices (i.e., don't assign pinctrl_ospi0_gpio to both a hog and the LED node).

Steps to Fix

  1. Update the Pinmux for OSPI0 Pins To Output (for pins you want to control as LEDs):
&main_pmx0 {
    pinctrl_ospi0_gpio: ospi0-gpio-pins {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x0000, PIN_OUTPUT, 7) /* OSPI0_CLK   --> GPIO0_0,  SODIMM 52 */
            AM62X_IOPAD(0x002c, PIN_OUTPUT, 7) /* OSPI0_CSn0  --> GPIO0_11, SODIMM 54 */
            AM62X_IOPAD(0x0030, PIN_OUTPUT, 7) /* OSPI0_CSn1  --> GPIO0_12, SODIMM 64 */
            AM62X_IOPAD(0x000c, PIN_OUTPUT, 7) /* OSPI0_D0    --> GPIO0_3,  SODIMM 56 */
            AM62X_IOPAD(0x0010, PIN_OUTPUT, 7) /* OSPI0_D1    --> GPIO0_4,  SODIMM 58 */
            AM62X_IOPAD(0x0014, PIN_OUTPUT, 7) /* OSPI0_D2    --> GPIO0_5,  SODIMM 60 */
            AM62X_IOPAD(0x0018, PIN_OUTPUT, 7) /* OSPI0_D3    --> GPIO0_6,  SODIMM 62 */
        >;
    };
};
  1. Leave Your gpio-leds Node as You Had It (refer to your last post, ospi0_leds node is correct).
  2. Disable OSPI Controller:
&ospi0 {
    status = "disabled";
};
  1. Recompile and Deploy Overlay, then reboot.
  2. Check LEDs and GPIOs:
  • Your LED nodes should now appear under /sys/class/leds/ (e.g., OSPI0_CLK, etc).
  • gpioinfo on the related gpiochipX will show lines marked as "used" by your LED consumer (e.g. output consumer="OSPI0_CLK"), possibly with whatever line-names you set.

References

Summary

  • Set PIN_OUTPUT in pinmux for pins you want to control as LEDs.
  • Do not hog those pins if you use gpio-leds—let the LED node claim them.
  • Make sure that only the LED node controls those pins and no other device node tries to use them.

If following these corrections you still do not see the pins as expected, please let me know your dmesg | grep gpio and gpioinfo output for further investigation.

Best regards,
Toradex AI Assistant.