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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 [email protected]. >>>>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORogof2a4gaJ7cFKcKbNJWG8TSMOJUA7o%2BuinYPH3kx0xQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
