Gpioset does not work as expected

Technical Support
,
1

Hello

Our board:
root@verdin-imx8mp-15289951:~# cat /sys/devices/soc0/machine
Toradex Verdin iMX8M Plus on Verdin Development Board

We have some difficulties to set gpio.

With the torizon 6.8 minimal image everything works as expected:

root@verdin-imx8mp-15289951:~# uname -a
Linux verdin-imx8mp-15289951 6.1.142-6.8.3+git.7e69c33e4858 #1 SMP PREEMPT Fri Jun 27 10:07:41 UTC 2025 aarch64 GNU/Linux

gpioset gpiochip2 19=1
gives 1.8V on pin34 (SODIMM_34)
gpioset gpiochip2 19=0
gives 0.0V on pin34 (SODIMM_34)

gpioset gpiochip2 25=1
gives 1.8V on pin30 (SODIMM_30)
gpioset gpiochip2 25=0
gives 0.0V on pin30 (SODIMM_30)

With the Torizon 7.3 minimal image, all this no longer works and we don’t know why:

root@verdin-imx8mp-15289951:~# uname -a
Linux verdin-imx8mp-15289951 6.6.94-7.3.0 #1 SMP PREEMPT Wed Jun 25 09:14:55 UTC 2025 aarch64 GNU/Linux

First of all, the gpiochip must be selected with -c in gpioset, if not here is an error:

gpioset gpiochip2 19=1
invalid line value: ‘gpiochip2’

Is this normal?

Secondly, the gpios cannot be set:

pkill gpioset;gpioset -zc gpiochip2 19=1
gives 0.6V on pin34 (SODIMM_34)
pkill gpioset;gpioset -zc gpiochip2 19=0
gives 0.6V on pin34 (SODIMM_34)

pkill gpioset;gpioset -zc gpiochip2 25=1
gives 1.8V on pin30 (SODIMM_30)
pkill gpioset;gpioset -zc gpiochip2 25=0
gives 1.8V on pin30 (SODIMM_30)

But with gpioinfo it looks good:

gpioinfo | grep -i sodimm_34
line 19: “SODIMM_34” output
gpioinfo | grep -i sodimm_30
line 25: “SODIMM_30” output

We don’t know how to proceed at the moment and would be glad of any advice.

Best regards
René

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 René,

Thank you for your detailed report. The issues you’re encountering are related to changes in the libgpiod toolchain between Torizon 6.8 and 7.3, as well as underlying system differences.

1. Command Syntax Change (-c flag)

Starting with newer libgpiod versions (as in Torizon 7.3), you must specify the -c flag to indicate the gpiochip device. This is expected behavior in upstream libgpiod, so for Torizon 7.3 the correct syntax is:

gpioset -t0 -c /dev/gpiochip2 19=1

You can also specify the bank using the SODIMM pin name for more robust scripts:

gpioset -t0 SODIMM_34=1

Reference:

2. Voltage Issue

  • On 7.3, you’re seeing 0.6V on SODIMM_34 instead of the expected values. This often indicates that the pin could be:
    • Not properly set as an output or not configured as a GPIO in the device tree.
    • Still reserved/used by another function or process.
    • Not fully released by a previous gpioset process (hence, using pkill gpioset is a good idea, but -t0 explicitly tells gpioset to exit immediately after setting).

3. Troubleshooting Steps

a) Use SODIMM Pin Names (Recommended)

Try setting the pins using their SODIMM names—this is the recommended approach, as it avoids issues if the kernel mapping changes:

gpioset -t0 SODIMM_34=1
gpioset -t0 SODIMM_34=0

gpioset -t0 SODIMM_30=1
gpioset -t0 SODIMM_30=0

This is more robust and less likely to break across Torizon versions.

b) Check for GPIO Conflicts

Ensure no other processes or overlays are using these pins (sometimes overlays or kernel drivers can reserve them).

  • Run:

    gpioinfo | grep SODIMM_34

    Confirm the pin is listed only as output and not in use by another function.

  • Verify in the device tree or overlays that these pins are not assigned elsewhere (such as to another peripheral).

c) Confirm Output Setting

After running your gpioset command, confirm with:

gpioinfo | grep SODIMM

Pin should show “output” and “active high” state matching your command.

d) Container Usage

If using from inside a container, ensure the correct chip device is passed through using the --device flag (e.g., --device=/dev/gpiochip2). For production, pass only those needed.

Summary Checklist

  • Use the new gpioset syntax and preferably SODIMM names
  • Confirm pin direction and value via gpioinfo
  • Make sure no other process or device tree node is reserving the pin
  • If in a container, pass the correct /dev/gpiochip* device

Let me know if you continue to see issues with SODIMM name usage or after these checks.

Best regards,
Toradex AI Assistant.

3

@ToradexAI

Hello

Thanks for the answer.

Just to clarify. I don’t need my own image at the moment, but the official minimal image that the easy installer offers me.

I have now done what was suggested:

root@verdin-imx8mp-15289951:~# gpioset -t0 SODIMM_34=0
root@verdin-imx8mp-15289951:~# gpioinfo | grep SODIMM_34
line 19: “SODIMM_34” output

root@verdin-imx8mp-15289951:~# gpioset -t0 SODIMM_30=0
root@verdin-imx8mp-15289951:~# gpioinfo | grep SODIMM_30
line 25: “SODIMM_30” output

The pins remain at 0.6V (SODIMM_34) or 1.8V (SODIMM_30). No change when I set to 1.

Since I don’t have my own device tree I’m wondering if the device tree in 7.3 upstream version is broken. Do you know anything about it?

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 René,

Thank you for following the steps and providing the details.

Given that you are using the official Torizon 7.3 minimal image and have not made any device tree modifications, it is possible that there was a change in the default device tree configuration between Torizon 6.8 and 7.3. When gpio lines do not respond to user commands and stay at a fixed voltage, it typically means that the pins are not configured as GPIOs in the device tree, or they are still in use by another subsystem.

What Might Be Happening

  • Pin Multiplexing: The affected pins (SODIMM_34 and SODIMM_30) could be assigned to an alternate function (e.g., UART, I2C, SPI, etc.) by default in the device tree of the new 7.3 release. In this case, gpioset can show the correct label, but the pin is not electrically behaving as a GPIO.
  • Device Tree Changes: It’s possible that the device tree in the 7.3 release assigns these pins differently than in 6.8, and this could be an intentional change reflecting hardware requirements.

How to Diagnose

  1. Check Pin Assignment with gpioinfo

    • You’ve already checked and the pins are labeled, which is a good sign.

  2. Check for Conflicts

    • Even if the label is set, another driver or subsystem might have reserved these pins. With Torizon 7.3 and Linux 6.6, sometimes labeled pins might not be exclusively available for GPIO if, for example, a UART or I2C device has a claim on them in the device tree.

  3. Check the Release Notes and Known Issues

    • Review the TorizonCore release notes for Torizon 7.3 to see if pin multiplexing changes or regressions have been reported.

Next Steps

  • Compare SODIMM_34 and SODIMM_30 Defaults: See what their default functions are in the Verdin iMX8M Plus datasheet and if the 7.3 device tree aligns with that. (Typically SODIMM_34 is GPIO1_IO19, SODIMM_30 is GPIO1_IO25; make sure these aren’t being consumed by a peripheral in the device tree.)
  • Device Tree Overlay (if needed):

Summary

  • It’s likely a result of a device tree change in 7.3.
  • The sysfs and libgpiod user interface changes alone do not cause the voltages to stay fixed.
  • This is not a hardware issue; it’s probably pinmux or device tree related.
  • If you require these pins for GPIO, a device tree overlay may be necessary.

Let me know if you’d like step-by-step assistance creating a device tree overlay for these pins. You can also check the links below for further reference:

Best regards,
Toradex AI Assistant.

5

@ToradexAI

The link for the 7.3 relaese you gave me (High performance, low power Embedded Computing Systems | Toradex Developer Center) does not exist.

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:

Thank you for drawing my attention to this. You are correct—the direct link I provided for Torizon OS 7.3 release notes is not currently available. At this time, Toradex does not provide explicit, version-by-version release notes for Torizon OS 7 “minimal” images on the developer site.

To monitor release changes and documentation, you may refer to these resources:

For device tree or pinmux issues like the one you’re seeing, the device tree overlays and customization guides above can help resolve differences between versions.

If you need help creating a device tree overlay for SODIMM_34 and SODIMM_30 to restore GPIO behavior, let me know—I’m happy to provide a step-by-step example.

Best regards,
Toradex AI Assistant.

7

Dear @rema,

Thank you for raising your question with us and talking to the @ToradexAI.

I had a quick look at the versions you are using for both TorizonOS 6 and 7. It appears that for TorizonOS 6 you are using an upstream image. is this on purpose?

Concerning the issue you are facing, I saw on the verdin development board that the pins SODIMM_30 and SODIMM_34 go towards the audio codec via I2S. this means that if you want to use those pins as GPIOs you will have to mux them as GPIOs within the device tree. In that case you will need to mux the pin in &iomuxc as a GPIO and give it the correct pad control. Also remember to disable the audio codec with this approach.

Alternatively you could also consider using the determined GPIOs on the other end of the banks which are by default already set as such (gpio_0, gpio_1, etc.)

Best regards,
Collin

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 René,

Thank you for providing Collin’s feedback—his explanation aligns with the root cause of your issue on Torizon OS 7.

Summary:
On the Verdin Development Board, SODIMM_30 and SODIMM_34 are, by default, routed to the onboard audio codec (via I2S) through the device tree configuration. In Torizon OS 6, you may have been using an upstream image where these pins were available as GPIOs by default. However, in Torizon OS 7, the official minimal image configures them for audio, preventing GPIO operations.

Why GPIO Doesn’t Work
Because the device tree currently assigns these pins to the audio codec, trying to set them as GPIOs from userspace has no electrical effect—they remain held by their primary function and you observe voltages that do not correspond to GPIO logic levels.

How to Resolve

Option 1:
Create a device tree overlay for Torizon OS 7 to:

  1. Disable the audio codec (so the pins are no longer reserved for I2S use)
  2. Remux SODIMM_30 and SODIMM_34 as GPIOs in the &iomuxc section.

Here is a sample overlay structure for these pins (adapt to your exact board and kernel version):

/dts-v1/;
/plugin/;

/ {
    fragment@0 {
        target = <&iomuxc>;
        __overlay__ {
            pinctrl_mygpio: mygpiogrp {
                fsl,pins = <
                    MX8MM_IOMUXC_GPIO1_IO19_GPIO1_IO19 0x104  // SODIMM_34
                    MX8MM_IOMUXC_GPIO1_IO25_GPIO1_IO25 0x104  // SODIMM_30
                >;
            };
        };
    };

    fragment@1 {
        target-path = "/some/audio/node";
        __overlay__ {
            status = "disabled";
        };
    };
};

See:

Note: You will need to identify the correct node name for the audio codec in your board’s device tree and disable it. Refer to the Verdin Development Board documentation for pin assignments.

Option 2:
Use GPIOs already configured as generic purpose inputs/outputs (e.g., gpio_0, gpio_1, etc.) that do not require device tree changes. See your board’s SODIMM pinout table for these.

If you’d like step-by-step instructions on building and deploying the device tree overlay, just let me know!

Best regards,
Toradex AI Assistant.

10

Thank you for answering.

We have our own extension borad connected to a mallow and I really need exactly these pins, as far as I understand.

How do i write a correct overlay for these pins? I can’t quite get on with it. Are there any examples?

Beste regards
René