UART1 using BB-UART1 vs cape-universal

I have a sensor hooked up to UART1. This seems to work just fine using cape-universal and config-pin to setup P9-24 and P9-26 in uart mode.

When I modify uEnv.txt to use BB-UART1 overlay, I am unable to read data from the sensor.

Relevant portions of uEnv.txt looks like this:

Don’t enable cape-universal

cmdline=coherent_pool=1M quiet

Enable UART1 and I2C1 overlays


And I have commented out the original cmdline:

#cmdline=coherent_pool=1M quiet cape_universal=enable

Slots look like this:

0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-I2C1
5: P-O-L- 1 Override Board Name,00A0,Override Manuf,BB-UART1

Kernel and rootfs:

debian@bbb2:~$ uname -r
debian@bbb2:~$ cat /etc/dogtag Debian Image 2016-01-17

I have also pulled the latest and run

I have this working on another system with 4.1.13-ti-r35 with the 2015-11-09 rootfs. If I am correct in analyzing the BB-UART1 dtb that is working on this system, it appears as if P9_24 is configured with a pulldown resistor and P9_26 is configured with a pullup resistor. The BB-UART1 dtb on the system where this is not work (and the current version from has no pullup/pulldown resistors configured for those pins. Looking at cape-universal (that works), it appears as if P9_24 and P9_26 are both configured with pullups.

So, I’m assuming that this is why my current BB-UART1 setup is not working.

Is the configuration of the current BB-UART1 (actually all of them) without pullup/pulldown for UART mode by design? If so, why? And of course, the converse question for cape-universal.

Not being a H/W guy, maybe someone can inform me as to why my current BB-UART1 doesn’t work and why these dtb’s are thusly configured.


Sorry, just fixed this today, my edma fix for spi/mcasp, broke usart1/2..

cd /opt/scripts/tools/
git pull
sudo ./ --ti-rt-channel --lts-4_1

BB-UART1 & BB-UART2 will work again...


OK, thanks Robert. I'll try an updated kernel and see what happens. Curious, what was the issue and why didn't it manifest itself with the different settings in cape-universal?

Still interested in why the pull-up/pull-down values are different in cape-universal vs BB-UART.


OK, thanks Robert. I’ll try an updated kernel and see what happens.

Issue fixed on 4.1.17-ti-rt-r46. Thanks!

Interesting. Was it just a matter of removing the references &uart0,
&uart1, and &uart2 from am33xx-overlay-edma-fix.dtsi ?

Yeah that's the change..

So spi/mcasp can be defined and then we can change the pin in the
overlay and everything works. (remember this a bug for dma, as without
it both spi/mcasp end up in pio mode..)

While the usarts, once the node is defined we can't change the pinmux
with the overlay..

But we could change it with cape-universal.. (odd)

Well we have the dma disabled for serial anyways, so we really didn't
need it in the edma overlay fix..