GPIO access to SODIM 281 has no effect on Apalis IMX8

JanS · September 14, 2021, 1:41pm

Hi All,
we use Apalis IMX8 with Torizon 5.4.115-5.3.0+git.dbdbcabf0f98 (no customizations so far) and would like to use SODIM 275 and 281 as GPIO output. According to the UM, this means we want to use mode 3 for both pins:

X1 Pin	i.MX 8 Ball Name	Ball	ALT0	ALT1	ALT3	Type	Default Mode	Reset State	Power Block
275	SIM0_GPIO0_00	AP46	DMA.SIM0.POWER_EN		LSIO.GPIO0.IO05	GPIO	ALT3	PD	VDD_SIM_3P3
281	LVDS1_I2C0_SCL	BL35	LVDS1.I2C0.SCL	LVDS1.GPIO0.IO02	LSIO.GPIO1.IO12	GPIO	ALT0	PU	VDD_LVDS_DIG_3P3

Checking the device tree sources, I see following entries for 275:

#define IMX8QM_SIM0_GPIO0_00                      5
#define IMX8QM_SIM0_GPIO0_00_DMA_SIM0_POWER_EN    IMX8QM_SIM0_GPIO0_00 0
#define IMX8QM_SIM0_GPIO0_00_LSIO_GPIO0_IO05      IMX8QM_SIM0_GPIO0_00 3
 
    /* Apalis LCD1_ */
    pinctrl_sim0_gpios: sim0gpiosgrp {
      fsl,pins = <
        /* Apalis LCD1_G5 */
        IMX8QM_SIM0_CLK_LSIO_GPIO0_IO00      0x00000021
        /* Apalis LCD1_G3 */
        IMX8QM_SIM0_GPIO0_00_LSIO_GPIO0_IO05 0x00000021
        /* Apalis TS_5 */
        IMX8QM_SIM0_IO_LSIO_GPIO0_IO02       0x00000021
        /* Apalis LCD1_G4 */
        IMX8QM_SIM0_RST_LSIO_GPIO0_IO01      0x00000021
      >;
    };

and for 281:

#define IMX8QM_LVDS1_I2C0_SCL                  58
#define IMX8QM_LVDS1_I2C0_SCL_LVDS1_I2C0_SCL   IMX8QM_LVDS1_I2C0_SCL 0
#define IMX8QM_LVDS1_I2C0_SCL_LVDS1_GPIO0_IO02 IMX8QM_LVDS1_I2C0_SCL 1
#define IMX8QM_LVDS1_I2C0_SCL_LSIO_GPIO1_IO12  IMX8QM_LVDS1_I2C0_SCL 3
 
    /* Apalis LCD1_G6+7 */
    pinctrl_lvds1_i2c0_gpios: lvds1i2c0gpiosgrp {
      fsl,pins = <
        /* Apalis LCD1_G6 */
        IMX8QM_LVDS1_I2C0_SCL_LSIO_GPIO1_IO12    0x00000021
        /* Apalis LCD1_G7 */
        IMX8QM_LVDS1_I2C0_SDA_LSIO_GPIO1_IO13    0x00000021
      >;
    };

I can confirm these settings are present in the active device tree, by both, unpacking the dtb file and parsing through the /proc/device-tree/scu/pinctrl file system.
I can also (at least I thought) confirm they are applied during the boot as this is what I see in pinctrl-handles under /sys/kernel/debug/pinctrl

Requested pin control handlers their pinmux maps:
device: scu:pinctrl current state: default
  state: default
    type: MUX_GROUP controller scu:pinctrl group: lvds1i2c0gpiosgrp    (19) function: apalis-imx8qm (0)
    type: CONFIGS_PIN controller scu:pinctrl pin IMX8QM_LVDS1_I2C0_SCL (58)  config 00000003 config 00000021
    type: CONFIGS_PIN controller scu:pinctrl pin IMX8QM_LVDS1_I2C0_SDA (59)  config 00000003 config 00000021
 
    type: MUX_GROUP controller scu:pinctrl group: sim0gpiosgrp         (22) function: apalis-imx8qm (0)
    type: CONFIGS_PIN controller scu:pinctrl pin IMX8QM_SIM0_CLK       (0)   config 00000003 config 00000021
    type: CONFIGS_PIN controller scu:pinctrl pin IMX8QM_SIM0_GPIO0_00  (5)   config 00000003 config 00000021
    type: CONFIGS_PIN controller scu:pinctrl pin IMX8QM_SIM0_IO        (2)   config 00000003 config 00000021
    type: CONFIGS_PIN controller scu:pinctrl pin IMX8QM_SIM0_RST       (1)   config 00000003 config 00000021

or in pinconf-pins at the same location:

pin 5 (IMX8QM_SIM0_GPIO0_00): 0x18000021
pin 58 (IMX8QM_LVDS1_I2C0_SCL): 0x18000021

At the same time, the GPIOs also seem to be exported and set (/sys/kernel/debug/gpio):

gpiochip1: GPIOs 448-479, parent: platform/5d090000.gpio, 5d090000.gpio:
  ...
  gpio-460 (MXM3_281            |sysfs               ) out hi
  ...
gpiochip0: GPIOs 480-511, parent: platform/5d080000.gpio, 5d080000.gpio:
  ...
  gpio-485 (MXM3_275            |sysfs               ) out hi
  ...

but still, the pin 281 measures as low and writing to the GPIO value has no effect, while for 275 it worked out of the box.

kevin.tx · September 15, 2021, 12:29pm

Hi @JanS ,

Welcome to our community.

Thank you for explaining the issue as detailed as you did and mentioning all the steps you have already taken.

Would it be possible for you to send us the device tree files you modified and used, so that we can have a look?

Thank you

Best Regards
Kevin

JanS · September 15, 2021, 12:39pm

Hi @kevin.tx,
thank you for the quick response. So far I have not modified the files, and used whatever was on the board. fw_printenv shows the following file being used: fdtfile=imx8qm-apalis-v1.1-eval.dtb
imx8qm-apalis-eval.dtb (162.6 KB)
And there is also an overlay defined in overlays.txt: fdt_overlays=apalis-imx8_hdmi_overlay.dtbo, which was also taken as it was.
apalis-imx8_hdmi_overlay.dtbo (2.1 KB)

kevin.tx · September 15, 2021, 3:00pm

Hi @JanS,

thank you for clarifying. We’ll have a look and let you know as soon as possible.

Best Regards
Kevin

JanS · September 15, 2021, 4:15pm

I am sorry, but in my above response I have attached a wrong devicetree, this is the correct one: imx8qm-apalis-v1.1-eval.dtb (162.7 KB)

kevin.tx · September 20, 2021, 3:20pm

Hi @JanS ,

Thank you for your patience.

I did some tests on my side, to confirm the behaviour. The same as you I used an Apalis iMX8 for it. On my side I installed Torizon the same as you did.

In my setup the applied device tree was:

fdtfile=imx8qm-apalis-v1.1-eval.dtb

The same as you applied on your side.

To test the behaviour of the gpios I did the following steps:

apalis-imx8-06804855:/sys/class/gpio/gpio485# echo "out" > direction 
apalis-imx8-06804855:/sys/class/gpio/gpio485# echo 0 > value
apalis-imx8-06804855:/sys/class/gpio/gpio485# echo 1 > value
apalis-imx8-06804855:/sys/class/gpio/gpio485# cd ..
apalis-imx8-06804855:/sys/class/gpio# cd gpio460
apalis-imx8-06804855:/sys/class/gpio/gpio460# echo "out" > direction 
apalis-imx8-06804855:/sys/class/gpio/gpio460# echo 0 > value
apalis-imx8-06804855:/sys/class/gpio/gpio460# echo 1 > value
apalis-imx8-06804855:/sys/class/gpio/gpio460# cat /sys/kernel/debug/gpio

On both pins I saw the output toggling as expected.
In what way are you writing to the gpio pins on your side? And do you have any new findings on your side?

Best Regards
Kevin

JanS · September 20, 2021, 3:40pm

Hi @kevin.tx
thanks a lot for the test. Yes, you describe exactly what I did, except that on my side I have not seen any activity on the pin. So far we have just one module, so I can’t rule out a problem on HW side, but I’ll report here any findings once I get a second module, or once I have time to trace the signal on the PCB.

Best Regards,
Jan

kevin.tx · September 21, 2021, 9:08am

Hi @JanS ,

Thanks for sharing that insight.

So is it only happening with this specific pin? Or do you notice other pins not reacting to your inputs?

Best Regards
Kevin

JanS · September 21, 2021, 9:23pm

Hi @kevin.tx,
thank you again for your effort, I have now cleaned all the SODIM module and connector pins, re-plugged the board and now it works. I am sorry to take your time, I should have done this much earlier, but it was the default mode being declared as ALT0 in the datasheet, what let me to search for a software issue instead of a hardware one.

So again, thanks a lot for your support,
Jan

JanS · September 22, 2021, 7:45am

Hi @kevin.tx,
as further update, I can now confirm, that also other GPIOs are working as expected when properly configured via the devicetree. Just while working on it I tried to follow the suggestions from Pin Multiplexing - Changing Pin Functionalities in the Linux Device Tree | Toradex Developer Center but I fear the information presented there is not correct. What I see as a biggest problem, is the fact, that the overlay system seems to only support replacement of values, so when I write the overlay according to the suggestion:

    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_my_gpios>;

the value of pinctrl-0 is overwritten and all the existing values are lost, so what I had to do was to copy the values present in the source device tree and append the newly created one at the end:

    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_cam1_gpios>, <&pinctrl_dap1_gpios>,
      <&pinctrl_esai0_gpios>, <&pinctrl_fec2_gpios>,
      <&pinctrl_gpio3>, <&pinctrl_gpio4>,
      <&pinctrl_gpio_usbh_oc_n>, <&pinctrl_lpuart1ctrl>,
      <&pinctrl_lvds0_i2c0_gpio>, <&pinctrl_lvds1_i2c0_gpios>,
      <&pinctrl_mipi_dsi_0_1_en>, <&pinctrl_mipi_dsi1_gpios>,
      <&pinctrl_mlb_gpios>, <&pinctrl_qspi1a_gpios>,
      <&pinctrl_sata1_act>, <&pinctrl_sim0_gpios>,
      <&pinctrl_usdhc1_gpios>, <&pinctrl_my_gpios>;

Best regards,
Jan

kevin.tx · September 22, 2021, 8:19am

Hi @JanS,

thanks for the detailed update.

I am glad to hear that the initial issue has been solved. Thank you for letting us know, what the issue was.

About the Pin Multiplexing Article and its information, you can be assured that we will have a look at this. It Is very much appreciated that you pointed this out. I will forward this to the corresponding team.

Have a nice day

Best Regards
Kevin