Torizon: Defining GPIO in DTO

Hi team,

I’ve been having issues trying to add custom defined GPIOs in Torizon even with the latest images (Colibri iMX8X V1.0B, so recompiled with Yocto to get the correct machine).

Very simple change: 2 pins (SODIMM 28 and 30) that are not originally defined as GPIO, define them as GPIO. By default, gpioset won’t do anything.

Following some other posts I tried using the below dts but the kernel won’t boot (Stuck at “Starting kernel”). I checked that several customers had the same issue when trying to change GPIOs pinmux:

/dts-v1/;
/plugin/;

#include </device-tree-overlays/include/dt-bindings/pinctrl/pads-imx8qxp.h>

/ {
    compatible = "toradex";
    fragment@0 {
        target = <&iomuxc>;
        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <&pinctrl_my_gpios>; 
            pinctrl_my_gpios: gpiomuxgrp {
            	fsl,pins = <
                     SC_P_UART1_TX_LSIO_GPIO0_IO21 0x41
                     SC_P_UART1_RX_LSIO_GPIO0_IO22 0x41
                >;

            };
        };
    };
};

Even without any pins at fsl,pins, the module won’t boot. My thoughts are that this overlay overwrites ALL of the iomuxc node.

After checking the original device tree I managed to make it work by “hijacking” one of the already activated nodes pinctrl_ext_io0 :

/dts-v1/;
/plugin/;

#include </device-tree-overlays/include/dt-bindings/pinctrl/pads-imx8qxp.h>

/ {
    compatible = "toradex";
    fragment@0 {
        target = <&pinctrl_ext_io0>;
        __overlay__ {
            fsl,pins = <
                 SC_P_UART1_TX_LSIO_GPIO0_IO21 0x41
                 SC_P_UART1_RX_LSIO_GPIO0_IO22 0x41
            >;            
        };
    };

    fragment@1{
        target = <&pwm0>;
        __overlay__ {
            status = "disabled";
        };
    };

    fragment@2{
        target = <&pwm1>;
        __overlay__ {
            status = "disabled";
        };
    };
    
};

Needless to say, this is not ideal since we are overwritting stuff. What would be the correct way in changing these GPIOs? Thanks.

In case we cannot create new nodes directly in iomuxc without rewritting the whole node, an idea: Add an empty pinctrl node inside iomuxc called “custom_gpios”, activated by default, that the customers can target and overwrite without touching iomuxc (avoiding breaking the kernel).

Hi @alvaro.tx,

I don’t think an overlay on an existing node would overwrite the entire node.

As an example we have this overlay that enables the lvds interface on Apalis i.MX6Q: https://github.com/toradex/device-tree-overlays/blob/toradex_5.4.y/overlays/apalis-imx6-lvds-overlay.dts

In the above overlay it access the previously existing ldb node and changes the status field. But as you can see in the source: https://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/boot/dts/imx6q-apalis-eval.dts?h=toradex_5.4.y#n270

The ldb node is more than just the status field.

Actually now that I look at the source dts for the i.MX8X I noticed that the iomuxc node is slightly different here compared to other SoCs. Notice how there’s iomuxc and then a sub-node of colibri-imx8qxp and then within this sub-node is all the pinctrl nodes.

&iomuxc {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_hog0>, <&pinctrl_hog1>, <&pinctrl_hog2>,
			<&pinctrl_ext_io0>, <&pinctrl_mxt_ts>;

	colibri-imx8qxp {

Perhaps all the pinctrl nodes are required to be in this colibri-imx8qxp sub-node. Which might explain why your overlay even with no fsl,pins causes a kernel error.

Unfortunately I don’t have access to an i.MX8X myself to test this theory.

Best Regards,
Jeremias

Hi @jeremias.tx,
Any update regarding this?
I need to activate i2c3, spi2 and some pins to be pulled up at the boot.
Whenever I include &iomuxc in overlay and deplay, the system doesn’t boot any more

Hi @digec42482,

It is possible to include iomuxc in an overlay as shown in our example overlay here: apalis-imx8_ar0521_overlay.dts « overlays - device-tree-overlays.git - Sources for Device Tree Overlays

However, typically it works best if you’re only changing pinctrl-0 in iomuxc. Meaning working with pre-existing pinctrl groups. In my experience trying to add/redefine pinctrl groups via overlay results in strange and unpredictable behavior. Like the booting issue you’re seeing.

In my opinion for such changes I would just fall back to the traditional method of working on the device tree files rather than overlays.

Best Regards,
Jeremias