Failed to enable UART1, Ubuntu 16.04

I installed Ubuntu 16.04 to my BeagleBone Black and tried to enable UART1, but it seems to not works.

Content of /etc/default/capemgr:

`

Default settings for capemgr. This file is sourced by /bin/sh from

/etc/init.d/capemgr.sh

Options to pass to capemgr

CAPE=BB-UART1,BB-PWM1
`

Content of /sys/devices/platform/bone_capemgr/slots:

0: ---l-- -1 1: ------ -1 2: ---l-- -1 3: ---l-- -1 4: --O--- -1

Log related to BB-UART1 cape:

$ journalctl
Jul 17 16:15:00 beaglebone-glass sh[612]: generic-board-startup: [model=TI_AM335x_BeagleBone_Black]
Jul 17 16:15:00 beaglebone-glass sh[612]: generic-board-startup: [startup script=/opt/scripts/boot/am335x_evm.sh]
Jul 17 16:15:00 beaglebone-glass kernel: bone_capemgr bone_capemgr: part_number ‘BB-UART1’, version ‘N/A’
Jul 17 16:15:00 beaglebone-glass kernel: bone_capemgr bone_capemgr: slot #4: override
Jul 17 16:15:00 beaglebone-glass kernel: bone_capemgr bone_capemgr: slot #4: auto loading handled by U-Boot
Jul 17 16:15:00 beaglebone-glass cron[676]: (CRON) INFO (pidfile fd = 3)
Jul 17 16:15:00 beaglebone-glass systemd[1]: Starting System Logging Service…
Jul 17 16:15:01 beaglebone-glass systemd[1]: Started D-Bus System Message Bus.

Linux info:

$ uname -a
Linux beaglebone-glass 4.4.62-ti-r104 #1 SMP Thu May 18 18:00:40 UTC 2017 armv7l armv7l armv7l GNU/Linux

$ cat /etc/dogtag
rcn-ee.net console Ubuntu Image 2017-05-21

How to fix it?
Thanks

That image uses u-boot overlays:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

in /boot/uEnv.txt set:

uboot_overlay_addr4=/lib/firmware/BB-UART1-00A0.dtbo
uboot_overlay_addr5=/lib/firmware/BB-PWM1-00A0.dtbo

Regards,

Hi Robert

That /boot/uEnv.txt still doesn’t work.

Here is my content:

###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1

With u-boot overlays, just ignore the slots and kernel messages..

Did you try using, /dev/ttyS1 ?

It should be active.

Regards,

As Robert says, do you see ttyS1 in your /dev directory?
if so, what mode are the pins on p9_24 & p9_26 (config-pin -q 926;config-pin -q 924 )?

`

javalens@beaglebone:/dev$ config-pin -q 926;config-pin -q 924
P9_26 Mode: default Direction: in Value: 0
P9_24 Mode: default Direction: in Value: 1

`

is so try:
sudo config-pin 924 uart; sudo config-pin 926 uart

`

javalens@beaglebone:/dev$ sudo config-pin 924 uart; sudo config-pin 926 uart

[sudo] password for javalens:
javalens@beaglebone:/dev$ config-pin -q 926;config-pin -q 924
P9_26 Mode: uart
P9_24 Mode: uart

`

Regards,

Great, thank you. It works.

/dev/ttyS1 still appears before I configure cape_mgr, but it doesn’t work, cannot get data from serial.

Now, I can see data flowing in /dev/ttyS1.

Btw, the config-pin command doesn’t work on my system:

`

$ config-pin -q 924
P9_24 pinmux file not found!
Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P9_24_pinmux/state
`

However:

$ ls /sys/devices/platform/ocp/48022000.serial/tty/ ttyS1

Out of the box, we try to make this device as dynamic as possible..

So config-pin would have worked originally.

But once you enabled the BB-UART1-00A0.dtbo overlay in u-boot,
config-pin will be disabled.

Regards,

Thanks Robert, you saved my day.
I lost a couple of days with UART not working after upgrading to Debian 9.
Finally after having a look at the posts in the mailing list I found this and figured out ‘cape_enable=bone_capemgr.enable_partno=BB-UART1’ is not enough anymore.
It is perhaps worthed to include an entry in the wiki with specific information on this change and how to enable the UART, as not all of us who work with overlays have a full understanding on how they work and interact with uboot.

Thanks a log again! :slight_smile:

El dilluns, 17 juliol de 2017 20:01:24 UTC+2, RobertCNelson va escriure:

Glad I saw this post! I was able to enable UART1 and confirm that the BBB talks to the UART on my host PC using config-pin 924/926 uart.

However, I’m still having an issue with enabling UART1 or UART3 via u-boot overlays in uEnv.txt on the BBB. I’m new to u-boot overlays.

When the following line(s) are added to uEnv.txt, and I reboot, the systemd gods get angry and won’t grant me a Debian login prompt.
Note: I only have tried one UART overlay at a time.

uboot_overlay_addr3=/lib/firmware/BB-UART1-00A0.dtbo

OR

uboot_overlay_addr3=/lib/firmware/BB-UART3-00A0.dtbo

.
.
.

[ 29.881903] random: nonblocking pool is initialized

[ *** ] A start job is running for LSB: con…ial ports (14min 37s / no limit)

It looks like UART1,2,4 are already enabled in the Debian 8.9, BBB console image I have (details about the version of u-boot, SPL, kernel, and debian at the end).

debian@beaglebone:~$ setserial -g /dev/ttyS[0-5]
/dev/ttyS0, UART: 8250, Port: 0x0000, IRQ: 158
/dev/ttyS1, UART: 8250, Port: 0x0000, IRQ: 159
/dev/ttyS2, UART: 8250, Port: 0x0000, IRQ: 160
/dev/ttyS3, UART: unknown, Port: 0x0000, IRQ: 0
/dev/ttyS4, UART: 8250, Port: 0x0000, IRQ: 161
/dev/ttyS5, UART: unknown, Port: 0x0000, IRQ: 0

I’m not sure why the serial systemd startup is getting stuck, and I tried doing a cursory look at journalctl on the next bootup (after commenting the UART overlay lines in uEnv.txt) to see if the systemd history persisted what may have happened, but I didn’t see that.

Right now, I have some guesses at what may be going on:

1)Since UART1 is already enabled, there was a resource contention when the UART1 u-boot overlay was loaded.
2)When u-boot attempted to load the UART3 overlay, there may have been a resource contention between something existing in the active device tree and the DTBO for UART3.

??Do you get the same kind of error messages with u-boot overlays when there’s a device tree resource contention that you get with the cape manager and kernel overlays??

I also tried commenting these back in, in uEnv.txt, but this didn’t make systemd happy.

disable_uboot_overlay_emmc=1

#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1

I also tried renaming /boot/initrd.img-4.x to back.initrd.img-4.x per the thread which was posted today, but apparently that wasn’t the issue…