Cannot set any pins GPIO.IN

[StokesMIDE]

Attempting to set any GPIO pin to GPIO.IN raises a ValueError.
Example:

debian@beaglebone:~$ sudo python
Python 2.7.13 (default, Nov 24 2017, 17:33:09)
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from Adafruit_BBIO import GPIO
>>> GPIO.cleanup()
>>> GPIO.setup("P8_14", GPIO.IN)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Set gpio mode failed, missing file or invalid permissions.

All available GPIO pins were tried; attempting to set any of them to GPIO.IN failed. GPIO.OUT appears to work, however.

Originally attempted with a fresh image of bone-debian-9.3-lxqt-armhf-2018-01-21-4gb (kernel 4.9.77-ti-r92), with all packages upgraded. The next set of attempts were done after updating the kernel to 4.14.15-ti-r29; the results were the same.

The result was the same using Adafruit-BBIO-1.0.9 (the pre-installed version) and after updating to Adafruit-BBIO-1.0.10. Running Python with or without sudo made no difference.

System info (after last attempt):

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
git:/opt/scripts/:[b5d4d4251cc19ff84bc5ad0076cc4493caa3a7f1]
eeprom:[A335BNLT00C02017BBBK36FD]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-01-21]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2018.01-00002-g9aa111a004]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2016.01-00001-g4eb802e]
kernel:[4.14.15-ti-r29]
nodejs:[v6.12.3]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20180125.0-0rcnee0~stretch+20180125]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee2~stretch+20180104]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
dmesg | grep pinctrl-single
[    0.941832] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
END

/boot/uEnv.txt (after last attempt):

#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.14.15-ti-r29
#uuid=
#dtb=


###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/<file0>.dtbo
#uboot_overlay_addr1=/lib/firmware/<file1>.dtbo
#uboot_overlay_addr2=/lib/firmware/<file2>.dtbo
#uboot_overlay_addr3=/lib/firmware/<file3>.dtbo
###
###Additional custom capes
#uboot_overlay_addr4=/lib/firmware/<file4>.dtbo
#uboot_overlay_addr5=/lib/firmware/<file5>.dtbo
#uboot_overlay_addr6=/lib/firmware/<file6>.dtbo
#uboot_overlay_addr7=/lib/firmware/<file7>.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.4.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo
###pru_uio (4.4.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
###Cape Universal Enable
enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks... (60000 = 384KB)
#uboot_fdt_buffer=0x60000
###U-Boot Overlays###

cmdline=coherent_pool=1M net.ifnames=0 quiet

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e

##Example v3.8.x
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
#cape_enable=bone_capemgr.enable_partno=

##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

This is basically a duplicate of #206, but I was asked (by @pdp7) to create a new issue.

[RobertCNelson]

@StokesMIDE your version of u-boot in the eMMC is too old, thus blocking all the new features built into the newer U-Boot..

bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2018.01-00002-g9aa111a004]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2016.01-00001-g4eb802e]

Run this command to surgically remove the old version of U-Boot from the eMMC:

sudo dd if=/dev/zero of=/dev/mmcblk1 count=1 seek=1 bs=128k

Then enjoy all the new gpio wonderfulness.

Regards,

[StokesMIDE]

@RobertCNelson - That seemed to work on a fresh image, although those two lines in the version info didn't change. GPIO input continued to work after I disabled the HDMI and audio. The problem came back after I then attempted to enable UARTs 1, 4, and 5. Since your solution initially worked, I'm not sure if this should be considered a separate issue.

Version info dump after last attempt:

debian@dashboard4:~$ sudo /opt/scripts/tools/version.sh
git:/opt/scripts/:[714e162ba98cf3d2897e7fc95e951c6df15a7d0a]
eeprom:[A335BNLT00C02017BBBK36FD]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-01-21]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2018.01-00002-g9aa111a004]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2016.01-00001-g4eb802e]
kernel:[4.9.77-ti-r92]
nodejs:[v6.12.3]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[enable_uboot_cape_universal=1]
uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/BB-UART1-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr1=/lib/firmware/BB-UART4-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr2=/lib/firmware/BB-UART5-00A0.dtbo]
pkg:[bb-cape-overlays]:[4.4.20180125.0-0rcnee0~stretch+20180125]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee2~stretch+20180104]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]
dmesg | grep pinctrl-single
[    1.393304] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
END

In addition to uncommenting the lines to disable audio and video, here's what I added to the end of /boot/uEnv.txt to enable the UARTs:

cape_enable=bone_capemgr.enable_partno=BB-UART5,BB-UART4,BB-UART1

uboot_overlay_addr0=/lib/firmware/BB-UART1-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-UART4-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/BB-UART5-00A0.dtbo

Note that this is a fresh image of bone-debian-9.3-lxqt-armhf-2018-01-21-4gb, using kernel 4.9.77-ti-r92, with all packages upgraded. The uname_r= line in uEnv.txt (not shown above) correctly refers to that version. Upgrading the kernel to 4.14.15-ti-r29 was suggested in #206, but that doesn't (currently) seem to be an option; using that version, the BBB won't boot at all with the UART overlays.

[RobertCNelson]

@StokesMIDE ah, then we might be dealing with a fat partition:

What does lsblk show?

Regards,

[StokesMIDE]

@RobertCNelson

debian@dashboard4:~$ lsblk -a -f
NAME         FSTYPE LABEL  UUID                                 MOUNTPOINT
mmcblk0
mqmmcblk0p1  ext4   rootfs 655ed15a-ebd7-4055-8e9f-c0274d16f953 /
mmcblk1
mqmmcblk1p1  ext4   BOOT   5ebc9bbf-8e74-4e0a-a0c8-2a8e05158f18
mmcblk1boot0
mmcblk1boot1

(edit: added filesystem column)

[RobertCNelson]

Weird, i'd erase the eMMC..

Regards,

[StokesMIDE]

Okay, I erased the eMMC, but it did not do any good. However, I found a solution that seems to work. I'm hesitant to call it a real fix; it feels like a hack, generates some warnings, and I'm not sure if it itself fixed things or if it is a combination of everything that makes things work.

Anyway, I got the UARTs and GPIO.IN working by adding the overlay cape-universalh (it was included with the distro, but here's its repo), which exports all pins other than those used by the eMMC. The end of my /boot/uEnv.txt now looks like:

cape_enable=bone_capemgr.enable_partno=cape-universalh,BB-UART5,BB-UART4,BB-UART1

uboot_overlay_addr0=/lib/firmware/cape-universalh-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-UART1-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/BB-UART4-00A0.dtbo
uboot_overlay_addr3=/lib/firmware/BB-UART5-00A0.dtbo

This was using bone-debian-9.3-lxqt-armhf-2018-01-21-4gb, kernel 4.9.77-ti-r92, booted from SD.

As I said, this combination of overlays generates warnings about pin reassignment on boot (seen on ttyO0), but the UARTs and the GPIO inputs I need all seem to work. I can probably get rid of the warnings by rolling my own version of the cape-universalh overlay.

I have to confess that I don't fully 'get' the structure of overlay files. Is this a viable fix, or is this a virtual Rube Goldberg machine with its own issues that simply have yet to be seen?

[RobertCNelson]

@StokesMIDE don't add cape-universal overlay directly.

In /boot/uEnv.txt make sure these are set:

enable_uboot_overlays=1
enable_uboot_cape_universal=1

Then un-comment which block you'd like to disable:

#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1

Finally, once booted, use "config-pin" to set the uart pin's for uart1/uart4/uart5..

Regards,

[StokesMIDE]

@RobertCNelson They were. These are the relevant lines from my /boot/uEnv.txt:

###Master Enable
enable_uboot_overlays=1
###Cape Universal Enable
enable_uboot_cape_universal=1

#disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1

These were uncommented before I tried adding cape-universalh; the pins were supposedly free, but still couldn't be set to GPIO.IN if I loaded the UART overlays.

[RobertCNelson]

Correct, once you "set" it to load a custom overlay (UART) cape-universal will go bubye..

But you don't need to have it load your UART overlay, because when you set:

###Master Enable
enable_uboot_overlays=1
###Cape Universal Enable
enable_uboot_cape_universal=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1

The uart is actually enabled, you just need to run:

config-pin P9_24 uart
config-pin P9_26 uart

and uart1 will just work, (do the same with uart4 & uart5 pins)

Regards,

[StokesMIDE]

@RobertCNelson Is there a way to set up flow control via config-pin? I need both RTS and CTS on UARTs 4 and 5; the only way I was able to get that working was via overlays. Sorry for not making that clear; since they were something I added, I excluded them in the test above to try to isolate the problem.

I really need all this persistently configured; the BB will be running headless and (mostly) unattended. Solutions that use scripts to execute config-pin that I've seen seem to require giving users/groups superuser access without passwords, which makes me uneasy. Do I need to generate my own overlay?

[RobertCNelson]

Okay, yeah that's a special situation, i'd just add the gpio's you need to the uart overlays today.

I'm working on a better fix for down the road, but it's not ready today..

Regards,

[pdp7]

Okay, yeah that's a special situation, i'd just add the gpio's you need to the uart overlays today.

@StokesMIDE would that suggestion by @RobertCNelson work for your situation?

[RobertCNelson]

@pdp7 no what @StokesMIDE want's to relies on the Cape Universal Rewrite:

Here's the milestone i quckly put up..

https://github.com/beagleboard/bb.org-overlays/milestone/1

Regards,

[pdp7]

Is there a way to set up flow control via config-pin? I need both RTS and CTS on UARTs 4 and 5; the only way I was able to get that working was via overlays.

@StokesMIDE are you able to achieve what you need using the custom overlay?

[StokesMIDE]

@pdp7 No, my attempted overlay didn't work. That's really an issue with my understanding of overlays, though, not anything specific to adafruit-beaglebone-io-python.

@RobertCNelson Even though I shouldn't be explicitly applying cape-universalh, is doing so actually harmful? I need to move forward, and it seems to work fine; if it isn't going to hurt anything, can I leave it in, and return to creating my own overlay later?

[StokesMIDE]

Incidentally, after moving my SD to a different BBB, I can confirm that updating u-boot on the eMMC was indeed a necessary step. That might be helpful to others having (different) GPIO issues.

[pdp7]

@StokesMIDE I chatted with @RobertCNelson about this and I believe it is an acceptable solution for you to edit cape-universalh to have full control over the UART settings.

Are your needs satisfied with the custom cape-universalh?

[pdp7]

@StokesMIDE is it OK to close this issue?

[skfelix]

The cape-universalh may conflict your other device tree overlays, so I've edited the cape-universalh-00A0.dts and put only the pins I wanted to use, and it worked:
cape-universalh-custom-00A0.zip