Configuring the Initial state of GPIOs with device tree

Hello Everyone,

Can some please help me to identify the best way to set the initial states of the GPIOs using the devicetree?

I understand that I can use the gpio-hog to define the direction and the states of the GPIOs but I am not sure about what config value I should use depending upon the Initial state of the GPIO

I currently set the config value to 0x184 if I use them as gpios and 0x1c4 if I use them as interrupt. Is this correct? example

MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19		0x184

What is the best practice while setting the config values? Does this affect the initial state of the GPIO?
I would use some of the GPIOs to control the power for the peripherals and thus require them to be in a defined state at boot and hence this requirement.

Any advice or suggestions would be very helpful.

Regards,
Gaurav

Hi @gauravks,

So I do have a couple of questions here. How early in the boot process do you need to control the initial state of these pins? I ask because if you need these pins in a state during the boot process as early as U-Boot then you’ll need to make U-Boot changes as well as kernel device tree changes.

Probably the earliest you can influence pin settings/values is in U-Boot using the board’s specific definition file: verdin-imx8mm.c « verdin-imx8mm « toradex « board - u-boot-toradex.git - U-Boot bootloader for Apalis and Colibri modules

This would set your pin as early as U-Boot until the kernel takes over at which point the pinmuxing in the device tree is used.

As for kernel/device-tree settings it sounds like you’ll either need to set the pins as input/output with either a pull-up/pull-down depending on your needs. You’re correct that the way to set this would be to alter the config values in the device tree pinmuxing. The exact values however are not consistent across all the i.MX SoCs. For example a 0x184 means something different here then it does on the i.MX8 or i.MX6. The only way to really know the values and their meaning, would be to reference NXP’s reference manual on that specific SoC.

I believe the reference manual for the i.MX8M Mini should be openly available on the NXP site.

Best Regards,
Jeremias

Hi @jeremias.tx,

Thanks for your response.
Yeah after some more investigation I do feel the U-Boot is the best way to set the values and I believe that it would not still allow the userspace applications to access the GPIOs unlike the gpio-hog which reserves the pin for the kernel space. Please correct me if I am wrong?

As for the config values, do you think configuring the pull-up/pull-down is enough to specify the directions? This still would have to be set in the Linux somewhere I think right?

I thought the pull-up/pull-down resistors were meant to control the behavior of the GPIO signal not the directions. Can you confirm this?

Regards,
Gaurav

Well the U-Boot configuration of pins is only valid as long as U-Boot is running the second the kernel takes over then the device tree configuration is what is used.

So you’d most likely need a change in both U-Boot and the Kernel. So for the pull-up/down this is only to specify state of the pin. I believe in general at reset if no direction is specified the reset state for GPIO pins is input. If you want an output then you’d need to configure this in the device tree most likely via the values specific to the i.MX8M Mini SoC. Then you can use the pull-up/down configuration if you want a specific state at boot for an output.

Best Regards,
Jeremias