Debian Overlay / Pinmux not working?

[Riley Porter]

Hey guys,

I have been fighting this for a few days now.  But it seems to me that no matter what I do I cannot get the pinmux'ing to work when applying overlays in debian.  I have tried 7.8 and 8.2 and either is really different.

I was looking around to see if I was the only one in this boat and it turns out I found a post on stack exchange that describes my issue perfectly.

Unfortunately the "answer" was to install angstrom.  I was hoping someone on the list would have some secret answer as to why applying an overlay was not changing the pinmux's?

I would very much like to stick with debian but if the answer is go back angstrom I guess I can live with that.

Thanks

[John Syne]

That is strange because it seems to be working for everyone else. What is your kernel version?

If you are using kernel version 4.1 or higher, then do the following on your BBB

git clone https://github.com/RobertCNelson/bb.org-overlays.git

Follow the instructions readme.md file. My guess is you don’t have the correct Device Tree Compiler, but this repo will install the correct version. 

Regards,

John

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Riley Porter]

Yes I am running:

Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l GNU/Linux

I followed your instructions but still am at a loss.  I was able to update the device tree compiler and the kernel which is now:

Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC 2015 armv7l GNU/Linux

 Perhaps describing my exact steps might shed some light on my screw up?

This is the device tree I am testing with:

/* 
snip for space
*/
/dts-v1/;
/plugin/;

/{
       compatible = "ti,beaglebone", "ti,beaglebone-black";
       part-number = "EBB-GPIO-Example";
       version = "00A0";

       fragment@0 {
             target = <&am33xx_pinmux>;
           

             __overlay__ {
                  ebb_example: EBB_GPIO_Example {
                        pinctrl-single,pins = <


                                /*=============  Inputs ================*/
                                0x070 0x17  // P9_11 PINS$28 GPIO0_30 = 30 Input Mode7 pullup
                                0x078 0x17  // P9_12 PINS$30 GPIO1_28 = 60 Input Mode7 pullup
                                0x074 0x17  // P9_13 PINS$29 GPIO0_31 = 31 Input Mode7 pullup
                                0x048 0x17  // P9_14 PINS$18 GPIO1_18 = 50 Input Mode7 pullup
                                0x040 0x17  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 pullup
                                0x04c 0x17  // P9_16 PINS$19 GPIO1_19 = 51 Input Mode7 pullup
                                0x15c 0x17  // P9_17 PINS$87 GPIO0_5  =  5 Input Mode7 pullup
                                0x158 0x17  // P9_18 PINS$86 GPIO0_4  =  4 Input Mode7 pullup

                                /* OUTPUT  GPIO(mode7) 0x07 pulldown, 0x17 pullup, 0x?f no pullup/down */
                                /* INPUT   GPIO(mode7) 0x27 pulldown, 0x37 pullup, 0x?f no pullup/down */
                        >;
                  };
             };
       };

       fragment@1 {
                target = <&ocp>;
                __overlay__ {
                        gpio_helper {
                                compatible = "gpio-of-helper";
                                status = "okay";
                                pinctrl-names = "default";
                                pinctrl-0 = <&ebb_example>;
                        };
                };
        };
};

I also removed ALL overlays from my system before doing this below.
Here is my output from slots and a python program to get the pins i wrote:

root ~/bbb_stuff # slots
 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1
 9: P-O-L-   0 Override Board Name,00A0,Override Manuf,EBB-GPIO-Example

root ~/bbb_stuff # ./getpins 

==================================================
Reading Pinux Pins
==================================================

pin 16 (44e10840.0) 00000027 pinctrl-single
pin 18 (44e10848.0) 00000027 pinctrl-single
pin 19 (44e1084c.0) 00000027 pinctrl-single
pin 28 (44e10870.0) 00000017 pinctrl-single
pin 29 (44e10874.0) 00000027 pinctrl-single
pin 30 (44e10878.0) 00000027 pinctrl-single
pin 86 (44e10958.0) 00000027 pinctrl-single
pin 87 (44e1095c.0) 00000027 pinctrl-single

You can clearly see I have requested them all to be 0x17?  

Here are the alias's I am using:
pins='cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins'
slots='cat /sys/devices/platform/bone_capemgr/slots'

This is the command i used to compile the dt.
dtc -O dtb -o EBB-GPIO-Example-00A0.dtbo -b 0 -@ EBB-GPIO-Example.dts

This is the command I used to install it:
echo  EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots"

This is the dmesg output after installing the overlay:

[ 2629.259630] bone_capemgr bone_capemgr: part_number 'EBB-GPIO-Example-00A0', version 'N/A'
[ 2629.259679] bone_capemgr bone_capemgr: slot #11: override
[ 2629.259700] bone_capemgr bone_capemgr: Using override eeprom data at slot 11
[ 2629.259722] bone_capemgr bone_capemgr: slot #11: 'Override Board Name,00A0,Override Manuf,EBB-GPIO-Example'
[ 2629.271307] gpio-of-helper ocp:gpio_helper: ready
[ 2629.271555] bone_capemgr bone_capemgr: slot #11: dtbo 'EBB-GPIO-Example-00A0.dtbo' loaded; overlay id #0

So any help guys would be really appreciated!  I am thinking that I must be just doing something wrong.  Perhaps the example device tree I am using is outdated?  Would someone be willing to share with me a GPIO device tree that works with kernel 4.1?  Also I have tried the dt builder online:

http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator#1gpiodto

But this seems to not work also.  Thanks again everyone.

Riley

[William Hermans]

Unfortunately the "answer" was to install angstrom.  I was hoping someone on the list would have some secret answer as to why applying an overlay was not changing the pinmux's?

I would very much like to stick with debian but if the answer is go back angstrom I guess I can live with that.

Thanks

You do not have to go back to Angstrom, and if you ask me that is very counter productive. Read my guide here: http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/

Do note, that the kernel I talk about at the beginning is just an example. You do not have to use the exact kernel I demonstrated. Any 4.x kernel should work with that guide.

[Riley Porter]

William,

Thanks.  This basically is exactly what I did reading johns reply.  I guess my main disconnect here is.  I can apply a device tree overlay that I make.  I see it "applied" in dmesg and in slots.  However the pinmux output from cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins continues to show 0x27 for their modes when I specifically set the dtc to 0x17.  

I have not actually tried to use it as an input in code yet.  Merely have been seeing that it is not "applying" what i thought it should.  Perhaps I am looking at the wrong pinoutput?

for example P9_11's offset is 0x70 and its PIN value is 28.  So  | grep 870

root ~/bb.org-overlays # cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep 870
pin 28 (44e10870.0) 00000027 pinctrl-single 

which is not 0x17?

I am being very wordy here just to make sure you guys know exactly what I am doing and my expectations.  

So does anything I am doing look wrong?

Again thanks a bunch guys for the help.  I have been at this for the better part of a week now and I agree William it's a step in the WRONG direction going to Angstrom.

ril3y

[William Hermans]

Again thanks a bunch guys for the help.  I have been at this for the better part of a week now and I agree William it's a step in the WRONG direction going to Angstrom.

I agree, and in fact, I've been a supporter of Robert's debian images since long before they were official. Well, actually early on, I built my own images based on his Debian on ARM guide.

William,

Thanks.  This basically is exactly what I did reading johns reply.  I guess my main disconnect here is.  I can apply a device tree overlay that I make.  I see it "applied" in dmesg and in slots.  However the pinmux output from cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins continues to show 0x27 for their modes when I specifically set the dtc to 0x17. 

Ok, so let me say first that I'm no expert.*BUT* I've seen similar to this when setting pin mode 0x7 on the USR LED "pins". In the debugfs pins/ directory as you mention above. When checked, over other one's pin mode would be 0x17 so in effect . . .

0x7, 0x17, 0x7, 0x17. It stands to reason, that this is by design. How or why, I'm not sure, but I've seen this many times over the last 3 or so years. I've never looked into it however. So, with that said, perhaps this is the same as your case. But of course, slightly different.

[William Hermans]

essentially, I think all that matter is the first 8 bits. Someone correct me here if I'm wrong.

[William Hermans]

essentially, I think all that matter is the first 8 bits. Someone correct me here if I'm wrong.

Never mind, my brain was off some where in la la land. Anyway . . . have you check to see what mux 0x27 means versus 0x17 ?  For all I know the pull-up bit field could be shifted left one bit( left most nibble ), which is what the difference between 0x17, and 0x27 is.

[John Syne]

GPIO MODE SETTINGS
Bit 6	Bit 5	Bit 4	Bit 3	Bit 2,1,0
Slew Control	Receiver Active	Pullup/Pulldown	Enable Pullup/down	Mux Mode
0 Fast	0 Disable	0 Pulldown select	0 Enabled	000 Mode 0 to
1 Enable	1 Pullup select	1 Disabled	111 Mode 7
	e.g. OUTPUT GPIO(mode7) 0x07 pulldown, 0x17 pullup, 0x?f no pullup/down
	e.g. INPUT GPIO(mode7) 0x27 pulldown, 0x37 pullup, 0x?f no pullup/down
	TRM Table 9-60

From the table above, 0x27 in an input and 0x17 is an output. My guess is that there is some conflict that occurs and that is why the config isn’t set correctly. What does your overlay look like and what do you see when you install the overlay?

Regards,

John

[John Syne]

One more thing, just defining pinmux in the overlay will have no effect. The pinmux will only be configured as part of installing the driver. Just before the kernel calls the driver probe function, it sets up the pinmux as defined by the pinctrl definition. 

Regards,

John

[William Hermans]

His overlay is in the first post John.

[William Hermans]

Err sorry his second post.

[John Syne]

Thanks William,

He uses the command:

echo  EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots”

but I think he should be using the command:

sudo sh -c “echo 'EBB-GPIO-Example-00A0' > /sys/devices/platform/bone_capemgr/slots”

Other than that, I don’t see why he has this problem. 

Regards,

John

[William Hermans]

One is done as root, the other is not. I would guess he is probably logged in as root.

[William Hermans]

Riley, confirm device tree compiler version. As such. . .

$ dtc -v
Version: DTC 1.4.1-g5cadadd9

If it's not version 1.4.1-<something>, then you have the wrong version.

[Charles Steinkuehler]

I don't have time to dig into the full details, but IIRC this has
popped up before. I don't think the gpio-of-helper driver actually
does anything (like setup the pinmux) if you're not actually
_exporting_ any gpios. But I could be wrong...it's been a while since
I crawled through the code.

Oh, and your pinmux settings don't match the comments. If you really
want inputs with the pullup enabled, the value to use is 0x37, *NOT*
0x17. It's important to enable the gpio receive buffer (bit 0x20) or
you won't be able to read the value on the GPIO pin (IIRC it will
always return zero). If you really want outputs and just didn't
update the comments, 0x17 is fine.

On 11/27/2015 2:14 PM, Riley Porter wrote:
> Yes I am running:
>

> *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
> GNU/Linux*

>
> I followed your instructions but still am at a loss. I was able to update
> the device tree compiler and the kernel which is now:
>

> *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC 2015
> armv7l GNU/Linux*

>
> Perhaps describing my exact steps might shed some light on my screw up?
>
>

> *This is the device tree I am testing with:*

> *root ~/bbb_stuff # **slots*
>
>
>
>
> * 0: PF---- -1 1: PF---- -1 2: PF---- -1 3: PF---- -1 9: P-O-L- 0
> Override Board Name,00A0,Override Manuf,EBB-GPIO-Example*
>
> *root ~/bbb_stuff # ./getpins *
>
>
>
> *==================================================Reading Pinux
> Pins==================================================*
>
>
>
>
>
>
>
>
> *pin 16 (44e10840.0) 00000027 pinctrl-singlepin 18 (44e10848.0) 00000027
> pinctrl-singlepin 19 (44e1084c.0) 00000027 pinctrl-singlepin 28
> (44e10870.0) 00000017 pinctrl-singlepin 29 (44e10874.0) 00000027
> pinctrl-singlepin 30 (44e10878.0) 00000027 pinctrl-singlepin 86
> (44e10958.0) 00000027 pinctrl-singlepin 87 (44e1095c.0) 00000027
> pinctrl-single*

>
> You can clearly see I have requested them all to be 0x17?
>

> *Here are the alias's I am using:*
>
> *pins='cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins'**slots='cat
> /sys/devices/platform/bone_capemgr/slots'*
>
>
> *This is the command i used to compile the dt.*
> *dtc -O dtb -o EBB-GPIO-Example-00A0.dtbo -b 0 -@ EBB-GPIO-Example.dts*
>
> *This is the command I used to install it:*
> *echo EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots"*
>
>
> *This is the dmesg output after installing the overlay:*
>
>
>
>
>
>
> *[ 2629.259630] bone_capemgr bone_capemgr: part_number

> 'EBB-GPIO-Example-00A0', version 'N/A'[ 2629.259679] bone_capemgr
> bone_capemgr: slot #11: override[ 2629.259700] bone_capemgr bone_capemgr:
> Using override eeprom data at slot 11[ 2629.259722] bone_capemgr
> bone_capemgr: slot #11: 'Override Board Name,00A0,Override
> Manuf,EBB-GPIO-Example'[ 2629.271307] gpio-of-helper ocp:gpio_helper:
> ready[ 2629.271555] bone_capemgr bone_capemgr: slot #11: dtbo

> 'EBB-GPIO-Example-00A0.dtbo' loaded; overlay id #0*

--
Charles Steinkuehler
cha...@steinkuehler.net

[William Hermans]

A good overview of GPIO's and device tree overlays: http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/

Which is something I've been meaning to read myself for a long time . . .

[John Syne]

I believe the pinmux gets setup in pinctrl_bind_pins() found in drivers/pinctrl.c.

pinctrl_bind_pins() gets called by really_probe(), line 291 of drivers/dd.c and then calls the gpio_of_helper_probe on line 316 or 320, so I don’t think this has anything to do with gpio-of-helper.c driver. Probably need to setup some debug statements in pinctrl_bind_pins() to see why this does not work.

Regards,
John

[William Hermans]

Here is what I get by following https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md, and modifying it to reflect one of the pins Riley is using. So, what I suggest is that Riley has an overlay loaded that has already claimed these pins. Either by experimenting previously with different values, and not unloading the previous overlay. Or An overlay unbeknownst to him. I'll experiment now with changing up my overlay and see what happens. But the only other option really is that something on Riley's system is broken.

/*
 * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.

 */
/dts-v1/;
/plugin/;

/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";

    /* identification */
    part-number = "pinctrl-test-7";

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {

            pinctrl_test: pinctrl_test_7_pins {
                pinctrl-single,pins = <

                    0x040 0x17  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 pullup

                >;
            };
        };
    };

    fragment@1 {
        target = <&ocp>;
        __overlay__ {

            test_helper: helper {
                compatible = "gpio-of-helper";
                pinctrl-names = "default";
                pinctrl-0 = <&pinctrl_test>;
                status = "okay";
            };
        };
    };
};

 $ dtc -O dtb -o pinctrl-test-7-00A0.dtbo -b 0 -@ pinctrl-test-7.dts
 $ sudo cp pinctrl-test-7-00A0.dtbo /lib/firmware/
 $ cat /sys/devices/platform/bone_capemgr/slots

 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1

$ sudo sh -c "echo 'pinctrl-test-7' > /sys/devices/platform/bone_capemgr/slots"
$ cat /sys/devices/platform/bone_capemgr/slots
$ cat /sys/devices/platform/bone_capemgr/slots

 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1

 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
$ dmesg |grep pinctrl-test-7
[168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7', version 'N/A'
[168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,pinctrl-test-7'
[168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0

$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 00000017 pinctrl-single

[William Hermans]

OK so I changed to this:

fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            pinctrl_test: pinctrl_test_7_pins {
                pinctrl-single,pins = <

                    0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 pullup
                >;
            };
        };
    };

Compiled, copied, and then loaded the dtbo file. Then . . .

$ dmesg |grep pinctrl-test-7
[168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7', version 'N/A'
[168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,pinctrl-test-7'
[168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0

[169658.533949] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7', version 'N/A'
[169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board Name,00A0,Override Manuf,pinctrl-test-7'
[169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1

This shows that both device tree overlays have been sucessfully loaded. Despite the fact that the previously overwritten overlay was never unloaded. Then . . .

$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 00000017 pinctrl-single

So . . .
i$ cat /sys/devices/platform/bone_capemgr/slots

 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7

 5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7

oops, two overlays loaded lets see wha thappens when first one is unloaded.

$ sudo sh -c "echo '-4' > /sys/devices/platform/bone_capemgr/slots"

$ cat /sys/devices/platform/bone_capemgr/slots
 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1

 5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7

$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 00000017 pinctrl-single

Just as I thought, the original pinmux is persistent. So . . .
$ sudo sh -c "echo '-5' > /sys/devices/platform/bone_capemgr/slots"

$ cat /sys/devices/platform/bone_capemgr/slots
 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1

$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 00000017 pinctrl-single

Ok just as I expected. pinmux's are kept until explicitly changed. Let's try loading it again.

$ sudo sh -c "echo 'pinctrl-test-7' > /sys/devices/platform/bone_capemgr/slots"

$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 00000017 pinctrl-single

Whoopsy . . ..

[William Hermans]

Smells of a bug. But perhaps the GPIO pinmux's need to be explicity cleared as I mentioned above ?

[William Hermans]

OK so I thought maybe I forgot to copy the newly compiled overlay over . . .

$ ls |grep pin
pinctrl-test-7-00A0.dtbo
pinctrl-test-7.dts

$ rm pin*
$ ls |grep pin
< No output >

$ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
$ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts

/dts-v1/;

/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";

    part-number = "pinctrl-test-7";

    fragment@0 {
        target = <0xdeadbeef>;

        __overlay__ {

            pinctrl_test_7_pins {
                pinctrl-single,pins = <0x40 0x27>;
                linux,phandle = <0x1>;
                phandle = <0x1>;
            };
        };
    };

    fragment@1 {
        target = <0xdeadbeef>;

        __overlay__ {

            helper {
                compatible = "gpio-of-helper";
                pinctrl-names = "default";

                pinctrl-0 = <0x1>;
                status = "okay";
                linux,phandle = <0x2>;
                phandle = <0x2>;
            };
        };
    };

    __symbols__ {
        pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
        test_helper = "/fragment@1/__overlay__/helper";
    };

    __local_fixups__ {

        fragment@1 {

            __overlay__ {

                helper {
                    pinctrl-0 = <0x0>;
                };
            };
        };
    };

    __fixups__ {
        am33xx_pinmux = "/fragment@0:target:0";
        ocp = "/fragment@1:target:0";
    };
};

Ok, so this source mangling seems odd, but just looking things over, it seems like it should work. Next, reboot, and reload, then see what happens.

[John Syne]

Hi William,

I think you are right, there must be some sort of conflict on Riley’s system. BTW, 840 is connected to 888, so that pin might not be the best pin to test. Either way, I don’t understand why the Overlay manager doesn’t complain about a pin conflict. 

Regards,

John

[William Hermans]

$ sudo reboot

Broadcast message from root@beaglebone (pts/0) (Fri Nov 27 22:56:19 2015):
The system is going down for reboot NOW!

$ Agent has been released /* Ok wtf is this ?! Bluetooth agent ? */

login as: william
Debian GNU/Linux 7

BeagleBoard.org Debian Image 2015-03-01

Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

default username:password is [debian:temppwd]

wil...@192.168.254.167's password:
Last login: Wed Nov 25 23:21:15 2015 from <an IP address ;) >

$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840

pin 16 (44e10840.0) 00000027 pinctrl-single

WTF is going on here ? Anyhow seems like a bonafied bug ? Or is this the default state in which pins come up as auto-magically ?

[William Hermans]

BTW, 840 is connected to 888, so that pin might not be the best pin to test. Either way, I don’t understand why the Overlay manager doesn’t complain about a pin conflict.

Ok you're going to have to explain that. Since the pin I checked changed. And I've always understood that . . . 32*<GPIO bank >+<GPIO bank pin #>=pin value

[William Hermans]

Or, more correctly I suppose . . .

Pin value = 32 * GPIO bank + pin number.

Where. . .

GPIO Bank == 0-3

Pin number == 0-31

[John Syne]

P9_15A	16	0x840/040	GPIO1_16	48
P9_15B	34	0x888/088	GPIO1_16	64

Regards,

John

[William Hermans]

OK, so 0x27 is

• mode 7
• pullup/pulldown enabled
• pulldown selected
• reciever enabled /* meaning input I guess */

[William Hermans]

As per Riley's overlay source, I only copy pasted it. But changed the pinmux from 0x17, to 0x27 as a test.

0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 pullup

[John Syne]

P9 HEADER

LINUX PIN

ADDR/OFFSET

TRM NAME

GPIO NO.

P9_15A	16	0x840/040	GPIO1_16	48
P9_15B	34	0x888/088	GPIO1_16	64

Regards,

John

[John Syne]

Yeah, you are right, but he also tested on 870, which doesn’t have this conflict. I’m just trying to avoid any other problems that might influence this issue. 

Regards,

John

[William Hermans]

That still does not explain how 0x40 == 0x880 in /sys/kernel/debug/pinctrl/44e10800.pinmux/pins. It should be 840 . . . or  44e10840 if you prefer.

[William Hermans]

OK John, gotcha.

So now idea how to why this is happening. But, it kind of seems like capemgr does not truly work "on the fly" as It is purported to do. e.g. it works once, but then a reboot is needed to change the pinmux value.

*OR*

I do recall reading somewhere in the TRM, around the part you originally talked about John( table 9-60 I think ) where you can clear the pin by writing a value of '1' to a bit location . . . but it could be the TRM was talking about something else perhaps

[John Syne]

Yeah, but they are both connected to P9 Pin15.

Regards,

John

[Riley Porter]

OK guys.  

dtc version here:

root ~/bbb_stuff # dtc --version

Version: DTC 1.4.1-g71222ad7

So after reading your comments I changed my overlay to 0x27 vs 0x17.  I actually want an INPUT with a pulldown for my application.  I tried 0x17 to see if I could control the pin modes for sure.  I guess what you are saying is 0x17 is not a valid mode for the pins I selected?  Either way I changed my overlay to this:

/dts-v1/;

/plugin/;

/{

       compatible = "ti,beaglebone", "ti,beaglebone-black";

       part-number = "EBB-GPIO-Example";

       version = "00A0";

       fragment@0 {

             target = <&am33xx_pinmux>;

             __overlay__ {

                  ebb_example: EBB_GPIO_Example {

                        pinctrl-single,pins = <

                                /*============= Player One Shmoo Deck Inputs ================*/

                                0x070 0x27  // P9_11 PINS$28 GPIO0_30 = 30 Input Mode7 pulldown

                                0x078 0x27  // P9_12 PINS$30 GPIO1_28 = 60 Input Mode7 pulldown

                                0x074 0x27  // P9_13 PINS$29 GPIO0_31 = 31 Input Mode7 pulldown

                                0x048 0x27  // P9_14 PINS$18 GPIO1_18 = 50 Input Mode7 pulldown

                                0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 pulldown

                                0x04c 0x27  // P9_16 PINS$19 GPIO1_19 = 51 Input Mode7 pulldown

                                0x15c 0x27  // P9_17 PINS$87 GPIO0_5  =  5 Input Mode7 pulldown

                                0x158 0x27  // P9_18 PINS$86 GPIO0_4  =  4 Input Mode7 pulldown

                                /* OUTPUT  GPIO(mode7) 0x07 pulldown, 0x17 pullup, 0x?f no pullup/down */

                                /* INPUT   GPIO(mode7) 0x27 pulldown, 0x37 pullup, 0x?f no pullup/down */

                        >;

                  };

             };

       };

       fragment@1 {

                target = <&ocp>;

                __overlay__ {

                        gpio_helper {

                                compatible = "gpio-of-helper";

                                status = "okay";

                                pinctrl-names = "default";

                                pinctrl-0 = <&ebb_example>;

                        };

                };

        };

};

On boot this is the state of slots and the pins in my overlay that I will be changing once its applied.

root ~/bbb_stuff # ./getpins

==================================================

Reading Pinux Pins

==================================================

pin 16 (44e10840.0) 00000027 pinctrl-single

pin 18 (44e10848.0) 00000027 pinctrl-single

pin 19 (44e1084c.0) 00000027 pinctrl-single

pin 28 (44e10870.0) 00000037 pinctrl-single

pin 29 (44e10874.0) 00000037 pinctrl-single

pin 30 (44e10878.0) 00000037 pinctrl-single

pin 86 (44e10958.0) 00000037 pinctrl-single

pin 87 (44e1095c.0) 00000037 pinctrl-single

root ~/bbb_stuff # slots

 0: PF----  -1

 1: PF----  -1

 2: PF----  -1

 3: PF----  -1

 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,cape-universaln

I remove the auto loaded overlay (From where is this loaded I am not sure??)

root ~/bbb_stuff # echo -4 > $SLOTS

root ~/bbb_stuff # slots

 0: PF----  -1

 1: PF----  -1

 2: PF----  -1

 3: PF----  -1

I install my overlay:

root ~/bbb_stuff # make install

-================================================-

INSTALLING EBB-GPIO-Example-00A0.dtbo to /lib/firmware

cp EBB-GPIO-Example-00A0.dtbo /lib/firmware

Activating EBB-GPIO-Example-00A0.dtbo overlay....

echo  EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots"

-================================================-

Check my slots

root ~/bbb_stuff # slots

 0: PF----  -1

 1: PF----  -1

 2: PF----  -1

 3: PF----  -1

 5: P-O-L-   0 Override Board Name,00A0,Override Manuf,EBB-GPIO-Example

root ~/bbb_stuff # ./getpins

==================================================

Reading Pinux Pins

==================================================

pin 16 (44e10840.0) 00000027 pinctrl-single

pin 18 (44e10848.0) 00000027 pinctrl-single

pin 19 (44e1084c.0) 00000027 pinctrl-single

pin 28 (44e10870.0) 00000027 pinctrl-single

pin 29 (44e10874.0) 00000027 pinctrl-single

pin 30 (44e10878.0) 00000027 pinctrl-single

pin 86 (44e10958.0) 00000027 pinctrl-single

pin 87 (44e1095c.0) 00000027 pinctrl-single

So it does look like its working?  My issue I guess was me overthinking it.  I really wanted to make sure it was working so I changed the values to 0x17 to make sure it would "change" but it was apparently a dumb setting and would not work.  Ugh  Sorry to have wasted your time guys!  But I learned a bunch in the process.  I have had a beagle bone for a few years now but always have seen it as a "little linux box" which it is so much more!  This thing is great.  I am so glad its finally working now with the 4.1 kernel and overlays.  

upward and onward.  

One last question, do you guys know of any good indepth overlay device tree tutorials that explain stuff fully. Like the gpio-helper.  I really have no idea what and why I need this etc.

Thanks again!

Riley

[William Hermans]

I guess what you are saying is 0x17 is not a valid mode for the pins I selected? 

No. Read to comment in the code here:

/* OUTPUT  GPIO(mode7) 0x07 pulldown, 0x17 pullup, 0x?f no pullup/down */
/* INPUT   GPIO(mode7) 0x27 pulldown, 0x37 pullup, 0x?f no pullup/down */

Whats the first word of each comment say ? I know the formating could be better for readability sake, but it's all explained right here in these two comments.

In other words, 0x17 is the wrong pinmux for what you wanted to do. Unless you want to run the pin as GPI mode, with the internal pullup enabled.

[William Hermans]

Unless you want to run the pin as GPIO Output mode, with the internal pullup enabled.

gmail is really starting to annoy me today . . .

[Riley Porter]

So I woke up this morning and gave this a go.  I think there still might be something wrong here.  So I have all of my pins that I wish to use set to 0x27 input with pulldown enabled.  Which I assume means they will be pulled low to ground.  (stating the obvious here)

I went to /sys/class/gpio/ and looked to see if they were "exported" but there were not? I am I wrong on understanding that applying a device tree does not export the GPIO pins to /sys/class/gpio?

I went ahead and exported 48 (P9_15 which is set to 0x27) to export.  I then:

root /sys/class/gpio/gpio48 # cat value
1

root /sys/class/gpio/gpio48 # cat direction
in

I tried this for gpio30 (P9_11) and it works as expected.  When I press the button that ties it to 3v3 it registers a 1 all other times its a 0.

I do not know why I am reading a HIGH on this pin?  There is nothing hooked up to this pin externally (as far as i know internally as well).  Perhaps I should just select another pin and move on.  But I after going this far I would rather beat a dead horse and get you guy's input on this?  Any thoughts?

Thanks!

[William Hermans]

As  I said. I'm no expert. In your place, I'd probably start up a google session that lasts for a day or two, If need be.

[Charles Steinkuehler]

On 11/28/2015 1:34 PM, Riley Porter wrote:
> So I woke up this morning and gave this a go. I think there still might be
> something wrong here. So I have all of my pins that I wish to use set to
> 0x27 input with pulldown enabled. Which I assume means they will be pulled
> low to ground. (stating the obvious here)
>
> I went to /sys/class/gpio/ and looked to see if they were "exported" but
> there were not? I am I wrong on understanding that applying a device tree
> does not export the GPIO pins to /sys/class/gpio?

A device tree overlay _can_ export GPIO pins (using the gpio-of-helper
driver), but it doesn't have to. Note that there is a difference
between *exporting* the GPIO pin and setting it's pinmux to a specific
value. The device tree file you sent previously sets up pinmux
values, but doesn't actually export any GPIOs.

> I went ahead and exported 48 (P9_15 which is set to 0x27) to export. I
> then:
>

> *root /sys/class/gpio/gpio48 # cat value**1*
>
> *root /sys/class/gpio/gpio48 # cat directionin*

>
> I tried this for gpio30 (P9_11) and it works as expected. When I press the
> button that ties it to 3v3 it registers a 1 all other times its a 0.
>
> I do not know why I am reading a HIGH on this pin? There is nothing hooked
> up to this pin externally (as far as i know internally as well). Perhaps I
> should just select another pin and move on. But I after going this far I
> would rather beat a dead horse and get you guy's input on this? Any
> thoughts?

Per the schematic, it looks like P9_15 is hooked to GPIO1_16 (ball
R13) as well as GPIO2_0 (ball T13) via resistors R160 and R161, both
of which are populated on my board. What is the pinmux setting for
GPIO2_0? It could be fighting your pull-down setting if it's set to
pull up or drive a high level.

--
Charles Steinkuehler
cha...@steinkuehler.net