> > *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. On Fri, Nov 27, 2015 at 4:02 PM, William Hermans <[email protected]> wrote: > essentially, I think all that matter is the first 8 bits. Someone correct > me here if I'm wrong. > > On Fri, Nov 27, 2015 at 4:00 PM, William Hermans <[email protected]> > wrote: > >> *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.
