GPIO Device tree change?

Technical Support
, ,
1

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)

2

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
3

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.

4

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?

5

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

6

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.

image
image857×323 43.9 KB

7

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
8

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!
9

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.