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/CALHSORqKnZC0gSJUHbTuit-dTZnQb8ohqrdMij4CpGEmmdZO3Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
