Verdin iMX8MM Q 2GB IT GPIOs avaliability

Hello Community!

I’m having trouble with some of the GPIO pins on the following hardware:
SoM: Verdin iMX8MM QUAD 2GB IT V1.1C on custom carrier board
I’m using TorizonOS v6.4.0-devel-202309-build.13

The problem is the following:
We want to use GPIO3[10], [11], [12], [13] pins as GPIO outputs. They are mapped as gpiochip2 in TorizonOS. Initial state of those pins is the following (output of gpioinfo command):

line 10:SODIMM_162 input
line 11:SODIMM_164 input
line 12:SODIMM_166 input
line 13:SODIMM_168 input

After I set those pins with gpioset their configuration also changes, as expected.
This is the output of gpioinfo after I’ve run the ./gpioset -c 2 10=0 and ./gpioset -c 2 11=0

line 10:SODIMM_162 output
line 11:SODIMM_164 output
line 12:SODIMM_166 input
line 13:SODIMM_168 input

But on the output of physical pins on the SODIMM nothing changes.
Additionally, we are using GPIO3[8] and GPIO3[9], which have the same configuration as the upper-mentioned GPIOs and setting them with gpioset results in expected behaviour.
This is the table from the iMX8M processor datasheet:

image

The only difference between those two sets of pins is that SODIMM pins 162, 164, 166, 168 are not available on the Verdin SoM with WiFi, but since we are using WiFi-less SoM they should be available as regular GPIOs.

Best regards!

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!


Hello,

I understand you’re facing issues with GPIO pins on the Verdin iMX8MM QUAD 2GB IT V1.1C not reflecting changes physically despite being configured as outputs in TorizonOS.

Given the context, it seems like you’ve correctly identified and configured the GPIOs using the gpioset command, but the expected physical output isn’t observed on the SODIMM pins 162, 164, 166, and 168. Since you’ve mentioned that these pins are not available on Verdin SoMs with WiFi and you’re using a WiFi-less SoM, they should indeed be available for general GPIO use.

Here are a few steps and considerations to troubleshoot this issue:

  1. Verify Pin Configuration: Ensure that the device tree correctly reflects the pins’ intended use as GPIOs. Since these pins might have alternate functions, it’s crucial to confirm that they are not configured for another peripheral in the device tree.

  2. Check for Hardware Conflicts: Even though the pins are not used for WiFi in your module, ensure there are no other hardware conflicts or reserved uses for these pins that might prevent them from functioning as expected.

  3. Power Supply and Signal Integrity: Verify that the power supply to these pins is stable and within the expected voltage range. Also, check for any signal integrity issues that might affect the GPIO performance.

  4. Software Confirmation: Use the gpioget command to confirm the state of the GPIOs after you set them. This can help verify if the software is correctly updating the state, even if it’s not observed physically.

  5. Review GPIO Driver and Controller Settings: Dive into the Linux kernel configuration for the GPIO driver and controller settings specific to the Verdin iMX8MM. There might be specific nuances or limitations for these GPIOs that are not immediately apparent.

  6. Consult the Verdin iMX8MM Datasheet and Carrier Board Design: Ensure that there’s no physical limitation or specific configuration on the carrier board that might affect these GPIOs’ functionality. The custom carrier board design might have specific constraints or differences from the standard Verdin Development Board.

If after these steps the issue persists, it might be beneficial to look into more detailed logs or kernel messages that could hint at what’s preventing the GPIOs from functioning as expected physically. Since you’re working with a custom carrier board, also consider any carrier-specific configurations or limitations that might not be present in standard Toradex documentation or reference designs.

Best regards,

Please, also check if these links can help you solve your problem:

How to Use GPIO on Torizon OS | Toradex Developer Center.


How did you like my response?

:+1: :-1:

Dear @kratabl,

Welcome to our community and thank you for contacting us here.
While the @ToradexAI gave some okay leads, I believe the issue might be something else. I have a suspicion, that an incorrect device tree is used for your application. Potentially the issue might lie in the fdtfile. Maybe you are using a wifi variant while you actually want to use the non-wifi.

In this developer page you can find a way to set your fdtfile to the non-wifi device tree blob. For this to work you will have to stop the Uboot and follow alter the fdtfile as written in the article.

Alternatively you can change it in Linux after booting. For that you can look up this article and use the printenv instruction to see what is available and what you are using. After that you can change it with the setenv instruction, followed by saveenv.

Please let me know how you fare with this.

Best regards
Collin

Hello @collin.tx,

I’ve already checked that I’m using non-wifi device tree blob. To be exact, I’m using imx8mm-verdin-nonwifi-dev.dts device tree for my project.
The only thing that concerns me are pinctrls for the ‘usdhc3’ node in `imx8mm-verdin.dtsi’:

pinctrl_usdhc3: usdhc3grp {
		fsl,pins = <
			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x150
			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x150
			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x150
			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x150
			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x150
			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x150
		>;
	};

	pinctrl_usdhc3_100mhz: usdhc3grp100mhz {
		fsl,pins = <
			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x154
			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x154
			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x154
			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x154
			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x154
			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x154
		>;
	};

	pinctrl_usdhc3_200mhz: usdhc3grp200mhz {
		fsl,pins = <
			MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK		0x156
			MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD		0x156
			MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0		0x156
			MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1		0x156
			MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2		0x156
			MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3		0x156
		>;
	};

Correct me if I’m getting this wrong, but according to this it looks like imx8mm-verdin-nonwifi-dev.dts configures Pin MUX to be used for usdhc3 peripheral, not as gpios since it includes imx8mm-verdin.dtsi which configures these pins as usdhc3_data pins.

Best regards,
kratabl

Hi @collin.tx, reminder for this topic.
Ping, ping :slight_smile:

Hello @kratabl thank you for the reminder.
We are currently checking this issue. I will get back to you as soon as we have some further information or questions. :slight_smile:

Dear @kratabl,

Please excuse the delay in reply.
You are indeed correct in your assumption regarding usdhc3.
Here is the plan to help you create a functioning device tree to use the GPIOs:
1.) We need to make sure that all nodes, which use pinctrl_usdhc3* are disabled. this can be done by checking the whole device tree with a tool called find in devicetree.
2.) Using this tool will show all the .dtsi files (and corresponding lines) which contain the entered pinctrl.
3.) disable all the nodes which use that pinctrl with status = "disabled".
4.) From here you should create a new pinctrl group as GPIOs with help of the imx8mm-pinfunc.h provided by NXP. This file should be contained within your device tree and hold the macros for muxing. As I see it you will have to use these macros for your pinctrl.

#define MX8MM_IOMUXC_NAND_DATA04_GPIO3_IO10                                 0x11C 0x384 0x000 0x5 0x0
#define MX8MM_IOMUXC_NAND_DATA05_GPIO3_IO11                                 0x120 0x388 0x000 0x5 0x0
#define MX8MM_IOMUXC_NAND_DATA06_GPIO3_IO12                                 0x124 0x38C 0x000 0x5 0x0
#define MX8MM_IOMUXC_NAND_DATA07_GPIO3_IO13                                 0x128 0x390 0x000 0x5 0x0

5.) For your newly created pinctrl group you will also need padcontrols after your macros. We can assume, that the padcontrol is identical to the ones used for a gpio of the same number, such as 0x106 in this example:

pinctrl_gpio1: gpio1grp {
		fsl,pins =
			<MX8MM_IOMUXC_NAND_CE3_B_GPIO3_IO4		0x106>;	/* SODIMM 206 */
	};

Please note, that the padcontrol number could potentially be different, in which case we will have to refer to the reference manual of the NXP SoC.
6.) Eventually your new pinctrl should contain something similar to this:

<MX8MM_IOMUXC_NAND_DATA04_GPIO3_IO10		0x106>;
<MX8MM_IOMUXC_NAND_DATA04_GPIO3_IO11		0x106>;
<MX8MM_IOMUXC_NAND_DATA04_GPIO3_IO12		0x106>;
<MX8MM_IOMUXC_NAND_DATA04_GPIO3_IO13		0x106>;

Please let me know how you fare with this.

Best regards
Collin

Hi @collin.tx,

Thank you for the solution, GPIOs work like a charm now.
Padcontrol numbers are indeed 0x106.
If anyone encounters this issue in the future follow the solution that Collin wrote above and don’t forget to use the newly-defined pinctrl group in the iomuxc node.
In my case the iomuxc device-tree node, defined in imx8mm-verdin.dtsi looks like this:

&iomuxc {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_gpio1>, <&pinctrl_gpio2>,
		    <&pinctrl_gpio3>, <&pinctrl_gpio4>,
		    <&pinctrl_gpio7>, <&pinctrl_gpio8>,
		    <&pinctrl_gpio_hog1>, <&pinctrl_gpio_hog2>, <&pinctrl_gpio11>,
			<&pinctrl_gpio_hog3>, <&pinctrl_pmic_tpm_ena>;

where pinctrl_gpio11 is actually

	pinctrl_gpio11: gpio11grp {
		fsl,pins = <
			MX8MM_IOMUXC_NAND_DATA04_GPIO3_IO10		0x106	/* SODIMM 162 */
			MX8MM_IOMUXC_NAND_DATA05_GPIO3_IO11		0x106	/* SODIMM 164 */
			MX8MM_IOMUXC_NAND_DATA06_GPIO3_IO12		0x106	/* SODIMM 166 */
			MX8MM_IOMUXC_NAND_DATA07_GPIO3_IO13		0x106	/* SODIMM 168 */
		>;
	};

Of course, it would be ideal to create your own device tree overlay where this pinctrl node is simply added to the list of nodes.

Best regards!

Thank you for your reply @kratabl and I am glad I could be of help :slight_smile:

1 Like