Getting EQEPs Working With Debian Buster

I’m new to embedded Linux and Beaglebones, so I have a lot to learn. I want to use the Beaglebone Black to control 3 closed-loop stepper motors. Connecting the 'bone to A4988 step sticks is fairly easy, but I’m having trouble reading the encoders. I read this topic: “Getting EQEP2 to work on the PocketBeagle”, so it looks like I should be able to set up the eqeps just using “config-pin p8.12 qep”, but I just get the following error:

bash: /usr/local/bin/config-pin: No such file or directory

if I use the “maintainable” version of config-pin, or

/usr/local/bin/config-pin: 1489: echo: echo: I/O error
Cannot write pinmux file: /sys/devices/platform/ocp/ocp:P8_12_pinmux/state

if I use the shell script version. Is this a Debian Buster issue? Do I need to use a Device Tree Overlay? Help!

Here’s the output of

dogtag:[ Debian Buster IoT Image 2020-04-06]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-g31a8ae0206]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[]
UBOOT: Loaded Overlay:[]
UBOOT: Loaded Overlay:[]
/boot/uEnv.txt Settings:
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[ 43.687360] remoteproc remoteproc0: wkup_m3 is available
[ 44.122522] remoteproc remoteproc0: powering up wkup_m3
[ 44.122552] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217148
[ 44.122814] remoteproc remoteproc0: remote processor wkup_m3 is now up
[ 47.147976] remoteproc remoteproc1: is available
[ 47.163659] remoteproc remoteproc2: is available
dmesg | grep pru
[ 47.147976] remoteproc remoteproc1: is available
[ 47.148166] pru-rproc PRU rproc node pru@4a334000 probed successfully
[ 47.163659] remoteproc remoteproc2: is available
[ 47.163812] pru-rproc PRU rproc node pru@4a338000 probed successfully
dmesg | grep pinctrl-single
[ 0.954504] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[ 0.968176] gpio-of-helper ocp:cape-universal: ready
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

1 Like

I may have found a partial answer. Perusing this, Beagleboard:BeagleBoneBlack Debian - , it looks as if I need to enable the “universal cape” and (based on other reading) disable video in uEnv.txt. I had already enabled the “universal cape”, and disabling video made no difference.

It is with great embarrassment that I announce that all I had to do was switch from

config-pin p8.12 qep

config-pin p8.12 eqep



Hi Dirt!

There’s an eQEP module in each PWM subsystem 0-2, so three modules in total. In order to use the module in PWMSS-1 you’ve to dissable (some) HDMI lines (P8_31, P8_33, P8_35). The other modules are wired to free header pins. Find details at libpruio: Pins

While the config-pin solution is full of (undocumented) quirks and pitfalls, the driver libpruio

  • makes it more easy to handle the eQEP signals,
  • executes much faster and
  • supports the index signal to (re-)synchonize the (initial) decoder position.


Hello Thomas,
Thanks for the pointer to your webpage. There’s a lot of information on it. I’ve looked at libpruio, and it looks very powerful and helpful. My only concern with it is that my project would become multi-lingual. Please remember the old joke:
What do you call someone who speaks three languages? Trilingual.
What do you call someone who speaks two languages? Bilingual.
What do you call someone who speaks only one language? An American.
I’d rather not introduce more complexity into my project than necessary. Having spent hours studying the source code of config-pin.c, I feel fairly confident that I can turn off HDMI and load the universal cape in uEnv.txt and then control the eQEP pins at will. However, I may come back with my tail between my legs after trying it today.

In order to use libpruio you’ll include C source header files and link against a shared library binary. Why do you think that you’ll end up with a polyglot project?

Where do I get the binary?

Don’t Be embarrassed! Be proud! Years from now, this post is going to help some enterprising noob (like me right now) solve their own problem(s) with your solution.

@ RobertCNelson
Refering to this post, did you build the packages yet?

You’ll have to switch to the bone kernel flavour in order to get the uio_pruss driver running.

Did you know that, when omiting the underscore in your nick name, it reads like ‘Dreck’, the German word for mud/dirt?

@Thomas I did not know that, but even in English dreck means something undesirable, like dross or slime. What do you mean by “the bone kernel flavor”? I’m using kernel:[4.19.94-ti-r71] that I downloaded from - latest-images.


sudo apt update
cd /opt/scripts/tools
git pull
sudo ./ --bone-kernel --lts-4_19

Find details at Beagleboard:BeagleBoneBlack Debian -