BBB Debian Jessie: Enabling all serial ports (incl. ttyO5)

I am using RCN’s image-builder to build jessie images for the BBB (was previously using Wheezy). So far so good, I now need to create a custom dtb to enable ttyO1,ttyO2,ttyO4 and ttyO5. I cloned RCN’s dtb-rebuilder and created a .dts with the following contents:


#include “am33xx.dtsi”
#include “am335x-bone-common.dtsi”
#include “am335x-bone-common-pinmux.dtsi”

/ {
model = “TI AM335x BeagleBone Black”;
compatible = “ti,am335x-bone-black”, “ti,am335x-bone”, “ti,am33xx”;

&ldo3_reg {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;

&ocp {
/* clkout2 /
P9_41_pinmux {
status = “disabled”;
mmc1 */
P9_92_pinmux {
status = “disabled”;

&mmc1 {
vmmc-supply = <&vmmcsd_fixed>;

&am33xx_pinmux {
pinctrl-names = “default”;
pinctrl-0 = <&clkout2_pin>;

#include “am335x-boneblack-emmc.dtsi”
#include “am335x-bone-i2c2-cape-eeprom.dtsi”

#include “am335x-bone-ttyO1.dtsi”
#include “am335x-bone-ttyO2.dtsi”
#include “am335x-bone-ttyO4.dtsi”
#include “am335x-bone-ttyO5.dtsi”


However, it seems that while ttyO1, ttyO2 and ttyO4 appear (although the device numbering is off as I see ttyO0-ttyO3 in /dev), I’m not seeing ttyO5 appear. dmesg shows:

[ 2.613986] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 2.616773] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 88, base_baud = 3000000) is a 8250
[ 2.634561] console [ttyS0] enabled
[ 2.635559] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 89, base_baud = 3000000) is a 8250
[ 2.636413] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 90, base_baud = 3000000) is a 8250
[ 2.637193] 481a8000.serial: ttyS3 at MMIO 0x481a8000 (irq = 61, base_baud = 3000000) is a 8250
[ 2.637737] omap8250 481aa000.serial: unable to register 8250 port
[ 2.644177] omap8250: probe of 481aa000.serial failed with error -28

So it looks like the old “HDMI needs to be disabled” error, except that with there’s no capemgr in 3.14 loading BB-HDMI and I’m NOT including any of the am335x-hdmi .dts[i] files. I think this should work as is. Not sure what error -28 is (28 is ENOSPC in errno.h?).

Any ideas on why ttyO5 is not coming up?



I've been seeing that locally too, but i see the issue...


So... yeah.. next kernel build.... :wink:


Ah! So r55 then?

Hi Robert,

I would too greatly appreciate having a jessie image with all the chip
UARTs enabled (at least a basic version with no RTS/CTS handshake

I tried the included ADAFRUIT UART4 overlay but it didn't work with my
Logic Supply CBB-TTL-232 (which I painfully configured for UART4 to
avoid a clash with getty obsession with UART0).

Logic Supply will not release an updated DTO for their CBB-TTL-232... I
should not have bought any of their capes :frowning:

TIA, Regards, Enoch. writes:

One other thing I noticed, I see entries in dmesg output like this:

[ 2.656184] bone-pinmux-helper P8_37_pinmux.28: Set initial pinmux mode to uart
[ 2.656791] bone-pinmux-helper P8_38_pinmux.29: Set initial pinmux mode to uart


In fact, I see it for the ttyO1, ttyO2, ttyO4 and ttyO5 TXD and RXD pins. However, I want to enable hardware flow control (CTS/RTS) for ttyO4 and ttyO5, so I have added the following lines to my custom .dts file:

P8_33_pinmux {
mode = “uart”;
P8_35_pinmux {
mode = “uart”;

P8_31_pinmux {
mode = “uart”;
P8_32_pinmux {
mode = “uart”;


But I don’t see corresponding entries in dmsg showing the bone-pinmux-helper settings the uart modes for 3 of these extra pins (it did actually set the uart mode for P8_31). A bit of digging in am335x-bone-common-pinmux.dtsi shows that it’s missing the pinctrl modes for P8_32, P8_33 and P8_35, along with the uart pinmux definitions for P8_33 and P8_35. So I added them and I now see bone-pinmux-helper property configuring these pins. Here’s the diff for am335x-bone-common-pinmux.dtsi:

Next up, I need to get or build a kernel with 5 serial ports enabled to test this.


am335x-bone-common-pinmux.dtsi.patch (2.69 KB)

The pinctrl values I use for P8_33 and P8_35 are:

  0xd0 0x36 /* P8_35, uart4_ctsn - in | pullup | mode 6 */
  0xd4 0x1e /* P8_33, uart4_rtsn - out | pull dis | mode 6 */

(similarly for uart5 pins P8_31 and P8_32)

CTS is active low, so you want the pin to pullup when not driven. Otherwise,
the remote sees CTS enabled when you don't have the port open, and will not
stop sending.

RTS is active low as well, so you either want the pullup/down disabled or
pulled up.

Peter Hurley