(IMX8MP) - Changing GPIOs in Device Tree using Torizoncore Builder, but measuring no change in state

Technical Support
, , , ,
1

Hello,
I’ve been working to set up pin multiplexing for our verdin imx8mp on the mallow carrier board, but have not been seeing the desired results.

Overview
I’m trying to configure all the pins on the X19 primary extension header to be GPIOs. Currently, I’m trying to have them all be pulled down, thus outputting 0v on init (represented by 0x104 in the configuration). However, after applying the different device trees & overlays, measuring the pins on that header with an oscilloscope showed some of them at 1.8v while others were at 0.

What I’ve Tried
I’ve tried creating both my own device tree overlay with the configuration and editing the imx8mp-verdin.dtsi file directly to change the configuration. The pin that I’m focusing on currently is SPDIF_TX (configured to CAN1_TX by default). This is what my modification to the imx8mp-verdin.dtsi file’s flexcan1 pincontrol group looks like:

	flexcan1grp
	{
		fsl, pins = <MX8MP_IOMUXC_SPDIF_RX__GPIO5_IO4 0x104>, // Replaced by CMC
		<MX8MP_IOMUXC_SPDIF_TX__GPIO5_IO3 0x104>; // Replaced by CMC
	};

Based on my understanding, this should configure both RX and TX as pull-down GPIOs. However, I’m still seeing TX at 1.8v. I’ve made similar changes to the other pins on the header, but none of them have changed from their default state.

Is there something I’m missing here? Any advice on what to try next? Any help would be appreciated

Output of tdx-info

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           5.15.177-6.8.2+git.5a6602cc6c32 #1-TorizonCore SMP PREEMPT Fri Mar 21 16:22:58 UTC 2025
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/f75f7252e68327bc4f7f609b75b0313055b3bb63deeae8889eb6722c98a29647/0
Distro name:              NAME="TorizonCore"
Distro version:           VERSION_ID=6.8.2-build.30
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx8mp-15230162
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version:          0058 V1.1B
Serial number:            15230162
Processor arch:           aarch64
------------------------------------------------------------

(using torizon OS 6 because that’s what I was able to get the crank & weston containers running consistently on)

Regards,
Andrew

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 Andrew,

Thank you for your detailed explanation! Your approach and documentation are great, and you’re definitely on the right track. The issue likely comes from a few places in your device tree configuration and the process for ensuring the pins are functioning purely as GPIOs.

Points to Address

  1. Pin Ownership / Peripheral Conflict

    • The SPDIF_TX pin is assigned by default to the CAN1 peripheral as CAN1_TX. Even if you change just the pinctrl values, the flexcan1 driver may still claim the pin.
    • Solution: Explicitly disable the flexcan1 node in your overlay or device tree.
      &flexcan1 {
    status = "disabled";
};
      This will prevent the kernel from attaching the CAN1 function to those pins.
      (Reference)

  2. Pinctrl Pad Value

    • The value 0x104 configures the pad with “pull-down” and “SION” (software input). While this should work for a pulled-down GPIO, for output use a more typical value: 0x184 (output, pull-down) or 0x1c4 (output, pull-up), depending on your needs (Reference).

  3. Pin Assignment to GPIO

    • Ensure the pins are placed into a hog configuration so they are exported and set as outputs with initial state:
      &gpio5 {
    gpio5_io3: gpio5_io3_output {
        gpio-hog;
        gpios = <3 GPIO_ACTIVE_HIGH>;
        output-low;
        line-name = "gpio5_io3_output";
        status = "okay";
    };
    gpio5_io4: gpio5_io4_output {
        gpio-hog;
        gpios = <4 GPIO_ACTIVE_HIGH>;
        output-low;
        line-name = "gpio5_io4_output";
        status = "okay";
    };
};
      This will make the pins available as /dev/gpiochip devices and keep them low on boot.
      (Reference: Customizing Device Trees)

  4. Correct Header Pin Mapping

Recommended Device Tree Overlay Example

/dts-v1/;
/plugin/;

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

    fragment@0 {
        target = <&flexcan1>;
        __overlay__ {
            status = "disabled";
        };
    };

    fragment@1 {
        target = <&iomuxc>;
        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <&pinctrl_flexcan1_gpio>;
        };
    };

    fragment@2 {
        target = <&gpio5>;
        __overlay__ {
            gpio5_io3: gpio5_io3_output {
                gpio-hog;
                gpios = <3 GPIO_ACTIVE_HIGH>;
                output-low;
                line-name = "gpio5_io3_output";
            };
            gpio5_io4: gpio5_io4_output {
                gpio-hog;
                gpios = <4 GPIO_ACTIVE_HIGH>;
                output-low;
                line-name = "gpio5_io4_output";
            };
        };
    };

    fragment@3 {
        target-path = "/bus@30800000/iomuxc@30330000";
        __overlay__ {
            pinctrl_flexcan1_gpio: pinctrl_flexcan1_gpio {
                fsl,pins = <
                    MX8MP_IOMUXC_SPDIF_TX__GPIO5_IO3 0x184
                    MX8MP_IOMUXC_SPDIF_RX__GPIO5_IO4 0x184
                >;
            };
        };
    };
};
  • Use 0x184 pad control for stable, output-low GPIO.
  • Expand the above for all pins on X19 as needed.

How to Apply and Test

  1. Build the overlay and apply with TorizonCore Builder.
  2. Reboot your device and run:
    gpioinfo
    • Confirm your pins are correctly configured as output and low.

Further Guidance

  • Make sure only overlays (not direct .dtsi edits) are used when possible, to ease migrations and updates.
  • If you continue to see unexpected voltages, re-verify the physical header mapping and check for other conflicting definitions in other overlays or base trees.

References

Please let me know if you need help adapting this for the rest of the X19 header or if you encounter further issues!

Best regards,
Toradex AI Assistant.

3

nevermind, figured it out. I was misunderstanding a lot of the information, but was able to piece it together from the various articles and other tech support things after some more trial and error