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