Serial port on Beaglebone



Can someone explain how to get the serial ports to work on a beaglebone with the nodeJS resinOS image? I figure the solution is to add something to my Dockerfile. What is it?

My confusion is below:
I have no problems doing this on a beaglebone without resin.os.
There seems to be 2 methods of doing this for a beaglebone: writing to uEnv.txt, or echo BB-UART4 > /sys/devices/platform/bone_capemgr/slots

They don’t work inside the container. COPYing a uEnv.txt into the container (in the dockerfile), does nothing (there is no uEnv.txt in the filesystem anyway), and the result of running the following inside the container: echo BB-UART4 > /sys/devices/platform/bone_capemgr/slots is echo: write error: File exists.

What am I missing here?
Thanks a lot.


More info following, trying to explain, may not make any sense.

echo BB-UART4 > /sys/devices/platform/bone_capemgr/slots

I get the error “echo: write error: file exists” for all UARTS except UART 3. That makes me believe the uEnv.txt file has been processed.

After a “cat slots” inside /sys/devices/platform/bone_capemgr , I saw 6 slots.
I did a “echo -6 slots” , to remove the 6th slot, which worked.

But a subsequent echo BB-UART4 > /sys/devices/platform/bone_capemgr/slots gave me the same write error: file exists.

I still don’t see a ttyO4 or ttyO* inside /dev

Also, I tried using the beaglebone-python image as well as the -node image, same thing.

Any tips?
Thanks a lot.


Hi, we are checking this out. Can you tell us what resinOS version are you running on the device?


v2.0.0+rev4 is that what you mean?


Yes, that’s the one, thanks!


Try ttyS4 instead of ttyO4.

With your cat slots did it show an overlay for BB-UART4?


Hi, I was checking it out, and found the following:

The first time I run echo BB-UART4 > /sys/devices/platform/bone_capemgr/slots, it succeeds fine and triggers capemgr. If I re-running the command after that, I’ll get a echo: write error: file exists, which indeed shows that the settings are already applied, no need again (until next boot).

I could see the results in the kernel messages using dmesg, here are the relevant lines:

[  223.795986] bone_capemgr bone_capemgr: part_number 'BB-UART4', version 'N/A'
[  223.805436] bone_capemgr bone_capemgr: slot #4: override
[  223.820155] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[  223.831940] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-UART4'
[  223.861614] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 199, base_baud = 3000000) is a 8250
[  223.919764] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-UART4-00A0.dtbo' loaded; overlay id #0

Shows that indeed as @fenris says, you need to connect to ttyS4. Tried it out to communicate over an USB-Serial line, and works.

So I’m guessing you need to run that echo ... command or something equivalent in your start script. If the error is file exists, then you can just continue with your code, everything is already set up earlier (would happen eg. if you restart the container, but not the whole device).
What do you think?


Thanks a lot! That helps.

I must have screwed something up but I don’t know what. I get a similar output with dmesg -T, except the following line from your output is missing from mine:
[ 223.861614] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 199, base_baud = 3000000) is a 8250

However, if I look in the past of the dmesg logs, I do get that line of output. I am seeing the UARTs when I do a cat slots. I got that to work by removing the universal cape, which was conflicting with the UARTs.

Anyway I’m going to take the easy next step and reflash my beaglebone with a fresh OS, then I believe it should work.


Perfect! Works.
As indicated in the dmesg logs, the path to the serial port is /dev/ttyS* .
Did the same test, put a FTDI into the beaglebone’s USB port and connected to BB serial port. Now I know the ttyUSB0 works too!

Here’s more info in case that helps in the future:
I used the same SD card to reflash the Beaglebone onboard flash. I also used the same application.

Therefore I believe the problem was introduced in one of my past commits, and didn’t go away with later commits. But as I said above, a fresh install with the same latest commit works fine.
I did swap back and forth to the simple-server-node and the adc-node app (check spelling) using git push -f. I think maybe possibly running the adc app at one time messed things up.