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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[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/CALHSORpDZCUFmNRH66VqPESHfRnRQQYtx0%2BEez3Duxaygxw__A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
