Where are the serial ttyO1,2,3,4?

Hi all
today I received my first Black one revision A5A.

With my old Beaglebone A6A I was using 2 uart, so the first things I checked out were the serial ports, and:

  • I didn’t find the /dev/ttyOx nodes
  • I saw that there is no mode the pin muxing avaliable from /sys/kernel/debug/omap_mux/…

I have read about the auto muxing based on capes eeprom configuration and stuff like this is it the only way? And if I don’t need the display how can I disable the hdmi drivers?


Same issue here - if anybody has a solution please let us know.



Hi all,
following these two guides I finally managed to enable the serial ports!

The thing is to create a virtual-cape like the one used for the internal emmc or hdmi. Put some overlay configuration for pinmux config, like this:
fragment@0 {

target = <&am33xx_pinmux>;
overlay {
/* pinmux for uart1 /
bone_myuartXX_pins: pinmux_bone_myuartXX_pins {
the uart pin config register offset from the base 0x44e10800 / the mux value /
pinctrl-single,pins = <
0x184 0x00 /
24 UART1_TXD uart1_txd OUTPUT /
0x180 0x20 /
26 UART1_RXD uart1_rxd INPUT */




and some other to change the device node status from the default “disabled” to “okay” and assign the pinctrl:

fragment@1 {

target = <&uart2>;
overlay {
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&bone_myuartXX_pins>;

Since we don’t have a real cape with an eeprom saying hei i am connected so mux that we must also change uEnv.txt like mentioned in this comment: http://hipstercircuits.com/enable-pwm-on-beaglebone-with-device-tree-overlays/#comment-516

However a huge amount of work compared to the old-style pin muxing at runtime available on 3.2 kernel of the original beaglebone.

If someone will find how to manage runtime pinmuxing i will glad to listen to the solution :wink:


Hi Luca,

That sounds great.

Did you only compile the new dts file and move to dto file to appropriate location, or did you move dts to /KERNEL/firmware/capes and rebuild the kernel ?

I tried the first method and kept getting errors with dtc.

I rebuilt the kernel with tools/rebuild.sh and copied everything: zImage and ddbs to fat partition, modules and firmwares to the rootfs. but in the next rebuilds i just copied zImage and the am335x-boneblack.dtb the the fat part.

have fun…


I think I’m getting close - when you finally got it to work - where did the device finally show up? in /dev where /dev/ttyO1 used to be located ?

Hi Tim,
yes it is! You will see it in the boot log like this:
[ 1.830121] bone-capemgr bone_capemgr.9: slot #7: #3 overlays
[ 1.837655] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89) is a OMAP UART1

I don’t know which kind of logic is used to accept or not the pinmux overlay names, but in some cases it could say that it is not able to apply the muxing…


this seems to be a good way to proceed, but I didn’t tried…

I just tried out this approach, especially the quick approach where you simply need to grab a few things from them and I think it worked! Thanks for the link.

Next question might be if I want a 2nd TTL UART, which one should I use? Looks like most of the others are on either on the HDMI stuff or the boot stuff… For the most part I won’t be using the HDMI.


If you don’t need hardware handshaking, just RX and TX, then UART2 and UART4 should be available. UART5 with same is available, but not advised unless you can gate RX during boot since RX is used as one of the boot mode signals.

Keep in mind too - you keep saying TTL UART - these are all 3.3 V signals. You will need a level shifter of some sort before you connect these to anything > 3.3 VDC.


The two devices I was thinking of connecting up are:
XBee which is 3.3v

And potentially a Roboclaw (Motor controller), which as I understand it from the people who make them (Basic Micro/Orion Robotics), they are also 3.3v devices which are 5v tolerant

However I may also play on the safe side and use one of the Sparkfun Level Converters, I have, and plug it into the prototype Cape (breadboard.), May try USART2… Will need to figure out the addresses. and the like. Also not sure but my guess is that I should do this as separate overlay as to make them both independent to install.


Would you be interested in an Xbee cape? I’m considering making these to make life simpler for people running my stuff,

Not sure about my plans yet. May have some fun and maybe design and build my own cape, that has on it what I want…

Note: I mentioned the newer instructions work. They do to a point, but so far I have to do the echo… >$SLOTS on each boot.
I remember a note on this, about needing to edit the /boot/uEnv.txt file… Need to experiment some more to figure out what needs to go in this file.


I forgot to mention that in the post. The echo > $SLOTS is not persistent across reboots. A quick fix would be to put that command into an init script that gets executed at boot. I think the proper thing to do would be to do the pin mux setting in the am335x-boneblack.dtb file so it happens at boot. I haven’t tried that part out yet. It should be possible to put the pin settings in the am33xx_pinmux section in am335x-bone-common.dtsi.


The link SKiAt provided to Pignology News: Getting UART2 (/dev/ttyO1) Working on BeagleBone Black worked really well. After some messing around with it, I was able to enable the UARTs without needing to recompile am335x-boneblack.dtb. The second fragment in the uart2pinmux.dts file from Pignology can be changed to overlay the <&uart2> object instead of creating the test_helper. This is how SKiAt mentioned the changes above:

fragment@1 {

target = <&uart2>;
overlay {
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&uart2pinmux>;

If you do this, the slots won’t unload, but this shouldn’t be a concern for most people. If for some reason you need to unload and reload the UART slots, stick with the test_helper method described by Pignology; however, you’ll need to remove the “:helper” in the second fragment. With this left in, only the first UART added to the slots will be active.

Like Nick mentioned, the echo > $SLOTS commands are not persistent. Compiling the pinmux commands into the am335x-boneblack.dtb will make them persist after boot.

Also, to save some people time digging through thousands of pages of datasheets, here are the pin offset and mux values for the other UARTs:

uart3:serial@48024000 (/dev/ttyO2)
TX: 0x154 0x01
RX: 0x150 0x21

uart4:serial@481a6000 (/dev/ttyO3)
TX: 0x164 0x01
RX: N/A (not broken out to P8 or P9)

uart5:serial@281a8000 (/dev/ttyO4)
TX: 0x074 0x06
RX: 0x070 0x26

uart6:serial@481aa000 (/dev/ttyO5)
TX: 0x0C0 0x04
RX: 0x0C4 0x24
Note: these pins are used by the HDMI on the BBB. dmesg will show errors that the pins are in use, but the module will still be placed into a slot. I don’t use the HDMI so I tried to remove the slot (echo -5 > $SLOTS), but the BBB didn’t like that (ssh session closed and had to power cycle to reconnect).


Thanks, that looks really good.

I will update mine to match as well.


Thank you for gathering that information, Michael.

There’s a section in am335x-bone-common.dtsi that sets up the HDMI; it’s in the bone_capemgr section. They’re forcing it to load some firmware since it’s soldered on. On a side note, it appears this is the way (cape-override) to load custom cape firmware that doesn’t have an EEPROM for cape identification, like the Geiger Cape.

slot@101 {
priority = <1>;
compatible = “ti,beaglebone-black”;
board-name = “Bone-Black-HDMI”;
version = “00A0”;
manufacturer = “Texas Instruments”;
part-number = “BB-BONELT-HDMI”;

This can be commented out to keep the HDMI pins from being claimed and UART6 pins can be set to the correct mode without error.

I’ve managed to get all UARTs (except UART4/ttyO3) enabled and pin mux modes set correctly from within am335x-bone-common.dtsi. Going this route will set pin mux modes correctly upon boot. This also disables HDMI to get UART6 to work so use with caution if you’re using HDMI.

The updated files to build /boot/am335x-boneblack.dtb are here:

If you need HDMI, uncomment the slot@101 section and set uart6 to status = “disabled”;.



Tried to follow this and compile a dtb to give me access to the uarts but the dtc command throws an error over the ‘-@’ option and so I can’t follow any of the examples out there nor can I find any indication of what ‘-@’ means. I’m using Arch and puled the dtc package from their repository. If i omit ‘-@’ then it produces the .dtb file but it’s several K smaller than the exiting one and I have not the foggiest idea what I am omitting in doing that.

Thanks for the examples. I’m hoping to enjoy this more once I’m past stubbing my toes in the dark everywhere.

Well, whatever ‘-@’ is it doesn’t appear to be all that important!

Dec 31 18:18:22 robo-2 kernel: [ 0.490195] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
Dec 31 18:18:22 robo-2 kernel: [ 0.502437] console [ttyO0] enabled
Dec 31 18:18:22 robo-2 kernel: [ 0.503495] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89) is a OMAP UART1
Dec 31 18:18:22 robo-2 kernel: [ 0.504471] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90) is a OMAP UART2
Dec 31 18:18:22 robo-2 kernel: [ 0.505482] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a OMAP UART4
Dec 31 18:18:22 robo-2 kernel: [ 0.506424] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 62) is a OMAP UART5