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





On Fri, Nov 27, 2015 at 10:26 PM, William Hermans <[email protected]> wrote:

> 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
>
> On Fri, Nov 27, 2015 at 10:14 PM, John Syne <[email protected]> wrote:
>
>> 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
>>
>>
>>
>>
>> > On Nov 27, 2015, at 7:25 PM, Charles Steinkuehler <
>> [email protected]> wrote:
>> >
>> > 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:*
>> >>
>> >>
>> >> /*
>> >>> 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-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*
>> >>
>> >>
>> >>
>> >> 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
>> >>
>> >> On Thu, Nov 26, 2015 at 2:13 PM, John Syne <[email protected]> wrote:
>> >>
>> >>> 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
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Nov 26, 2015, at 8:35 AM, Riley Porter <[email protected]>
>> wrote:
>> >>>
>> >>> 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
>> >>>
>> >>> --
>> >>> 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 [email protected].
>> >>> For more options, visit https://groups.google.com/d/optout.
>> >>>
>> >>>
>> >>> --
>> >>> 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 [email protected].
>> >>> For more options, visit https://groups.google.com/d/optout.
>> >>>
>> >>
>> >
>> >
>> > --
>> > Charles Steinkuehler
>> > [email protected]
>> >
>> > --
>> > 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 [email protected].
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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 [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to