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