So, what is bothering me about this is that I do not know if this particular problem has been discussed before, and is a known issue or not. To me it truly seems to be a bug, but other than what I've done, I know no way of confirming this.
So just to keep things clear. The behavior I talked about above only effects the Beaglebone Green. There is not such issue with the Beaglebone Black. But I do not know why, nor do I know how to correct this. Shouldn't this be an important issue ? Or does everyone feel that is should be necessary to configure this pin via a device tree overlay file in order for this 1 pin to be usable ? On Wed, Sep 7, 2016 at 8:35 PM, William Hermans <yyrk...@gmail.com> wrote: > So, I still do not know what exactly the problem *is*. So for those of you > who need to use this pin, I guess you, and everyone else who is using a 4.x > kernel will have to load a device tree overlay *just* for gpio1_16 to work > correctly under sysfs. kernels 3.8.x I'm not sure about. > > On Wed, Sep 7, 2016 at 6:09 PM, William Hermans <yyrk...@gmail.com> wrote: > >> Let me rephrase that. The board seems to boot and come up, but I was >> unable to ssh into the board. For whatever reason. Did not care to look why. >> >> On Wed, Sep 7, 2016 at 6:08 PM, William Hermans <yyrk...@gmail.com> >> wrote: >> >>> So, booting and loading am335x-bonegreen-overlay.dtb on a beaglebone >>> green will render the board unbootable. >>> >>> On Wed, Sep 7, 2016 at 5:24 PM, William Hermans <yyrk...@gmail.com> >>> wrote: >>> >>>> Just for clarity >>>> >>>> *debian@beaglebone:~$* sudo sh -c "echo '1' > >>>> /sys/class/gpio/gpio51/value" >>>> *debian@beaglebone:~$* cat /sys/class/gpio/gpio48/value >>>> 0 >>>> *debian@beaglebone:~$* sudo sh -c "echo '0' > >>>> /sys/class/gpio/gpio51/value" >>>> *debian@beaglebone:~$* cat /sys/class/gpio/gpio48/value >>>> 1 >>>> >>>> So, I'm not experiencing an "off by 1" issue. But for some reason >>>> gpio1_16 *only* works if a universal IO overlay that deals with gpio1_16 >>>> appropriately - *somehow*. I'm not sure what I'm missing. Is this a >>>> software bug of some sort ? >>>> >>>> >>>> On Wed, Sep 7, 2016 at 4:39 PM, William Hermans <yyrk...@gmail.com> >>>> wrote: >>>> >>>>> Ah, but the "Drama" continues . . . >>>>> >>>>> *debian@beaglebone:~$* sudo sh -c "echo '0' > >>>>> /sys/class/gpio/gpio51/value" >>>>> *debian@beaglebone:~$* cat /sys/class/gpio/gpio48/value >>>>> 0 >>>>> *debian@beaglebone:~$* sudo sh -c "echo '1' > >>>>> /sys/class/gpio/gpio51/value" >>>>> *debian@beaglebone:~$* cat /sys/class/gpio/gpio48/value >>>>> 0 >>>>> >>>>> Ok, that's wrong . . . so. . . >>>>> >>>>> *debian@beaglebone:~$* wget https://raw.githubusercontent. >>>>> com/cdsteinkuehler/beaglebone-universal-io/master/config-pin >>>>> *debian@beaglebone:~$ *chmod +x config-pin >>>>> *debian@beaglebone:~$* sudo ./config-pin overlay univ-all >>>>> Loading univ-all overlay >>>>> *debian@beaglebone:~$* sudo ./config-pin P9.16 hi >>>>> *debian@beaglebone:~$* cat /sys/class/gpio/gpio48/value >>>>> 0 >>>>> *debian@beaglebone:~$* sudo ./config-pin P9.16 low >>>>> *debian@beaglebone:~$* cat /sys/class/gpio/gpio48/value >>>>> 1 >>>>> >>>>> So, Robert, Charles, anyone ? What gives ? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Sep 7, 2016 at 4:17 PM, William Hermans <yyrk...@gmail.com> >>>>> wrote: >>>>> >>>>>> So, I think *maybe* I might have narrowed down the problem. My >>>>>> assumption is that gpio64(gpio2_0) is perhaps set >>>>>> default by the processor to an output. Until the pin is exported via >>>>>> the sysfs gpio mechanism. One only need to export the pin and then >>>>>> everything works fine. I'll confirm this later with an oscilloscope >>>>>> reading >>>>>> later to backup my assumption. With that said I dug through all the >>>>>> include files, headers, and whatnot. Conspicuously there was mention of >>>>>> emmc_pins for the green overlay file, but gpio2_0 was not muxed in the >>>>>> file >>>>>> am335x-bone-common.dtsi. >>>>>> >>>>>> Worklog below, and yes this did physically toggle an LED on our test >>>>>> fixture. >>>>>> >>>>>> *debian@beaglebone:~$* ls /sys/class/gpio >>>>>> export gpio115 gpiochip0 gpiochip32 gpiochip64 gpiochip96 >>>>>> unexport >>>>>> *debian@beaglebone:~$* sudo sh -c "echo '64' > >>>>>> /sys/class/gpio/export" >>>>>> *debian@beaglebone:~$* ls /sys/class/gpio >>>>>> export gpio115 gpio64 gpiochip0 gpiochip32 gpiochip64 >>>>>> gpiochip96 unexport >>>>>> *debian@beaglebone:~$* cat /sys/class/gpio/gpio64/direction >>>>>> in >>>>>> *debian@beaglebone:~$* cat /sys/devices/platform/ >>>>>> alarmtimer/ fixedregulator@0/ omap-pcm-audio/ >>>>>> pmu/ serial8250/ ti-cpufreq.0/ >>>>>> bone_capemgr/ leds/ opp_table0/ >>>>>> power/ snd-soc-dummy/ uevent >>>>>> cpufreq-dt/ ocp/ pm33xx.0/ >>>>>> reg-dummy/ soc/ >>>>>> *debian@beaglebone:~$* cat /sys/devices/platform/ >>>>>> alarmtimer/ fixedregulator@0/ omap-pcm-audio/ >>>>>> pmu/ serial8250/ ti-cpufreq.0/ >>>>>> bone_capemgr/ leds/ opp_table0/ >>>>>> power/ snd-soc-dummy/ uevent >>>>>> cpufreq-dt/ ocp/ pm33xx.0/ >>>>>> reg-dummy/ soc/ >>>>>> *debian@beaglebone:~$* cat /sys/devices/platform/bone_capemgr/slots >>>>>> 0: PF---- -1 >>>>>> 1: PF---- -1 >>>>>> 2: PF---- -1 >>>>>> 3: PF---- -1 >>>>>> *debian@beaglebone:~$* sudo sh -c "echo '48' > >>>>>> /sys/class/gpio/export" >>>>>> *debian@beaglebone:~$* cat /sys/class/gpio/gpio48/direction >>>>>> in >>>>>> *debian@beaglebone:~$* sudo sh -c "echo '51' > >>>>>> /sys/class/gpio/export" >>>>>> *debian@beaglebone:~$* cat /sys/class/gpio/gpio51/direction >>>>>> in >>>>>> *debian@beaglebone:~$* sudo sh -c "echo 'out' > >>>>>> /sys/class/gpio/gpio51/direction" >>>>>> *debian@beaglebone:~$* cat /sys/class/gpio/gpio51/direction >>>>>> out >>>>>> *debian@beaglebone:~$* sudo sh -c "echo '1' > >>>>>> /sys/class/gpio/gpio51/value" >>>>>> *debian@beaglebone:~$* sudo sh -c "echo '0' > >>>>>> /sys/class/gpio/gpio51/value" >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Sep 7, 2016 at 3:29 PM, William Hermans <yyrk...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> No bites on this post ? I did find a post from 2014 where someone >>>>>>> else was discussing with Gerald about this situation as well. But it >>>>>>> appears now days the software is somehow overriding this behavior. >>>>>>> Unless >>>>>>> the designers of the green somehow messes up. I've not yet found >>>>>>> anything >>>>>>> in the board file. >>>>>>> >>>>>>> /* >>>>>>> * 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/; >>>>>>> >>>>>>> #include "am33xx.dtsi" >>>>>>> #include "am335x-bone-common.dtsi" >>>>>>> #include "am33xx-overlay-edma-fix.dtsi" >>>>>>> >>>>>>> /* pruss: pick one: */ >>>>>>> >>>>>>> /* >>>>>>> * /etc/modprobe.d/pruss-blacklist.conf >>>>>>> * >>>>>>> * blacklist uio_pruss >>>>>>> */ >>>>>>> >>>>>>> /* #include "am33xx-pruss-rproc.dtsi" */ >>>>>>> >>>>>>> /* >>>>>>> * /etc/modprobe.d/pruss-blacklist.conf >>>>>>> * >>>>>>> * blacklist pruss >>>>>>> * blacklist pruss_intc >>>>>>> * blacklist pru-rproc >>>>>>> */ >>>>>>> >>>>>>> /* #include "am33xx-pruss-uio.dtsi" */ >>>>>>> >>>>>>> / { >>>>>>> model = "TI AM335x BeagleBone Green"; >>>>>>> compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", >>>>>>> "ti,am335x-bone", "ti,am33xx"; >>>>>>> }; >>>>>>> >>>>>>> &ldo3_reg { >>>>>>> regulator-min-microvolt = <1800000>; >>>>>>> regulator-max-microvolt = <1800000>; >>>>>>> regulator-always-on; >>>>>>> }; >>>>>>> >>>>>>> &mmc1 { >>>>>>> vmmc-supply = <&vmmcsd_fixed>; >>>>>>> }; >>>>>>> >>>>>>> &mmc2 { >>>>>>> vmmc-supply = <&vmmcsd_fixed>; >>>>>>> pinctrl-names = "default"; >>>>>>> pinctrl-0 = <&emmc_pins>; >>>>>>> bus-width = <8>; >>>>>>> status = "okay"; >>>>>>> }; >>>>>>> >>>>>>> &cpu0_opp_table { >>>>>>> /* >>>>>>> * All PG 2.0 silicon may not support 1GHz but some of the early >>>>>>> * BeagleBone Blacks have PG 2.0 silicon which is guaranteed >>>>>>> * to support 1GHz OPP so enable it for PG 2.0 on this board. >>>>>>> */ >>>>>>> oppnitro@1000000000 { >>>>>>> opp-supported-hw = <0x06 0x0100>; >>>>>>> }; >>>>>>> }; >>>>>>> >>>>>>> The includes should not make a difference as they're going to be the >>>>>>> same for the boneblack board file as well . . . >>>>>>> >>>>>>> I did find something in the file : https://github.com/beagleboard >>>>>>> /bb.org-overlays/blob/master/src/arm/cape-CBB-Serial-r01.dts >>>>>>> >>>>>>> bb_uart4_pins: pinmux_bb_uart4_pins { >>>>>>> pinctrl-single,pins = < >>>>>>> BONE_P9_11 (PIN_INPUT_PULLUP | MUX_MODE6) /* >>>>>>> gpmc_wait0.uart4_rxd_mux2 */ >>>>>>> BONE_P9_13 (PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* >>>>>>> gpmc_wpn.uart4_txd_mux2 */ >>>>>>> BONE_P9_15 (PIN_INPUT | MUX_MODE7) /* >>>>>>> gpmc_a0.gpio1[16] */ >>>>>>> *0x088 (PIN_INPUT | MUX_MODE7) /* >>>>>>> gpmc_csn3.gpio2[0] */* >>>>>>> >; >>>>>>> }; >>>>>>> >>>>>>> That should be the culprit, but do I realy need to create a seperate >>>>>>> custom board file just for this purpose ? Seems a bit extreme . . . >>>>>>> >>>>>>> On Wed, Sep 7, 2016 at 2:04 PM, William Hermans <yyrk...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> err, that wrong what I said above. First, we have a circuit between >>>>>>>> another gpio, and gpio2_16 as a test circuit >>>>>>>> . To test the input pin. So the overlay file univ-all is muxing the >>>>>>>> pins exactly right for us on this one input pin. However, as stated the >>>>>>>> board being used is intended to be used without universal io, config >>>>>>>> pin, >>>>>>>> or any of that. >>>>>>>> >>>>>>>> On Wed, Sep 7, 2016 at 2:00 PM, William Hermans <yyrk...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Additionally, using: >>>>>>>>> >>>>>>>>> $ sudo config-pin overlay univ-all >>>>>>>>> $ sudo config-pin P9.15 hi / low >>>>>>>>> >>>>>>>>> Seems to work fine on the BBG too. However the idea is to use >>>>>>>>> P9.15 as normal through sysfs. Without having to mux the pins. If at >>>>>>>>> all >>>>>>>>> possible. But since pin is not exactly brought out to the header( >>>>>>>>> except >>>>>>>>> that it's tied to gpio1_16 ) it's not going to have a header pin >>>>>>>>> value. >>>>>>>>> However knowing the gpio number needing to be echoed into the export >>>>>>>>> file >>>>>>>>> would be fine too. It such a critter existed. Which I am thinking it >>>>>>>>> is >>>>>>>>> also possible that it also does >>>>>>>>> not exist . . . >>>>>>>>> >>>>>>>>> On Wed, Sep 7, 2016 at 1:51 PM, William Hermans <yyrk...@gmail.com >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> So as the subject says we're having issues with gpio1_16 and >>>>>>>>>> gpio2_0 being tied together through r161. We've removed r161 on one >>>>>>>>>> beaglebone green, then export gpio48(gpio1_16) through sysfs, set the >>>>>>>>>> direction to 'in', in an attempt to read input to an externally >>>>>>>>>> connected >>>>>>>>>> sensor. This does not work. However, as soon as we swap the BBG out >>>>>>>>>> for a >>>>>>>>>> BBB, the software we have reading the input pins works perfectly. >>>>>>>>>> >>>>>>>>>> So my question is this: Is there some sort of software binding >>>>>>>>>> through the initial boot board device tree file between these two >>>>>>>>>> pins that >>>>>>>>>> also needs to be changed ? Instead of or including removing r161 ? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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+unsubscr...@googlegroups.com. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/d/msgid/beagleboard/69c9a3a9-38a3- >>>>>>>>>> 4145-94e4-836bb5bfc711%40googlegroups.com >>>>>>>>>> <https://groups.google.com/d/msgid/beagleboard/69c9a3a9-38a3-4145-94e4-836bb5bfc711%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORp9bFDak65uRsFpv_Bp7qhTh%3DEfLKewB2SQ5y2fHw%3DjbQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
