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