S32G3 toggle gpio failed in u-boot

[GG0712]

Hi NXP team,

We refer to the custom board of s32g399ardb3 and using BSP35.

I added pinctrl configuration in atf device tree and try to toggles gpios in u-boot

I can toggle PC_05 (37) and PB_12 (28) but PK_13 (173) and PK_11 (171) failed.

arm-trusted-firmware device tree:

fdts/s32gxxxa-rdb.dtsi

&gpio {
	pinctrl-names = "default";
	pinctrl-0 = <&custom1_pins, &custom2_pins>;
};

&pinctrl {
	u-boot,dm-pre-reloc;

	custom1_pins: custom1_pins {
		custom1_grp0 {
			pinmux = <S32CC_PINMUX(174, FUNC0)>;
			input-enable;
		};

		custom1_grp1 {
			pinmux = <S32CC_PINMUX(37,  FUNC0)>,
				 <S32CC_PINMUX(171, FUNC0)>;
			output-enable;
		};
	};

	custom2_pins: custom2_pins {
		custom2_grp0 {
			pinmux = <S32CC_PINMUX(183, FUNC0)>;
			input-enable;
		};

		custom2_grp1 {
			pinmux = <S32CC_PINMUX(28,  FUNC0)>,
				 <S32CC_PINMUX(173, FUNC0)>;
			output-enable;
		};
	};

Here is gpio control failed log

=> gpio toggle siul2-gpio@4009d700037
gpio: pin siul2-gpio@4009d700037 (gpio 37) value is 1
=> gpio clear siul2-gpio@4009d700037
gpio: pin siul2-gpio@4009d700037 (gpio 37) value is 0

=> gpio clear siul2-gpio@4009d700028
gpio: pin siul2-gpio@4009d700028 (gpio 28) value is 0
=> gpio toggle siul2-gpio@4009d700028
gpio: pin siul2-gpio@4009d700028 (gpio 28) value is 1

=> gpio toggle siul2-gpio@4009d700171
gpio: pin siul2-gpio@4009d700171 (gpio 171) value is 1
   Warning: value of pin is still 0
=> gpio toggle siul2-gpio@4009d700173
gpio: pin siul2-gpio@4009d700173 (gpio 173) value is 1
   Warning: value of pin is still 0

Thanks

[Joey_z]

hi，GG0712

The pinctrl subsystem is used in the default configuration of BSP. I can operate PK_13 (173) and PK_11 (171) normally with the new version of BSP42. I think it should be that the BSP35 version is older. After comparison, it is found that the description of siul2 in the device tree file s32g.dtsi of ATF has been modified. The picture below shows the result of my operation in the BSP42.

Hope it can help you.

BR

Joey

[GG0712]

Hi Joey_z,

I got failed after update device tree.

I upload my s32g.dtsi siul2 part to BSP43 version as attached.

Also I modify our device tree as below:

fdts/s32gxxxa-rdb.dtsi

&gpio {
	pinctrl-names = "default";
	pinctrl-0 = <&custom1_pins, &custom2_pins>;
};

&pinctrl {
	u-boot,dm-pre-reloc;

	custom1_pins: custom1_pins {
		custom1_grp0 {
			pinmux = <S32CC_PINMUX(174, FUNC0)>;
			input-enable;
		};

		custom1_grp1 {
			pinmux = <S32CC_PINMUX(37,  FUNC0)>;
			output-enable;
		};

		custom1_grp2 {
			pinmux = <S32CC_PINMUX(171, FUNC0)>;
			bias-pull-down;
			output-enable;
		};
	};

	custom2_pins: custom2_pins {
		custom2_grp0 {
			pinmux = <S32CC_PINMUX(183, FUNC0)>;
			input-enable;
		};

		custom2_grp1 {
			pinmux = <S32CC_PINMUX(28,  FUNC0)>;
			output-enable;
		};
		custom2_grp2 {
			pinmux = <S32CC_PINMUX(173, FUNC0)>;
			bias-pull-down;
			output-enable;
		};
	};

In our hardware design, both PK_13 (173) and PK_11 (171) GPIOs from the SoC are connected to the EN pin of the MPQ5068GQV-AEC1-Z. A 10 Kohm pull-down resistor is also connected to the EN pin

SoC GPIO: PK_13 (173) ─┬──> EN pin of MPQ5068GQV-AEC1-Z
                       |
                       R (10kΩ pull-down)
                       |
                      GND

SoC GPIO: PK_11 (171) ─┬──> EN pin of MPQ5068GQV-AEC1-Z
                       |
                       R (10kΩ pull-down)
                       |
                      GND

Below is my test log

// Port  Module            SSS       Addr       Function
// PK_13 SIUL_OFFCC        0000_0000 0x440104F4 GPIO[173]

=> md.l 0x440104F4 1
440104f4: 00010000

=> gpio toggle siul2-gpio@4009d700173
gpio: pin siul2-gpio@4009d700173 (gpio 173) value is 1
Warning: value of pin is still 0

=> md.l 0x440104F4 1
440104f4: 00202000



// Port  Module  SSS       Addr       Function
// PB_12 SIUL_CC 0000_0000 0x440104F4 GPIO[28]

=> md.l 0x4009C2B0 1
4009c2b0: 00200000

=> gpio toggle siul2-gpio@4009d700028
gpio: pin siul2-gpio@4009d700028 (gpio 28) value is 1

=> md.l 0x4009C2B0 1
4009c2b0: 00280000

Thanks

[Joey_z]

hi,GG0712

Can you use gpio 171/173 normally without modifying the device tree and using BSP by default? If it can be toggle normally, I don't think it's a hardware issue.

BR

Joey

[GG0712]

Hi Joey_z,

I toggle 171/173 failed when I try to using siul2 and pins config by default and using siul2 by BSP43 but pins config by default

In S32G3_IOMUX 2 file, the gpio 28 module is SIUL_CC and the gpio 171/173  module is SIUL_OFFCC , are thereany differences between these modules?

$ gpio status -a
...
siul2-gpio@4009d70028: unknown
...
siul2-gpio@4009d700171: unknown
siul2-gpio@4009d700172: unknown
siul2-gpio@4009d700173: unknown
...

=> gpio set siul2-gpio@4009d700173
gpio: pin siul2-gpio@4009d700173 (gpio 173) value is 1
Warning: value of pin is still 0
=> gpio toggle siul2-gpio@4009d700173
gpio: pin siul2-gpio@4009d700173 (gpio 173) value is 1
Warning: value of pin is still 0

=> gpio set siul2-gpio@4009d700171
gpio: pin siul2-gpio@4009d700171 (gpio 171) value is 1
Warning: value of pin is still 0
=> gpio toggle siul2-gpio@4009d700171
gpio: pin siul2-gpio@4009d700171 (gpio 171) value is 1
Warning: value of pin is still 0

=> gpio toggle siul2-gpio@4009d70028
gpio: pin siul2-gpio@4009d70028 (gpio 28) value is 1
=> gpio clear siul2-gpio@4009d70028
gpio: pin siul2-gpio@4009d70028 (gpio 28) value is 0

Thanks

[Joey_z]

hi，GG0712

Thank you for your reply.

It is normally to use the gpio 171/173 for BSP43 on our development board, you can try to cancel the 10k pulldown resistance. The status of unknown should be not to set the gpio.

You can check the status, if you have been set the gpio as shown the following picture.

in addition, Refers to SIUL2_0 and SIUL2_1 as SIUL2_CC and SIUL2_OFFCC in S32G3_IOMUX.

Hope it can help you.

BR

Joey

[GG0712]

Hi Joey_z,

Thanks for your reply,  I will try to remove 10K pull down resistor.

But in my case, I can control gpio 171/173 through Linux kernel module.

Is it should be possible to rule out hardware issues ?

linux-s32_5.10/arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi
custom_gpio: custom_gpio {
    compatible = "custom,gpio-handler";
    toggle171-gpios  = <&gpio 171 GPIO_ACTIVE_HIGH>;	// PK_11		
    toggle173-gpios  = <&gpio 173 GPIO_ACTIVE_HIGH>;	// PK_13
}; 

I can use kernel api "gpiod_set_value" to toggle 171/173

 Thanks

[GG0712]

Hi Joey_z,

I try to toggle our gpio but seem like all of SIUL2_1 toggle failed

=> gpio toggle siul2-gpio@4009d700030
gpio: pin siul2-gpio@4009d700030 (gpio 30) value is 1
=> gpio toggle siul2-gpio@4009d700024
gpio: pin siul2-gpio@4009d700024 (gpio 24) value is 1

=> gpio toggle siul2-gpio@4009d700112
gpio: pin siul2-gpio@4009d700112 (gpio 112) value is 1
Warning: value of pin is still 0
=> gpio toggle siul2-gpio@4009d700185
gpio: pin siul2-gpio@4009d700185 (gpio 185) value is 1
Warning: value of pin is still 0
=> gpio toggle siul2-gpio@4009d700184
gpio: pin siul2-gpio@4009d700184 (gpio 184) value is 1
Warning: value of pin is still 0
=> gpio toggle siul2-gpio@4009d700186
gpio: pin siul2-gpio@4009d700186 (gpio 186) value is 1
Warning: value of pin is still 0
=> gpio toggle siul2-gpio@4009d700177
gpio: pin siul2-gpio@4009d700177 (gpio 177) value is 1
Warning: value of pin is still 0
=> gpio toggle siul2-gpio@4009d700178
gpio: pin siul2-gpio@4009d700178 (gpio 178) value is 1
Warning: value of pin is still 0

Thanks

[Joey_z]

hi，GG0712

Thank you for your reply and information.

You mentioned that after modifying the kernel source code, gpio can be controlled. You can try to measure the gpio voltage with a multimeter to see if true control has been achieved.

In addition, about all of SIUL2_1 toggle failed, is it a phenomenon that only occurs after modifying the Kernel?

BR

Joey

[GG0712]

Hi Joey_z,

The gpio voltage has changed, but this is an old solution. We currently want to move the gpio control to the u-boot stage

We just modify Linux kernel device tree and add a custom kernel module to control gpio.

Toggle SIUL2_1 related gpio faild after I use default Linux device tree.

Thanks

[Joey_z]

hi，GG0712

I understand what you mean, but I need to confirm some information.
Are you using BSP43? Can't you operate gpio 171/173 either by using the default fsl-image-auto-s32g399ardb3.sdcard file as shown in the figure? It's fine for me to use it, as I demonstrated to you before.

BR

Joey

[GG0712]

Hi Joey_z,

Currently we using BSP35.

I can toggle gpio 171/173 with BSP43 without any modify.

Do you have change list from BSP35 to BSP43?

We can compare and move commit to BSP35 

=> gpio toggle siul2-gpio@4009d700173
gpio: pin siul2-gpio@4009d700173 (gpio 173) value is 1

=> gpio toggle siul2-gpio@4009d700171
gpio: pin siul2-gpio@4009d700171 (gpio 171) value is 1

Thanks

[Joey_z]

hi，GG0712

Thank your for your reply.

I checked the AFT and u-boot information.

Some file is about the pinctrl and gpio system in BSP35, it has been changed in the BSP43. These files includes  pinctrl-s32cc.c and gpio-s32cc.c in uboot. The file of s32g.dtsi has the description for gpio device in ATF.

These files have all changed due to version updates. By referring to these files, some information can be found.

BR

Joey

[GG0712]

Hi Joey_z,

We still toggle gpio failed after I update pinctrl-s32cc.c and gpio-s32cc.c in u-boot and s32g.dtsi in ATF.

But I can toggle gpio in BSP37 and will try to use BSP36. I will update result after test.

BTW, we don't have any idea about BSP37 and BSP36 release note about this issue.

After test, I will try to compare u-boot driver and device tree in ATF.

Thanks

[GG0712 · Accepted solution]

Hi Joey_z,

We found the solution in BSP36.

The commit f54ed6f81ceff324cd5f354da440b78507e2bed0 show that why we can not toggle SIUL2_1 related GPIO.

I can toggle 171/173 GPIO after I merge this commit and without any modify in ATF and u-boot.

Thanks for your help.

Thanks

[Joey_z]

hi,GG0712

Thank you for your reply and share your experience.

BR

Joey

[Joey_z]

hi,GG0712

Thank you for your reply.

You can refer to the BSP Releasenotes to find some change information.

The BSP43 and BSP35 have a big different of version, the u-boot and device tree will have been changed, I will help you to check the change content and reply to you as soon as I get the results.

BR

Joey

[Joey_z]

hi,GG0712

Thank you for contacting us.

I will help you test this problem and reply to you as soon as there is a result.

BR

Joey