gpio1_16 and gpio2_0 issues on beaglebone green.

[William Hermans]

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 ?

[William Hermans]

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 <yyr...@gmail.com> 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 beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/69c9a3a9-38a3-4145-94e4-836bb5bfc711%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

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.

[William Hermans]

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 . . .

[William Hermans]

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"

[William Hermans]

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 ?

[William Hermans]

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 ?

[William Hermans]

So, booting and loading am335x-bonegreen-overlay.dtb on a beaglebone green will render the board unbootable.

[William Hermans]

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.

[William Hermans]

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.

[William Hermans]

So, what is bothering me about this is that I do not know if this particular problem has been discussed before, and is a known issue or not. To me it truly seems to be a bug, but other than what I've done, I know no way of confirming this.

So just to keep things clear. The behavior I talked about above only effects the Beaglebone Green. There is not such issue with the Beaglebone Black. But I do not know why, nor do I know how to correct this.

Shouldn't this be an important issue ? Or does everyone feel that is should be necessary to configure this pin via a device tree overlay file in order for this 1 pin to be usable ?