GPIO Device tree change?

We have recently been trying to update our system from Torizon 5.7 to Torizon 6.8.

We finally have everything working, except for this:

On the previous 5.7:

From GPIOINFO (shortened to relevant lines).
gpiochip2 - 32 lines:
line 20: “SODIMM_19” unused input active-high
gpiochip3 - 32 lines:
line 28: “SODIMM_21” unused input active-high
line 29: “SODIMM_256” unused output active-high

Now on 6.7
gpiochip2 - 32 lines:
line 20: “SODIMM_19” “hpd” input active-high [used]gpiochip3 - 32 lines:
line 28: “SODIMM_21” “reset” output active-low [used]
line 29: “SODIMM_256” “regulator-dsi-hdmi” output active-high [used]

when we try and set these pins, as we did on 5.7, we get responded with a “busy” (error 16).

Was there a device tree update? I tried to see if these pins had changed between versions but did not see anything in your documentation file: verdin_imx8mp_datashate (version1.1)

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


:handshake:

It appears that the GPIO pins you are trying to use are now assigned to specific functions in Torizon 6.8, which is why you are encountering the “busy” error. This indicates that these pins are already in use by other peripherals or functions as defined in the device tree.

To resolve this, you will need to modify the device tree to free up these pins. Here are the steps to do so:

  1. Identify the Conflicting Functions:

    • SODIMM_19 is used as “hpd”.
    • SODIMM_21 is used as “reset”.
    • SODIMM_256 is used as “regulator-dsi-hdmi”.
  2. Create a Device Tree Overlay:

    • You need to create a device tree overlay to disable these functions and reassign the pins as GPIOs.
  3. Example Device Tree Overlay:
    Here is an example of what your device tree overlay might look like:

    /dts-v1/;
    /plugin/;
    
    / {
        fragment@0 {
            target = <&iomuxc>;
            __overlay__ {
                pinctrl-0 = <&pinctrl_my_pins>;
            };
        };
    
        fragment@1 {
            target-path = "/soc";
            __overlay__ {
                pinctrl_my_pins: my_pins {
                    fsl,pins = <
                        MX8MP_IOMUXC_SODIMM_19_GPIO5_IO20 0x06000021
                        MX8MP_IOMUXC_SODIMM_21_GPIO5_IO28 0x06000021
                        MX8MP_IOMUXC_SODIMM_256_GPIO5_IO29 0x06000021
                    >;
                };
            };
        };
    
        fragment@2 {
            target = <&hpd>;
            __overlay__ {
                status = "disabled";
            };
        };
    
        fragment@3 {
            target = <&reset>;
            __overlay__ {
                status = "disabled";
            };
        };
    
        fragment@4 {
            target = <&regulator_dsi_hdmi>;
            __overlay__ {
                status = "disabled";
            };
        };
    };
    
  4. Build and Apply the Overlay:

    • Save the above content to a file, for example, custom_gpio_overlay.dts.
    • Use the TorizonCore Builder Tool

SODIMM_256 is a power management pin (CTRL_SLEEP_MOCI#) and cannot be used as a regular GPIO. In version 5.7, its functionality was not properly implemented, but this was fixed in the 6.7 release (ELB-5454).

Changes to SODIMM_19 were introduced in the 6.6 release to fix the ELB-5585 issue.

SODIMM_21 is used to control DSI-HDMI and DSI-LVDS adapters, as per ELB-3364.

The Verdin iMX8MP datasheet describes the hardware. Software changes are not reflected there.

All changes to the Device Tree and Device Tree overlays are available at git.toradex.com.

That makes sense then. What are some GPIO’s (that the device tree have has general purpose) that we can pick that won’t be taken in the future?

According to the Verdin Family Specification, GPIO_1 - GPIO_4 (X1 pins 206, 208, 210, and 212) are always compatible, so they will never be reserved for other purposes in the future. You are free to use any other available pins as GPIO, but we cannot guarantee that they won’t be reserved for other uses in the future

Thank you for your replies! they have been very helpful. The Family specification sheet shows these 8 pins as always compatible (seen in screenshot), which is great, however we need a few more pins than that for our hardware. I believe the best solution would be to change the functionality of other pins that are “always compatible” that we are not using. Would you agree this is the best solution, rather than using other GPIO’s that could be reserved in the future? (example, using extra SPI pins that are unused for GPIO functionality).

If this is the case, for just changing pin Signal Group to GPIO what is the simplest solution? I have found a few options in your documentation.

  1. Direct pin muxing: Pin Multiplexing - Changing Pin Functionalities in the Linux Device Tree | Toradex Developer Center
  2. Device Tree Modification: How to Customize Device Trees | Toradex Developer Center
  3. Device Tree Overlays on Torizon | Toradex Developer Center

We are on the iMX8MPlus if that has any effect on the most desirable process.

The SD_1_xx pins listed in the tables are marked as ‘Always compatible’ regarding the SD card interface. This means that any existing or future Verdin module will use these pins for the SD card interface. If you don’t require SD card support on your custom carrier board, you can change the pin functionality to GPIO by modifying the pin multiplexing in the Device Tree, as described in the first two articles you provided links to

1 Like

Most of the documentation makes sense, but I have a few questions regarding the process.

All of the “Always Compatible” pins are being used by our custom hardware so we are having to dip into the Reserved pins.

  •  17
    
  •  19 
    
  • 21
  • 93
  • 95
  • 34
  • 36
  • 38
  • 256

are a list of pins we came up with that we would like to use, mainly based on the alternate functionalities and that we do not predict that we will need them

  1. How can we take a pin back that you guys are using? For example, pins 19, 21 and 256 (that you recently took) we would like to keep using since we do not use an HDMI port, nor the new power control feature of 256.

  2. How do we know which device tree overlay to use if we want to overwrite a list of pins and confirm that they won’t get overridden by other features in the future? Device Tree Overlays on Torizon | Toradex Developer Center says “pick a device tree overlay” and does not go into much more about which to use, just how to show which are available.

  3. We want to create an overlay that assigns this pins as GPIO’s and won’t be taken by future releases, what can we do in this process to verify that we will get to keep using the “reserved” pins that we pick?

TL:DR it seems that We have two hurdles to jump through, are these correct?:

  1. Reassigning pins to be GPIO’s
  2. have our usage over the pins be used rather than the toradex default usage.
    Thanks again for all your help!

By modifying a device tree.

You need to create you custom one . We can not guarantee that any pins functionality will not be overwritten in future unless pins are belong to the “always compatible” group.

Pinmuxing is done by device tree. So if you create and always use your custom device tree pins’ functions will not be altered.

Sorry about the delay, we have been working on this along with other parts of the integration to 6.7 as well.

I would like to get some clarification on this, when to use a device tree, a device tree overlay, etc

In your response you say we must modify the device tree but not the overlay. So i have this question:

  1. Does this mean that every time Toradex modifies the linux\arch\arm64\boot\dts\freescale\imx8mp-verdin.dtsi, we must manually look at the changes and merge them with our custom device tree?

  2. If answer to previous question is yes, If we were to only use device tree overlays, would we no longer have to manually merge every time there is a Device Tree Update?

  3. With our current plan, we would like to use these pins as our additional GPIO’s (we found these from cross referencing the Verdin Family Specification with the verdin_imx8mp_datasheet

  • 17
  • 19
  • 21
  • 93
  • 95
  • 34
  • 36
  • 38
  • 256

Could we use just use a device tree overlay just to modify these to be disable?

  1. If not, could we if we used different pins to just use a device tree overlay?

  2. I am currently thinking no because just as a test, I tried doing this:
    device-trees\overlays\verdin-imx8mp_aevex-gpio-overlay.dts: ( i confirmed with sudo tdx-info -dt that the device tree overlaywas enabled)

/dts-v1/;
/plugin/;

/ {
    /* Disable power management for SODIMM_256 */
    fragment@0 {
        target = <&reg_force_sleep_moci>;
        __overlay__ {
            status = "disabled";
        };
    };
};

but gpioinfo still shows line 29: "SODIMM_256" "regulator-dsi-hdmi" output active-high [used].

We really appreciate your help in our understanding of Toradex’s device tree, and device tree overlays.

I have come a solution that seems to have worked for taking back pins 19, 21 and 256. For 19 and 21, by removing the Toradex DSI-HDMI overlay (since we do not have any physical HDMI ports), pins 19 and 21 were unused. Then I modified the device tree

	/*
	 * By default we enable CTRL_SLEEP_MOCI#, this is required to have
	 * peripherals on the carrier board powered.
	 * If more granularity or power saving is required this can be disabled
	 * in the carrier board device tree files.
	 */
	/* 
	 * reg_force_sleep_moci: regulator-force-sleep-moci {
	 *	compatible = "regulator-fixed";
	 *	enable-active-high;
	 *	
	 *	gpio = <&gpio4 29 GPIO_ACTIVE_HIGH>;
	 *	regulator-always-on;
	 *	regulator-boot-on;
	 *	regulator-name = "CTRL_SLEEP_MOCI#";
	 * };
	*/

	/* Aevex replacement for the above SODIMM 256 pin */
	reg_force_sleep_moci: regulator-force-sleep-moci {
		fsl,pins = <MX8MP_IOMUXC_SAI3_RXC__GPIO4_IO29 0x1c4>;
	};

And this allowed pin256 to be GPIO again. Thank you for all your help