How to configure GPIO as input and read its state from user space (Verdin AM62, custom carrier board)

Hi,

I’m using the Verdin AM62 module on our custom development board, running in the Yocto environment. I’ve configured one GPIO pin (for example, SODIMM_52gpiochip2 line 0) as an input in the device tree.

However, when I check the GPIO state from user space using:

gpioget --chip /dev/gpiochip2 0

it always shows:

"0" = inactive

even when I apply a high signal to that pin.

Could you please let me know if there’s something specific about reading GPIO states from user space on this module, or if any additional configuration (like pull-up/down settings) is needed?

Below is my device tree file for the reference
dts (37.1 KB)
The SODIMM pins configured as inputs are:
52, 54, 56, 58, 60, 62, 66, and 76.

only 66 and 76 is working rest of the things not working

Could you please help me check if there’s anything missing or incorrect in the GPIO configuration?
Also, is there any additional step required to properly read GPIO input states from user space on Verdin AM62?

For reference, my GPIO output configuration using gpio-hog works perfectly fine. For example

myled_sodimm_70 {
    label = "my_led_sodimm_70";
    gpios = <&main_gpio1 43 GPIO_ACTIVE_HIGH>;
    linux,default-trigger = "heartbeat";
    default-state = "off";
};

myled_sodimm_72 {
    label = "my_led_sodimm_72";
    gpios = <&main_gpio1 42 GPIO_ACTIVE_HIGH>;
    linux,default-trigger = "heartbeat";
    default-state = "off";
};

for quick check kindly refer main part in the device tree as below

/* Verdin QSPI_1_CLK as GPIO (conflict with Verdin QSPI_1 interface) */
pinctrl_qspi1_clk_gpio: main-gpio0-0-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x0000, PIN_INPUT, 7) /* (H24) OSPI0_CLK.GPIO0_0 */ /* SODIMM 52 */
	>;
};

/* Verdin QSPI_1_CS# as GPIO (conflict with Verdin QSPI_1 interface) */
pinctrl_qspi1_cs_gpio: main-gpio0-11-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x002c, PIN_INPUT, 7) /* (F23) OSPI0_CSn0.GPIO0_11 */ /* SODIMM 54 */
	>;
};

/* Verdin QSPI_1_IO0 as GPIO (conflict with Verdin QSPI_1 interface) */
pinctrl_qspi1_io0_gpio: main-gpio0-3-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x000c, PIN_INPUT, 7) /* (E25) OSPI0_D0.GPIO0_3 */ /* SODIMM 56 */
	>;
};

/* Verdin QSPI_1_IO1 as GPIO (conflict with Verdin QSPI_1 interface) */
pinctrl_qspi1_io1_gpio: main-gpio0-4-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x0010, PIN_INPUT, 7) /* (G24) OSPI0_D1.GPIO0_4 */ /* SODIMM 58 */
	>;
};

/* Verdin QSPI_1_IO2 as GPIO (conflict with Verdin QSPI_1 interface) */
pinctrl_qspi1_io2_gpio: main-gpio0-5-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x0014, PIN_INPUT, 7) /* (F25) OSPI0_D2.GPIO0_5 */ /* SODIMM 60 */
	>;
};

/* Verdin QSPI_1_IO3 as GPIO (conflict with Verdin QSPI_1 interface) */
pinctrl_qspi1_io3_gpio: main-gpio0-6-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x0018, PIN_INPUT, 7) /* (F24) OSPI0_D3.GPIO0_6 */ /* SODIMM 62 */
	>;
};
	
	
/* Verdin QSPI_1 */
pinctrl_ospi0: main-ospi0-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x0000, PIN_OUTPUT, 0) /* (H24) OSPI0_CLK  */ /* SODIMM 52 */
		AM62X_IOPAD(0x002c, PIN_OUTPUT, 0) /* (F23) OSPI0_CSn0 */ /* SODIMM 54 */
		AM62X_IOPAD(0x0030, PIN_OUTPUT, 0) /* (G21) OSPI0_CSn1 */ /* SODIMM 64 */
		AM62X_IOPAD(0x000c, PIN_INPUT, 0)  /* (E25) OSPI0_D0   */ /* SODIMM 56 */
		AM62X_IOPAD(0x0010, PIN_INPUT, 0)  /* (G24) OSPI0_D1   */ /* SODIMM 58 */
		AM62X_IOPAD(0x0014, PIN_INPUT, 0)  /* (F25) OSPI0_D2   */ /* SODIMM 60 */
		AM62X_IOPAD(0x0018, PIN_INPUT, 0)  /* (F24) OSPI0_D3   */ /* SODIMM 62 */
	>;
};

/* Verdin QSPI_1 */
&ospi0 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_ospi0>;
	status = "disabled";
};

Thanks in advance!

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

Common Issues with GPIO Input Reading

Based on the Verdin AM62 documentation, there are several potential causes for your GPIO input reading issue(1)(2):

1. Pin Configuration Requirements

For GPIO inputs on the Verdin AM62, you need to ensure proper pinmux configuration(3)(4). The AM62 SoC uses different GPIO controllers, and each requires specific configuration:

  • MCU_GPIO0: Uses AM62X_MCU_IOPAD function(4)
  • GPIO0/GPIO1: Uses AM62X_IOPAD function(4)

2. Pull-up/Pull-down Configuration

The AM62 GPIO pins may require explicit pull-up or pull-down configuration(2). In your device tree, ensure you’re using the correct pin configuration macros(3):

pinctrl-single,pins = <
    AM62X_IOPAD(0x01bc, PIN_INPUT, 7) /* (A14) SPI0_CLK.GPIO1_17 */ /* SODIMM 19 */
>;

(3)

The PIN_INPUT macro is defined in k3-pinctrl.h(4):

#define PIN_INPUT (INPUT_EN | PULL_DISABLE)
#define PIN_INPUT_PULLUP (INPUT_EN | PULL_UP)
#define PIN_INPUT_PULLDOWN (INPUT_EN | PULL_DOWN)

(4)

3. GPIO Controller Assignment

Verify that your SODIMM pins are assigned to the correct GPIO controller(4). For example:

  • SODIMM 19 belongs to GPIO1 controller(4)
  • SODIMM 21 belongs to GPIO0 controller(4)
  • SODIMM 61 belongs to MCU_GPIO0 controller(4)

4. Device Tree Structure Requirements

Your device tree should include(3)(4):

  1. Pinmux configuration in the appropriate controller (&main_pmx0 or &mcu_pmx0)
  2. GPIO controller reference with pinctrl assignment
  3. Line names for easier identification

Example structure for GPIO input(4):

&main_pmx0 {
    pinctrl_sodimm_52_gpio: sodimm_52_gpio_grp {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x00XX, PIN_INPUT_PULLUP, 7) /* GPIO configuration */
        >;
    };
};

&main_gpio0 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_sodimm_52_gpio>;
};

(4)

5. Troubleshooting Steps

  1. Verify pin assignment: Check that SODIMM_52 corresponds to the correct GPIO chip and line(5)
  2. Check pin conflicts: Ensure the pin isn’t being used by another peripheral(3)
  3. Test with pull-up: Try configuring the pin with PIN_INPUT_PULLUP instead of PIN_INPUT(4)
  4. Verify GPIO direction: Use gpioinfo to confirm the pin is configured as input(5)

6. Hardware Considerations

The Verdin AM62 GPIO pins may have specific electrical characteristics(2). If you’re applying an external high signal, ensure:

  • The voltage levels are compatible (typically 3.3V logic)
  • The signal source can drive the pin adequately
  • Consider using an external pull-up resistor if the pin is configured as open-drain(2)

Recommended Solution

Since your GPIO outputs work correctly, the issue is likely in the input pin configuration. Review your device tree to ensure:

  1. Correct pinmux settings with appropriate pull configuration
  2. Proper GPIO controller assignment
  3. No conflicts with other peripheral functions

Best regards,
Toradex AI Assistant.


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

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

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

Hey, @raju3003,

Can you tell me exactly what you are doing to drive the pin high before reading it?

libgpiod has a bit of a strange behavior when reading a pin that you set to high via software. If you use gpioset to drive the pin high and then read it with gpioget, it will drive the pin low and then read it. As far as I know, this happens because the pin stays high even after gpioset releases it, but is no longer held in that state, and then gpioget drives it to low once again.

To really test gpioget, you should connect an external high signal from another source to the pin, and then read its value with gpioget. Let me know if this solves the issue.

Best regards,

Hi @leonardo.costa.tx

Thanks for replying!

actually i am driving it high by giving high voltage say 24V in our set-up to that pin should i delete that node or
is that qspi node claiming all the pins

/* Verdin QSPI_1_CLK as GPIO (conflict with Verdin QSPI_1 interface) */
pinctrl_qspi1_clk_gpio: main-gpio0-0-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x0000, PIN_INPUT, 7) /* (H24) OSPI0_CLK.GPIO0_0 */ /* SODIMM 52 */
	>;
};

/* Verdin QSPI_1_CS# as GPIO (conflict with Verdin QSPI_1 interface) */
pinctrl_qspi1_cs_gpio: main-gpio0-11-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x002c, PIN_INPUT, 7) /* (F23) OSPI0_CSn0.GPIO0_11 */ /* SODIMM 54 */
	>;
};

/* Verdin QSPI_1_IO0 as GPIO (conflict with Verdin QSPI_1 interface) */
pinctrl_qspi1_io0_gpio: main-gpio0-3-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x000c, PIN_INPUT, 7) /* (E25) OSPI0_D0.GPIO0_3 */ /* SODIMM 56 */
	>;
};

/* Verdin QSPI_1_IO1 as GPIO (conflict with Verdin QSPI_1 interface) */
pinctrl_qspi1_io1_gpio: main-gpio0-4-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x0010, PIN_INPUT, 7) /* (G24) OSPI0_D1.GPIO0_4 */ /* SODIMM 58 */
	>;
};

/* Verdin QSPI_1_IO2 as GPIO (conflict with Verdin QSPI_1 interface) */
pinctrl_qspi1_io2_gpio: main-gpio0-5-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x0014, PIN_INPUT, 7) /* (F25) OSPI0_D2.GPIO0_5 */ /* SODIMM 60 */
	>;
};

/* Verdin QSPI_1_IO3 as GPIO (conflict with Verdin QSPI_1 interface) */
pinctrl_qspi1_io3_gpio: main-gpio0-6-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x0018, PIN_INPUT, 7) /* (F24) OSPI0_D3.GPIO0_6 */ /* SODIMM 62 */
	>;
};
	
	
/* Verdin QSPI_1 */
pinctrl_ospi0: main-ospi0-default-pins {
	pinctrl-single,pins = <
		AM62X_IOPAD(0x0000, PIN_OUTPUT, 0) /* (H24) OSPI0_CLK  */ /* SODIMM 52 */
		AM62X_IOPAD(0x002c, PIN_OUTPUT, 0) /* (F23) OSPI0_CSn0 */ /* SODIMM 54 */
		AM62X_IOPAD(0x0030, PIN_OUTPUT, 0) /* (G21) OSPI0_CSn1 */ /* SODIMM 64 */
		AM62X_IOPAD(0x000c, PIN_INPUT, 0)  /* (E25) OSPI0_D0   */ /* SODIMM 56 */
		AM62X_IOPAD(0x0010, PIN_INPUT, 0)  /* (G24) OSPI0_D1   */ /* SODIMM 58 */
		AM62X_IOPAD(0x0014, PIN_INPUT, 0)  /* (F25) OSPI0_D2   */ /* SODIMM 60 */
		AM62X_IOPAD(0x0018, PIN_INPUT, 0)  /* (F24) OSPI0_D3   */ /* SODIMM 62 */
	>;
};

/* Verdin QSPI_1 */
&ospi0 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_ospi0>;
	status = "disabled";
};

I guess some issue with this only may be

Best regards,
Raju

Hey @raju3003,

actually i am driving it high by giving high voltage say 24V in our set-up to that pin should i delete that node or

I think you might have damaged your GPIO port. I don’t know how you designed your carrier board, but the Verdin AM62 GPIO pins have a maximum rating of 2.1V. You should never apply such a high voltage directly to the I/O pins of your device.

I suggest taking a 1.8V power source and connecting to other pins to check if they are working correctly, though I wouldn’t trust any other results from this device. It’s probably better to change your module for a new one.

Best regards,

Hi @leonardo.costa.tx

We have converter in the design module getting only 1.8v
That’s not ths issue and also another 2 gpio nicely working only this QSPI node some problem
May be something with device tree

Please confirm that can we use that QSPI pins and also like even if we disabled stilll it’s claiming as QSPI not as gpio or what
Bcz in the device tree i kept both and just disabled that using status

Regards
Raju

Hey @raju3003,

I see that you are disabling the ospi0 node, which is correct. By the way, you can just disable it without any further configurations in the device tree:

&ospi0 {
	status = "disabled";
};

However, you may have forgotten to activate the group of pins you configured as GPIO. You can do it the way the AI suggested it, it should probably work:

&main_gpio0 {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_ospi0>;
};

Let me know if this solves the issue.

Best regards,

Hi @leonardo.costa.tx
I’ve made the suggested modifications, but there’s still no change in behavior.

Here’s how my updated file looks now. Could you please check why specifically those six QSPI pins (SODIMM 52, 54, 56, 58, 60, and 62) are not working as expected?

For reference, the other GPIOs (SODIMM 66 and 76) are working correctly.
k3-am62.dtsi (36.7 KB)
k3-am62-verdin-carrier.dtsi (4.2 KB)

Best regards,
Raju

Hi @raju3003 ,

can you try by adding commas (phandle-array instead of phandles) after every line of pinctrl-0 here:
&main_gpio0 {
pinctrl-names = “default”;
pinctrl-0 = <
&pinctrl_qspi1_clk_gpio
&pinctrl_qspi1_cs_gpio
&pinctrl_qspi1_io0_gpio
&pinctrl_qspi1_io1_gpio
&pinctrl_qspi1_io2_gpio
&pinctrl_qspi1_io3_gpio

;
status = “okay”;
};

Unrelated but, I suggest also to avoid configuring as output the GPIO using the device tree. I’m afraid it is not really supported (commonly you normally switch to output afterwards).

Emanuele

1 Like

Hi @emanuele.tx @leonardo.costa.tx,

Thank you for the suggestion regarding the output — I will update that.

However, I’m still unsure why this specific QSPI pin is not working as a GPIO.
I already updated the phandles with commas, but the issue remains.
We have checked the hardware side as well, and everything looks correct there.

In the device tree, the pin is configured as a GPIO, and because of that it also appears correctly in gpioinfo.
So now I’m unsure what exactly is going wrong.

I’m starting to doubt whether the QSPI pins truly support GPIO mode.
In the Verdin AM62 datasheet these pins are shown in bold text, and the GPIO function (option 7 in pinmux) is also listed, meaning they should be usable as GPIOs.

Could you please help me understand what might be happening?

Best regards,
Raju


Hi @emanuele.tx @emanuele.tx

I checked the kernel side, and pins SODIMM_52, SODIMM_56, and SODIMM_58 all appear to be correctly claimed by the GPIO subsystem. However, I still cannot get them to work as expected.

Below are the debug outputs I collected:

ot@verdin-am62-15415775:/sys/class/gpio# grep -i "52" /sys/kernel/debug/pinctrl/*/pins
/sys/kernel/debug/pinctrl/f4000.pinctrl-pinctrl-single/pins:pin 52 (PIN52) 51:600000.gpio f40d0 00010000 pinctrl-single 
/sys/kernel/debug/pinctrl/f4000.pinctrl-pinctrl-single/pins:pin 53 (PIN53) 52:600000.gpio f40d4 00010000 pinctrl-single 
/sys/kernel/debug/pinctrl/f4000.pinctrl-pinctrl-single/pins:pin 152 (PIN152) 0:? f4260 08214000 pinctrl-single 
root@verdin-am62-15415775:/sys/class/gpio# grep -n "SODIMM_52" /sys/kernel/debug/gpio || true
11: gpio-539 (SODIMM_52           )
root@verdin-am62-15415775:/sys/class/gpio# cat /sys/kernel/debug/pinctrl/*/pins | grep -i "ospi"
root@verdin-am62-15415775:/sys/class/gpio# grep -i "56" /sys/kernel/debug/pinctrl/*/pins
/sys/kernel/debug/pinctrl/f4000.pinctrl-pinctrl-single/pins:pin 56 (PIN56) 55:600000.gpio f40e0 00010000 pinctrl-single 
/sys/kernel/debug/pinctrl/f4000.pinctrl-pinctrl-single/pins:pin 57 (PIN57) 56:600000.gpio f40e4 00010000 pinctrl-single 
/sys/kernel/debug/pinctrl/f4000.pinctrl-pinctrl-single/pins:pin 156 (PIN156) 0:? f4270 08214000 pinctrl-single 
root@verdin-am62-15415775:/sys/class/gpio# grep -i "58" /sys/kernel/debug/pinctrl/*/pins
/sys/kernel/debug/pinctrl/4084000.pinctrl-pinctrl-single/pins:pin 22 (PIN22) 0:? 4084058 08014000 pinctrl-single 
/sys/kernel/debug/pinctrl/f4000.pinctrl-pinctrl-single/pins:pin 22 (PIN22) 22:600000.gpio f4058 08254007 pinctrl-single 
/sys/kernel/debug/pinctrl/f4000.pinctrl-pinctrl-single/pins:pin 58 (PIN58) 57:600000.gpio f40e8 00010000 pinctrl-single 
/sys/kernel/debug/pinctrl/f4000.pinctrl-pinctrl-single/pins:pin 59 (PIN59) 58:600000.gpio f40ec 00010000 pinctrl-single 
/sys/kernel/debug/pinctrl/f4000.pinctrl-pinctrl-single/pins:pin 86 (PIN86) 84:600000.gpio f4158 00050000 pinctrl-single 
/sys/kernel/debug/pinctrl/f4000.pinctrl-pinctrl-single/pins:pin 150 (PIN150) 51:601000.gpio f4258 00010000 pinctrl-single 
/sys/kernel/debug/pinctrl/f4000.pinctrl-pinctrl-single/pins:pin 158 (PIN158) 0:? f4278 08214000 pinctrl-single 

From the pinctrl and GPIO debug information, the pins seem properly muxed as GPIOs, but they still do not behave correctly in userspace.

here is input schematic

Do you have any suggestions on what else I should verify?

Best regards,
Raju

Hey, @raju3003,

I made a small device tree overlay just copying the relevant snippets you pointed out here. I didn’t change anything besides separating the groups by commas and leaving the ospi0 as disabled.
verdin-am62-qspi-gpio.dts (2.8 KB)

I’m starting to doubt whether the QSPI pins truly support GPIO mode.

Applying this overlay on top of our Reference Multimedia, I was able to correctly read the input from all the configured pins. What this probably means is that you either have another part of the device tree, or a device tree overlay, that is disabling the GPIO functionality of your pins, or the high signal is not getting to the pins correctly due to a design issue.

Best regards,

Hi @leonardo.costa.tx @emanuele.tx,

Thank you, it’s working now. The issue was caused by a conflict with another overlay file.

Best regards,
Raju

1 Like