topic Re: GPIO silently fails in u-boot rel_imx_5.4.24_2.1.0 in i.MX Processors

GPIO silently fails in u-boot rel_imx_5.4.24_2.1.0

compmas2 — Mon, 02 Nov 2020 16:02:05 GMT

I am having the an issue with the Linux BSP u-boot release version rel_imx_5.4.24_2.1.0. I am using an i.MX6UL processor which was running fine on an older version of u-boot (2015.04 release rel_imx_4.1.15_1.1.1_patch) and now that I am updating it the GPIOs silently fail. I am initializing and setting/clearing GPIO the same way as all the i.MX evaluation boards do based on their board files under /board/freescale/.

Here is where I am setting up GPIO pins:

static iomux_v3_cfg_t const led_gpio_pads[] = { MX6_PAD_ENET2_TX_DATA0__GPIO2_IO11 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), MX6_PAD_ENET2_RX_ER__GPIO2_IO15 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), MX6_PAD_LCD_DATA03__GPIO3_IO08 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), MX6_PAD_LCD_DATA04__GPIO3_IO09 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), MX6_PAD_LCD_DATA05__GPIO3_IO10 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), MX6_PAD_LCD_DATA06__GPIO3_IO11 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), MX6_PAD_LCD_DATA07__GPIO3_IO12 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), MX6_PAD_LCD_DATA08__GPIO3_IO13 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), MX6_PAD_LCD_DATA09__GPIO3_IO14 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), MX6_PAD_LCD_DATA10__GPIO3_IO15 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), MX6_PAD_LCD_DATA11__GPIO3_IO16 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), MX6_PAD_LCD_DATA12__GPIO3_IO17 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), };

Then the following code is run and fails silently:

imx_iomux_v3_setup_multiple_pads(led_gpio_pads, ARRAY_SIZE(led_gpio_pads)); puts("Starting LEDs\n"); gpio_request(IMX_GPIO_NR(3,8), "led1 blue"); gpio_direction_output(IMX_GPIO_NR(3,8), 1); gpio_request(IMX_GPIO_NR(2,11), "led1 red"); gpio_direction_output(IMX_GPIO_NR(2,11), 1); gpio_request(IMX_GPIO_NR(3,9), "led2 red"); gpio_direction_output(IMX_GPIO_NR(3,9), 0); gpio_request(IMX_GPIO_NR(3,12), "led3 red"); gpio_direction_output(IMX_GPIO_NR(3,12), 0); gpio_request(IMX_GPIO_NR(3,15), "led4 red"); gpio_direction_output(IMX_GPIO_NR(3,15), 0); puts("Started LEDs\n");

I confirmed the above code is running since I can see the message "Started LEDs" printed out to the debug UART at boot.

Additionally the gpio command line tool from the hush shell is not functioning. Using the following I get a blank response:

=> gpio status -a

=> gpio status 72

Using the set command on any GPIO number will get the following result:

=> gpio set 72 GPIO: '72' not found Command 'gpio' failed: Error -22

It appears like the initialization of the GPIO is not working and no pins are registered as GPIOs. All other functionality works fine with non-GPIO settings like UART, MMC, I2C, etc. Any help on this would be appreciated.

Re: GPIO silently fails in u-boot rel_imx_5.4.24_2.1.0

compmas2 — Mon, 02 Nov 2020 18:05:58 GMT

So I have a .dts for my board and I enabled the MXC_GPIO and GPIO_HOG in the u-boot config. This allowed me to get the gpio scripting command to work with showing status and setting and clearing values. The issue is the C code in the board file still does not work. Instead it reports the following errors:

gpio@20a4000: dir_output: error: gpio GPIO3_5 not reserved gpio@20a4000: dir_output: error: gpio GPIO3_4 not reserved gpio@20a4000: set_value: error: gpio GPIO3_4 not reserved gpio@20a4000: dir_output: error: gpio GPIO3_24 not reserved gpio@20a4000: dir_output: error: gpio GPIO3_6 not reserved gpio@20a4000: dir_output: error: gpio GPIO3_7 not reserved gpio@20a4000: set_value: error: gpio GPIO3_7 not reserved gpio@20a4000: dir_output: error: gpio GPIO3_22 not reserved gpio@20a4000: dir_output: error: gpio GPIO3_21 not reserved gpio@20a4000: set_value: error: gpio GPIO3_22 not reserved

I really need to be able to setup the GPIOs in C code to reset chips and prevent manipulation of the setting of certain GPIOs by users of the product.

Unfortunately with this version of u-boot, there is a transition from direct driver calls to using driver models and device trees. It seems the i.MX processor support from NXP is in flux and there is no guidance from NXP as to which drivers to use in the porting guide they publish. Is there any place that details which drivers to use and how to use the functionality associated with them in the more recent versions of u-boot from NXP?

Re: GPIO silently fails in u-boot rel_imx_5.4.24_2.1.0

weidong_sun — Tue, 03 Nov 2020 06:19:39 GMT

Hi,

In 5.4.24_2.1.0 BSP, u-boot also uses device tree, so you should configure them in dts file.

path is u-boot/arch/arm/dts

Have a nice day!

B.R,

Weidong

Re: GPIO silently fails in u-boot rel_imx_5.4.24_2.1.0

compmas2 — Wed, 04 Nov 2020 17:02:48 GMT

I defined the GPIOs in the device tree under the hog entry and I am getting the same failure messages:

I commented out the following code in the board file since the device tree is handling the IOMUX of the GPIO pins:

//static iomux_v3_cfg_t const led_gpio_pads[] = { // MX6_PAD_ENET2_TX_DATA0__GPIO2_IO11 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), // MX6_PAD_ENET2_RX_ER__GPIO2_IO15 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), // MX6_PAD_LCD_DATA03__GPIO3_IO08 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), // MX6_PAD_LCD_DATA04__GPIO3_IO09 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), // MX6_PAD_LCD_DATA05__GPIO3_IO10 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), // MX6_PAD_LCD_DATA06__GPIO3_IO11 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), // MX6_PAD_LCD_DATA07__GPIO3_IO12 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), // MX6_PAD_LCD_DATA08__GPIO3_IO13 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), // MX6_PAD_LCD_DATA09__GPIO3_IO14 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), // MX6_PAD_LCD_DATA10__GPIO3_IO15 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), // MX6_PAD_LCD_DATA11__GPIO3_IO16 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), // MX6_PAD_LCD_DATA12__GPIO3_IO17 | MUX_PAD_CTRL(GPIO_PULL_DOWN_PAD_CTRL), //}; //imx_iomux_v3_setup_multiple_pads(led_gpio_pads, ARRAY_SIZE(led_gpio_pads));

Here is my hog entries in the .dts file for my board that cover the GPIOs:

&iomuxc { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_hog_1>; board { pinctrl_hog_1: hoggrp-1 { fsl,pins = < MX6UL_PAD_ENET2_TX_DATA0__GPIO2_IO11 0x030b0 MX6UL_PAD_ENET2_RX_ER__GPIO2_IO15 0x030b0 MX6UL_PAD_LCD_DATA03__GPIO3_IO08 0x030b0 MX6UL_PAD_LCD_DATA04__GPIO3_IO09 0x030b0 MX6UL_PAD_LCD_DATA05__GPIO3_IO10 0x030b0 MX6UL_PAD_LCD_DATA06__GPIO3_IO11 0x030b0 MX6UL_PAD_LCD_DATA07__GPIO3_IO12 0x030b0 MX6UL_PAD_LCD_DATA08__GPIO3_IO13 0x030b0 MX6UL_PAD_LCD_DATA09__GPIO3_IO14 0x030b0 MX6UL_PAD_LCD_DATA10__GPIO3_IO15 0x030b0 MX6UL_PAD_LCD_DATA11__GPIO3_IO16 0x030b0 MX6UL_PAD_LCD_DATA12__GPIO3_IO17 0x030b0 >; }; }; };

Are the gpio_request() and gpio_direction_output() functions still supposed to work with the device tree method of initializing the GPIOs? It looks like that is how all the i.MX6UL eval board files did it.

Re: GPIO silently fails in u-boot rel_imx_5.4.24_2.1.0

lmhdoms — Fri, 19 Nov 2021 08:24:04 GMT

It looks correct, those not reserved complaints are regarding other gpio pins, which most likely are used without first being opened with the gpio_request call.