UART1 using BB-UART1 vs cape-universal

GoogleGroups
1

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

cape_enable=bone_capemgr.enable_partno=BB-I2C1,BB-UART1

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
4.1.16-ti-rt-r44
debian@bbb2:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2016-01-17

I have also pulled the latest bb.org-overlays and run install.sh.

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 bb.org-overlays) 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.

ba

2

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

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

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

Regards,

3

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.

ba

4

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

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

5

Interesting. Was it just a matter of removing the references &uart0,
&uart1, and &uart2 from am33xx-overlay-edma-fix.dtsi ?
https://github.com/RobertCNelson/linux-dev/commit/cba0713acc8220039c3c5ee646c592af8d532515

6

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..

Regards,