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



On Fri, Nov 27, 2015 at 2:03 PM, Riley Porter <[email protected]> wrote:

> 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) 000000*27* 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
>
>
>
> On Fri, Nov 27, 2015 at 3:45 PM, William Hermans <[email protected]>
> wrote:
>
>> *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.
>>
>>
>> On Fri, Nov 27, 2015 at 1:14 PM, Riley Porter <[email protected]>
>> 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.
>>>>
>>>
>>> --
>>> 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.
>

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