Configure GPIO's through custom Device Tree

This topic has 3 replies, 2 voices, and was last updated 6 years, 2 months ago by Eshtaartha Basu.

Viewing 3 reply threads

Author
Posts

August 12, 2018 at 3:08 pm #6206

Dusty

Participant

Hello,

I followed the Linux Device Tree Application Note to add some GPIO’s (all in GPIO3 module):

&amp;am33xx_pinmux {

    gpio3_pins_default: gpio3_pins_default {    /* GPIO PINS */
	    pinctrl-single,pins = &lt;
            AM33XX_IOPAD(0xa34, PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (F15) USB1_DRVVBUS.gpio3[13] */    /* KSZ8081 RESET */
            AM33XX_IOPAD(0x990, PIN_INPUT_PULLDOWN | MUX_MODE7 ) /* (A13) mcasp0_aclkx.gpio3[14] */     /* PHY_A RXER */
            AM33XX_IOPAD(0x994, PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (B13) mcasp0_fsx.gpio3[15] */      /* LED1 */
            AM33XX_IOPAD(0x998, PIN_INPUT_PULLUP | MUX_MODE7 ) /* (D12) mcasp0_axr0.gpio3[16] */        /* KEY1 */
            AM33XX_IOPAD(0x99c, PIN_INPUT_PULLDOWN | MUX_MODE7 ) /* (C12) mcasp0_ahclkr.gpio3[17] */    /* PHY_B RXER */
            AM33XX_IOPAD(0x9a0, PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (B12) mcasp0_aclkr.gpio3[18] */    /* LED2 */
	    &gt;;
    };
...

&am33xx_pinmux {

gpio3_pins_default: gpio3_pins_default { /* GPIO PINS */

pinctrl-single,pins = <

AM33XX_IOPAD(0xa34, PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (F15) USB1_DRVVBUS.gpio3[13] */ /* KSZ8081 RESET */

AM33XX_IOPAD(0x990, PIN_INPUT_PULLDOWN | MUX_MODE7 ) /* (A13) mcasp0_aclkx.gpio3[14] */ /* PHY_A RXER */

AM33XX_IOPAD(0x994, PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (B13) mcasp0_fsx.gpio3[15] */ /* LED1 */

AM33XX_IOPAD(0x998, PIN_INPUT_PULLUP | MUX_MODE7 ) /* (D12) mcasp0_axr0.gpio3[16] */ /* KEY1 */

AM33XX_IOPAD(0x99c, PIN_INPUT_PULLDOWN | MUX_MODE7 ) /* (C12) mcasp0_ahclkr.gpio3[17] */ /* PHY_B RXER */

AM33XX_IOPAD(0x9a0, PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (B12) mcasp0_aclkr.gpio3[18] */ /* LED2 */

};

...

and

&amp;gpio3 {
    pinctrl-names = "default";
    pinctrl-0 = &lt;&amp;gpio3_pins_default&gt;;
    status = "okay";
};

&gpio3 {

pinctrl-names = "default";

pinctrl-0 = <&gpio3_pins_default>;

status = "okay";

};

(full dts file attached).

I also disabled the other overlays and cape manager in uEnv.txt (to avoid my dts configuration to be overwritten):

...
enable_uboot_overlays=0
...
enable_uboot_cape_universal=0
...

...

enable_uboot_overlays=0

...

enable_uboot_cape_universal=0

...

(full uEnv.txt attached).

The problem is that my GPIO configuration still doesn’t seem to take effect:

debian@beaglebone:/sys/class/gpio$ ls
export  gpiochip0  gpiochip32  gpiochip64  unexport

1 2	debian@beaglebone:/sys/class/gpio$ ls export gpiochip0 gpiochip32 gpiochip64 unexport

debian@beaglebone:/sys/kernel/debug/pinctrl/44e10800.pinmux$ cat pins
registered pins: 142
...
pin 100 (PIN100) 44e10990 00000027 pinctrl-single
pin 101 (PIN101) 44e10994 00000027 pinctrl-single
pin 102 (PIN102) 44e10998 00000027 pinctrl-single
pin 103 (PIN103) 44e1099c 00000027 pinctrl-single
pin 104 (PIN104) 44e109a0 00000027 pinctrl-single
...
pin 141 (PIN141) 44e10a34 00000020 pinctrl-single
debian@beaglebone:/sys/kernel/debug/pinctrl/44e10800.pinmux$

debian@beaglebone:/sys/kernel/debug/pinctrl/44e10800.pinmux$ cat pins

registered pins: 142

...

pin 100 (PIN100) 44e10990 00000027 pinctrl-single

pin 101 (PIN101) 44e10994 00000027 pinctrl-single

pin 102 (PIN102) 44e10998 00000027 pinctrl-single

pin 103 (PIN103) 44e1099c 00000027 pinctrl-single

pin 104 (PIN104) 44e109a0 00000027 pinctrl-single

...

pin 141 (PIN141) 44e10a34 00000020 pinctrl-single

debian@beaglebone:/sys/kernel/debug/pinctrl/44e10800.pinmux$

I can export most gpio’s manually, and control them, but they all default to inputs (27h), although configured differently in the Device Tree.

Is my Device Tree wrong?

Are my Device Tree setting overwritten through an overlay (although disabled)?

The boot log indicates that the overlays are not loaded, but I still see this in the boot log (bone_capemgr.uboot_capemgr_enabled=1):

debug [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=devmmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet] ...

1	debug [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=devmmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet] ...

Why would the u-boot command enable it although disabled through uEnv.txt?

Part 2 of the question:

GPIO3[15] is a little bit different: USB1_DRVVBUS.gpio3[13]

This is the USB1 bus power pin and it seems to resist to be put in GPIO mode 7 because it’s already claimed by USB1.

However, I don’t have an USB1 interface physically on my custom board, and didn’t include it in my Device Tree. Any ideas how I can ‘free’ this pin to be used as GPIO3[15]?

Thank you,
Dusty

This topic was modified 6 years, 2 months ago by Dusty.
This topic was modified 6 years, 2 months ago by Dusty.

Attachments:

octavo-2018-8-12.zip

August 14, 2018 at 3:00 pm #6223
Eshtaartha Basu
Moderator
Hello Dusty,
I will look into this issue and get back to you by the beginning of next week.
August 17, 2018 at 10:20 am #6254
Eshtaartha Basu
Moderator
Hello Dusty,
Sorry. This is taking longer than expected. I will get back to you on this issue by the beginning of the week of Aug 21st.
August 27, 2018 at 10:33 am #6305
Eshtaartha Basu
Moderator
Hello Dusty,
Sorry for the delay in response.
Your device tree is not correct. gpio3_default node is not binding to any parent node.
/
&ocp {
compatible = “bone-pinmux-helper”;
pinctrl-names = “default”;
pinctrl-0 = <&gpio3_pins_default>;
status = “okay”;
}; /
should be:
&ocp {
gpio3_default {
compatible = “bone-pinmux-helper”;
pinctrl-names = “default”;
pinctrl-0 = <&gpio3_pins_default>;
status = “okay”;
};
};
You need to uncomment &ocp node and add gpio3_default under it. This is similar to the BB Blue dts:
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-boneblue.dts#L706
For the USB1_DRVVBUS issue, you might need to modify the device tree to set usb1 to peripheral mode where the driver will not take control of the DRVVBUS signal.
A similar issue has been resolved on TI forum:
https://e2e.ti.com/support/arm/sitara_arm/f/791/t/270060?USB1-power-control-with-DRVVBUS?

Author
Posts

Viewing 3 reply threads

You must be logged in to reply to this topic.