Cannot use GPIO3_IO16 and GPIO3_IO22 from Cortex-M on Verdin iMX8M-Plus

vix · January 9, 2025, 8:48am

I’ve just found another issue while using GPIO pins from Cortex-M of Verdin iMX8M-Plus running Torizon OS 6.8.0.
I think it’s another mis-configuration of device tree, but it’s not clear to me if I can get the usage I need.
I need to use two pins GPIO3_IO16 (SODIMM_64) and GPIO3_IO22 (SODIMM_32) as general purpose inputs.
But this doesn’t work, and even if I apply low or high voltage to the pin, I always read “low”.

I suspect the pin configurations is done in different way from some other node in .dts files.
I looked in the tree, but I can’t find which is the reason for this.
Looking to the datasheet I see that:

GPIO3_IO16 can be used as peripheral function pin for:
- I2C3 - but I disabled this node. But pinctrl_flexspi0 node is configured in imx8mp-verdin.dtsi. Should I delete this node too if I don’t need I2C3?
- USDHC3 - I understand this is used on the module to connect the EMMC (so I don’t think I can disable it)
- NAND - it’s disabled in imx8mp.dtsi
GPIO3_IO22 can be used as peripheral function pin for:
- SAI5 - it’s disabled in imx8mp.dtsi
- SAI1 - it’s disabled in imx8mp.dtsi, but pinctrl_sai1 node is configured in imx8mp-verdin.dtsi. Should I delete this node too if I don’t need SAI1?
- PDM - not configured in Toradex dts files
- CAN1 - it’s disabled, and moreover pinctrl_flexcan1 node doesn’t refer to SODIMM_32

So, basically the question is:
are pinctrl_flexspi0 and pinctrl_sai1 responsible to the mis-configuration of the two pins (even if I2C3 and CAN1 are disabled)?
Because in imx8mp-verdin.dtsi I see

&iomuxc {
	pinctrl_flexspi0: flexspi0grp {
		fsl,pins =
			<MX8MP_IOMUXC_NAND_ALE__FLEXSPI_A_SCLK		0x1c2>,	/* SODIMM 52 */
			<MX8MP_IOMUXC_NAND_CE0_B__FLEXSPI_A_SS0_B	0x82>,	/* SODIMM 54 */
			<MX8MP_IOMUXC_NAND_DQS__FLEXSPI_A_DQS		0x82>,	/* SODIMM 66 */
			<MX8MP_IOMUXC_NAND_DATA00__FLEXSPI_A_DATA00	0x82>,	/* SODIMM 56 */
			<MX8MP_IOMUXC_NAND_DATA01__FLEXSPI_A_DATA01	0x82>,	/* SODIMM 58 */
			<MX8MP_IOMUXC_NAND_DATA02__FLEXSPI_A_DATA02	0x82>,	/* SODIMM 60 */
			<MX8MP_IOMUXC_NAND_DATA03__FLEXSPI_A_DATA03	0x82>,	/* SODIMM 62 */
			<MX8MP_IOMUXC_NAND_READY_B__GPIO3_IO16		0x82>;	/* SODIMM 64 */
	};

	pinctrl_sai1: sai1grp {
		fsl,pins =
			<MX8MP_IOMUXC_SAI1_MCLK__AUDIOMIX_SAI1_MCLK		0x96>,	/* SODIMM 38 */
			<MX8MP_IOMUXC_SAI1_RXD0__AUDIOMIX_SAI1_RX_DATA00	0x1d6>,	/* SODIMM 36 */
			<MX8MP_IOMUXC_SAI5_MCLK__AUDIOMIX_SAI1_TX_BCLK		0x1d6>,	/* SODIMM 30 */
			<MX8MP_IOMUXC_SAI5_RXD1__AUDIOMIX_SAI1_TX_SYNC		0x1d6>,	/* SODIMM 32 */
			<MX8MP_IOMUXC_SAI5_RXFS__AUDIOMIX_SAI1_TX_DATA00	0x96>;	/* SODIMM 34 */
	};
};

And I see that both SODIMM 64 and SODIMM 32 are configured in the iomuxc as peripheral function.

ToradexAI · January 9, 2025, 8:49am

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

Hello,

Thank you for reaching out with your question about configuring GPIO3_IO16 and GPIO3_IO22 on the Verdin iMX8M Plus. It seems like the device tree configuration might be affecting the functionality of these GPIO pins.

To resolve this, you can follow these steps to modify the device tree and set the pins as general-purpose inputs:

Identify the Device Tree Files: Locate the device tree source files, such as imx8mp-verdin.dtsi, where the pin configurations are defined.
Review and Modify Pinctrl Settings:
- For GPIO3_IO16 (SODIMM_64), check the pinctrl_flexspi0 node. Ensure this pin is not configured for any peripheral function. You may need to comment out or remove the line that assigns it a peripheral function.
- For GPIO3_IO22 (SODIMM_32), examine the pinctrl_sai1 node. Make sure it is not set for SAI1 or any other peripheral. Again, comment out or remove the relevant line.
Configure Pins as GPIO: Add or adjust entries in the device tree to set these pins as GPIOs. This involves setting the function to GPIO and configuring any necessary pin properties, such as pull-up or pull-down resistors.
Recompile the Device Tree: After making your changes, recompile the device tree and deploy it to your Verdin iMX8M Plus module.
Test the Configuration: Use tools like libgpiod to test the GPIO functionality. Commands like gpioget can help verify that the pin state changes with applied voltage.

By following these steps, you should be able to configure GPIO3_IO16 and GPIO3_IO22 as general-purpose inputs. If you encounter further issues, double-check your device tree modifications for any conflicting settings.

I hope this helps! If you have any more questions, feel free to ask.

Best regards,
Toradex AI Assistant.

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

Verdin iMX8M Plus GPIO pull up configuration.

bruno.tx · January 9, 2025, 11:15am

Hello @vix,

Regarding SODIMM_32 (GPIO3_IO22):

Deleting the pinctrl_sai1 node should be possible if you are not using SAI1. Please note that this is the default I2S interface used for the Verdin iMX8MP.
It is also important to make sure that this node is not assigned to any other nodes in your device tree.
- For example, on the Verdin Development Board, it is assigned to the nau8822_1a node: imx8mp-verdin-dev.dtsi « freescale « dts « boot « arm64 « arch - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

Regarding SODIMM_64 (GPIO3_IO16):

This pin is used in pinctrl_flexspi0 which is then used in flexspi (Verdin QSPI_1)
Therefore, to use this pin on the Cortex-M4, you can either remove the above nodes or disable the flexspi node.

The objective here is to take the ownership of these pins away from Linux, so it will not do any pinmuxing and will not use the pins.

Best Regards,
Bruno

vix · January 9, 2025, 11:25am

Hi @bruno.tx

in theory, everything is clear and I agree 100% to what you wrote.
I did the same for other pins, successfully.
These ones are somehow “special” (i.e., I cannot get the result).

Is it possible that u-boot changed in some waht their config?

Is there any linux command that I can use to read the IOMUX registers?
I think to “IOMUXC Memory Map/Register Definition” registers (paragraph 8.2.4 of i.MX 8M Plus Applications Processor Reference Manual)

/* EDIT */
I read the pin configuration from Cortex-M and I confirm that GPIO3_IO16 is configured as ALT2_USDHC3_RESET_B.
But the question is: where this config come from?

/* EDIT #2 */
GPIO3_IO22 issue comes from a pull-down resistor on my carrier board.
Forget about it.
The only issue is for GPIO3_IO16.

bruno.tx · January 9, 2025, 1:53pm

Hello @vix,

Reading the values of the registers from Linux userspace is not straight forward because /dev/mem is not enabled by default on Torizon OS.

It is possible that u-boot changed the configuration of GPIO3_IO16.
To understand where the configuration is coming from, I would recommend that you do the following:

Stop the boot process in u-boot
Read the register value with the md command
Run your Cortex-M application, and check what is the configuration of the pin after the program has done its pinmuxing
Boot the system
Check the configuration of the pin from the Cortex-M

This will help you understand where this change is taking place.
A program for the Cortex-M that initializes the needed pins and continuously prints the status of the respective pinmuxing register could be used here.

Best Regards,
Bruno

vix · January 10, 2025, 9:33am

Hi @bruno.tx

I confirm that stopping in u-boot and reading the iomux configuration returns that pin GPIO3_IO16 is configured as ALT2_USDHC3_RESET_B.
This explains why I didn’t find any dts in torizon that configures the pin in this way.

The question is: why u-boot for Verdin iMX8M-Plus configures this pin as the RESET_B for USDHC3?
Is this by design?
Does this come from a different dts used by uboot?

bruno.tx · January 10, 2025, 10:09am

Hello @vix,

Thanks for checking it.
It appears that u-boot mistakenly configures this pad: imx8mp-verdin.dts « dts « arm « arch - u-boot-toradex.git - U-Boot bootloader for Apalis and Colibri modules

I have checked the Module’s schematics to be sure that this signal was not used for the eMMC, and I can confirm that it is not and therefore can be used by the Cortex-M4 without issues.

If you manually configure this pad to use ALT5 (GPIO3_IO16) within your Cortex-M program, does the configuration gets reversed during the normal boot flow?

Best Regards,
Bruno

vix · January 10, 2025, 10:23am

Yes, if I configure it at the very beginning of my Cortex-M program (that is started by u-boot).
If I configure it at a later stage (when I’m sure that Torizon OS has booted), the configuration is not overwritten anymore.

Based on the file you linked, I agree that u-boot has a wrong configuration for the pin RESET_B of USDHC3, since it doesn’t match the configuration used in Torizon OS imx8mp-verdin.dts « dts « arm « arch - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

I suspect that eMMC (connected to USDHC3 interface) needs the RESET_B signal, and so it’s not good that in the u-boot stage this signal is routed to a wrong pin (i.e., pin not connected to eMMC).
Do you think that Toradex should/would update its u-boot with this fix?

bruno.tx · January 10, 2025, 12:07pm

Hello @vix,

Noted, for now the recommended approach would be to configure the pin at a later stage as a workaround.
Would that be a viable alternative for you?

The current configuration has not caused issues, therefore the default configuration of the pin that is actually used for RESET_B is consistent and sufficient for the boot process.
The u-boot version we use for Torizon OS 7 does not have this problem: dts/upstream/src/arm64/freescale/imx8mp-verdin.dtsi · master · U-Boot / U-Boot · GitLab

With this in mind, I would say that this will likely not be changed for Torizon OS 6.
Regardless, I will check internally and send an update here.

Best Regards,
Bruno

vix · January 10, 2025, 1:40pm

I think it’s the only way at the moment.

Good to know.

At the moment Torizon OS 7 is not working with M7 (rpmsg doesn’t work anymore), so it’s not an option.
I know that it’s not ideal for Toradex, but today Torizon OS 6 is the only working OS in case M7 is used, and so it should be handled as an active branch (like before the relase of Torizon OS 7).
Or, the fix in Torizon OS 7 should be made available really soon.

Let me know

bruno.tx · January 13, 2025, 1:20pm

Hello @vix,

I was informed that the problem related to RPMSG on Torizon OS 7 has been solved recently.

If you want to use Torizon OS 7, this should already be working on the latest nightly.
Please note that there were some related changes to the HMP device tree overlay, so you may need to change your custom overlay. Relevant commit: device-tree-overlays.git - Sources for Device Tree Overlays

I will still send an update regarding pinctrl_usdhc3 on the u-boot device tree for BSP 6, the team is currently looking into it.

Best Regards,
Bruno

vix · January 13, 2025, 2:21pm

Hi @bruno.tx

I see that the commit refers to the branch toradex_6.6-2.1.x-imx.
Does this mean that the answer to my question here is “yes, branch toradex_6.6-2.1.x-imx should be used now to build Torizon OS 7”?

bruno.tx · January 13, 2025, 2:28pm

Hello @vix,

Yes, for Torizon OS 7.1.0 and nightly images the toradex_6.6-2.1.x-imx branch should be used when building Torizon OS 7.

Best Regards,
Bruno

bruno.tx · January 15, 2025, 5:34pm

Hello @vix,

Following up on the topic of the incorrect pinctrl_usdhc3, could you clarify the following topics:

Do you plan to release your project initally with Torizon OS 6 or Torizon OS 7?
If you plan to release it with Torizon OS 6, when would you need this changed in the u-boot device tree?

The main purpose of those questions is to evaluate the impact of this problem and be able to properly prioritize a fix if needed.

Best Regards,
Bruno

vix · January 16, 2025, 1:13pm

The release is scheduled on April.
If Torizon OS 7 + HMP + Chromium will be stable enough, I’ll go with Torizon OS 7.
Otherwise I will stay on Torizon Os 6 (tested until now).

bruno.tx · January 16, 2025, 1:39pm

Hello @vix,

Thanks for the information, I will relay it internally.

Best Regards,
Bruno