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/CALHSORrYDm10uE2MK6%3DoENpq2eM--Zss%2BzgCWuE4f%2Bpp-d2hPQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
