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

[compmas2]

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

or

=> 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.

[lmhdoms]

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.

[weidong_sun]

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

[compmas2]

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

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 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.

[compmas2]

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?