Problem with BB-UART1 overlay using P8 header pins

Running on a BBW.

~# cat /etc/dogtag Debian Image 2015-11-12

~# uname -a
Linux alarmbone 4.1.12-ti-r29 #1 SMP PREEMPT Mon Nov 9 22:46:19 UTC 2015 armv7l GNU/Linux

~# cat $SLOTS

0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 0 Override Board Name,00A0,Override Manuf,univ-all

I’m basically using all of the GPIO on the P8 Header.

I now want a UART or two, for some new functionality, seems UART1 & UART2 only use pins on P9 Header so in /boot/uEnv.txt so I added:

##Example v4.1.x

After I reboot the slot 4: becomes BB-UART1
and a simple loopback test with minicom after jumpering P9_22 to P9_24 shows the UART /dev/ttyO1 is working. But none of the P8 GPIO are exported. No problem as my
code exported them anyways, even though it seemed not required with 4.1.x kernels and the BBW “default” dtb, but seems P8_20 & P8_21 are now used for something else and my code
always reads them as low which messes everything up. I was expecting an error when I did the export if there was a conflict, but didn’t catch any in my code (assumed the open would fail if there was a problem).

I also tried


with and without cape_universal=enable on the cmdline.
The slot 4: line disappears and a 5: line is added with BB-UART1
but no change, UART1 still works and p8 20&21 are still stuck at low.

Is my lib/firmware and/or kernel out of date, or somehow wrong?

I thought UART1 was supposed to have rts & cts on P9 pins 19 & 20 according the tables in “Exploring Beaglebone” book with apparently no UART1 functions on P8.

Is there an easy fix? I’d prefer to have RTS/CTS available, although the device I’m ordering is supposed to support Xon/Xoff protocol as well.

I’ve been looking at and maybe using config-pin to enable uart1 but my /sys/devices/ paths aren’t matching up very well with the docs so I’m loathe to just stumble around with my very limited knowledge of pinmux and modes.


I just got the answer from Robert Nelson in another thread. The solution is almost too simple, config-pin is the answer.

Just leave the
commented out and let the cape-universal=enable on the cmdline do its thing, and after it boots:

sudo config-pin P9.24 uart
sudo config-pin P9.26 uart

Presto! /dev/ttyS1 works with minicom.

Still an issue if you need rts/cts as these uart1-rts/cts on P9 19 & 20 seem to now be hardwired in the kernel for use by /dev/i2c-2 and are “not-modifyable” with config-pin. If Xon/Xoff works as advertised on the device I’ve ordered, I should be OK without RTS/CTS pins.

The progress being made behind the scenes is amazing, getting the word out about taking advantage of it, not so much.



Thank you for your post. Using the steps you describe above I have finally been able to get all four UARTs working! I will just need to get the config-pin commands into a script that runs at boot and I will have a BBB running Jessie with 4 working serial ports.


I tried using a root crontab @reboot to run a script, but it runs before the cape-universal is set up, so nothing is accomplished. Robert suggested watching in a loop for /sys/devices/platform/bone_capemgr to appear, I’m a little unclear exactly how to do this, so for me it was easier to just launch my script with system() after I finish setting up my gpio via /sys/class/gpio/ file writes and before I start my uart thread.

Something like /bin/sleep 30 at the start of your script might allow the capemgr to come first, it you don’t mind slowing down your startup.


I’m a little unclear exactly how to do this. . .

A loop that checks for a files existence, and if it does not, it keeps looping / checking. You’re also going to want some sort of sleep method in the loop as well. To keep from hammering the CPU. Anyway, this can be done in any number of languages including a bash script.