UART1 (/dev/ttyO0) on Beagleboard-xM

GoogleGroups
1

Ok so I was able to mux the pins correctly in the Linux kernel for UART2 (/dev/ttyO1) and get all 4 I/O lines working (TX,RX,CTS,RTS). Now I need to do the same thing for UART1 (/dev/ttyO0), but that port isn’t working as easily as UART2 did, and I suspect it has something to do with the digital video lines (DSS_DATA*).

My Linux distribution is Ubuntu, and my baseline kernel is the RCN-EE kernel.

Basically my pin muxing is as follows for UART1 (/dev/ttyO0):
OMAP3_MUX(DSS_DATA7,OMAP_MUX_MODE2 | OMAP_PIN_INPUT), /* uart1_rx /
OMAP3_MUX(DSS_DATA6,OMAP_MUX_MODE2 | OMAP_PIN_OUTPUT), / uart1_tx /
OMAP3_MUX(DSS_DATA0,OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP), / uart1_cts /
OMAP3_MUX(DSS_DATA1,OMAP_MUX_MODE2 | OMAP_PIN_OUTPUT), / uart1_rts */

The above is the code I inserted into the omap_board_mux[] array in board-omap3beagle.c. As you can see, the UART1 pins a muxed with the DSS_DATA* pins for the digital video controller. I know the pins are getting muxed because I can do this:

cd /sys/kernel/debug/omap_mux

cat dss_data7 dss_data6 dss_data0 dss_data1

name: dss_data7.uart1_rx (0x480020ea/0x0ba = 0x0102), b f28, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE2
signals: dss_data7 | NA | uart1_rx | NA | gpio_77 | NA | NA | safe_mode
name: dss_data6.uart1_tx (0x480020e8/0x0b8 = 0x0002), b e26, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE2
signals: dss_data6 | NA | uart1_tx | NA | gpio_76 | NA | NA | safe_mode
name: dss_data0.uart1_cts (0x480020dc/0x0ac = 0x011a), b ag22, t NA
mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE2
signals: dss_data0 | NA | uart1_cts | NA | gpio_70 | NA | NA | safe_mode
name: dss_data1.uart1_rts (0x480020de/0x0ae = 0x0002), b ah22, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE2
signals: dss_data1 | NA | uart1_rts | NA | gpio_71 | NA | NA | safe_mode
The above output from the /sys area shows the 4 pins for UART1 being in the correct mux mode, which is mux mode 2.

So UART1 (/dev/ttyO0) should work from Linux right? It doesn’t (UART2 continues to work correctly though). The only pin that works on UART1 is the TX transmitter pin. I can write data to the /dev/ttyO0 port and see it on the DSO for the TX pin. However, when I set RTS on /dev/ttyO0 from Linux, nothing happens on the DSO for the RTS pin. When I short CTS to ground, I don’t see a change when reading the status of CTS for /dev/ttyO0 in Linux. When I short TX to RX to form a loopback, and then transmit data, I see video signals (DSS_DATA) on the DSO. This suggests that the HDMI video is overriding my mux settings somewhere, because sometimes I see video signaling on my pins.

All of this works fine with my muxing for UART2 (/dev/ttyO1).

Is there a way to disable the HDMI video in the Linux kernel, so it doesn’t try to use my UART1 pins? Should I need to disable the video?

What’s really stange is that when I boot my kernel with the above pin muxing, the HDMI video output connect on the BB-xM still works with my computer monitor (I would expect it not to work at all). Stranger, the video always has a background color of “blue”. Without the pin muxing, the background color of the video is “black”, as expected.

So something strange is going on… Can anyone offer help on disabling the video in the Linux kernel?

Thanks in advance,
-Eric

2

Ok so I was able to mux the pins correctly in the Linux kernel for UART2
(/dev/ttyO1) and get all 4 I/O lines working (TX,RX,CTS,RTS). Now I
need to do the same thing for UART1 (/dev/ttyO0), but that port isn't
working as easily as UART2 did, and I suspect it has something to do
with the digital video lines (DSS_DATA*).

My Linux distribution is Ubuntu, and my baseline kernel is the RCN-EE
kernel.

Basically my pin muxing is as follows for UART1 (/dev/ttyO0):
        OMAP3_MUX(DSS_DATA7,OMAP_MUX_MODE2 | OMAP_PIN_INPUT), /*
uart1_rx */
        OMAP3_MUX(DSS_DATA6,OMAP_MUX_MODE2 | OMAP_PIN_OUTPUT), /*
uart1_tx */
        OMAP3_MUX(DSS_DATA0,OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP), /*
uart1_cts */
        OMAP3_MUX(DSS_DATA1,OMAP_MUX_MODE2 | OMAP_PIN_OUTPUT), /*
uart1_rts */

The above is the code I inserted into the omap_board_mux array in
board-omap3beagle.c. As you can see, the UART1 pins a muxed with the
DSS_DATA* pins for the digital video controller. I know the pins are
getting muxed because I can do this:
# cd /sys/kernel/debug/omap_mux
# cat dss_data7 dss_data6 dss_data0 dss_data1
name: dss_data7.uart1_rx (0x480020ea/0x0ba = 0x0102), b f28, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE2
signals: dss_data7 | NA | uart1_rx | NA | gpio_77 | NA | NA | safe_mode
name: dss_data6.uart1_tx (0x480020e8/0x0b8 = 0x0002), b e26, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE2
signals: dss_data6 | NA | uart1_tx | NA | gpio_76 | NA | NA | safe_mode
name: dss_data0.uart1_cts (0x480020dc/0x0ac = 0x011a), b ag22, t NA
mode: OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE2
signals: dss_data0 | NA | uart1_cts | NA | gpio_70 | NA | NA | safe_mode
name: dss_data1.uart1_rts (0x480020de/0x0ae = 0x0002), b ah22, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE2
signals: dss_data1 | NA | uart1_rts | NA | gpio_71 | NA | NA | safe_mode
The above output from the /sys area shows the 4 pins for UART1 being in
the correct mux mode, which is mux mode 2.

So UART1 (/dev/ttyO0) should work from Linux right? It doesn't (UART2
continues to work correctly though). The only pin that works on UART1
is the TX transmitter pin. I can write data to the /dev/ttyO0 port and
see it on the DSO for the TX pin. However, when I set RTS on /dev/ttyO0
from Linux, nothing happens on the DSO for the RTS pin. When I short
CTS to ground, I don't see a change when reading the status of CTS for
/dev/ttyO0 in Linux. When I short TX to RX to form a loopback, and then
transmit data, I see video signals (DSS_DATA) on the DSO. This suggests
that the HDMI video is overriding my mux settings somewhere, because
sometimes I see video signaling on my pins.

All of this works fine with my muxing for UART2 (/dev/ttyO1).

Is there a way to disable the HDMI video in the Linux kernel, so it
doesn't try to use my UART1 pins? Should I need to disable the video?

What's really stange is that when I boot my kernel with the above pin
muxing, the HDMI video output connect on the BB-xM still works with my
computer monitor (I would expect it not to work at all). Stranger, the
video always has a background color of "blue". Without the pin muxing,
the background color of the video is "black", as expected.

So something strange is going on... Can anyone offer help on disabling
the video in the Linux kernel?

You can disable it using,

# echo 4 > /sys/class/graphics/fb0/blank

OR

# echo 0 > /sys/devices/platform/omapdss/display0/enabled

NOTE: I am not in front of board, so written command by-hand. Search for
names in sysfs.

Thanks,
Vaibhav

3

Thanks for the suggestion, but I was not able to make use of it.

find /sys/class -print | grep -i graphics

(produces no results)

find /sys/devices -print | grep -i dss

(produces no results)
So I’m not sure what you were trying to access, but I can’t find anything resembling your /sys paths.

4

I ended up just removing all the DSS stuff from the kernel using the configuration. Basically did a “make menuconfig” and took out all the DSS stuff and rebuilt the kernel from scratch. However, my RX, RTS, and CTS lines still do not work on UART1 (/dev/ttyO0). The TX line does work correctly.

Since UART2 (/dev/ttyO1) works, I don’t think there is a bug in the OMAP serial kernel driver. The only difference between UART1 and UART2 is that they use different pins on the expansion headers and they require different pin muxing.

I am certain the pin muxing is set according to the documentation, because I am able to mux all 4 UART2 pins and I am able to MUX the TX pin of UART1. So I know I am muxing the pins correctly. I have checked the pin muxing for the remaining 3 pins about a dozen times, and it is set per the documentation in the BB-xM design reference guide. For UART1 (/dev/ttyO0):
Header/Pin MUX-Mode-0 MUX-Mode-2 MUX-Mode-4

P11-pin#3 DVI_DATA1 UART1_RTS GPIO-71
P11-pin#4 DVI_DATA0 UART1_CTS GPIO-70
P13-pin#9 DVI_DATA7 UART1_RX GPIO-77
P13-pin#15 DVI_DATA6 UART1_TX GPIO-76

So all the UART1 pins are supposed to be available by MUX mode 2 for various DVI_DATA processor pins. How can it be that UART1 TX functions correctly, but the other 3 pins fail to function correctly?

I believe there is either an error in the BB-xM documentation or bug in the silicon. There has to be. I’ve spent weeks on these UARTs (I already had to fix a bug in the kernel driver to get UART2 working).

Could someone advise where I can go to try to report a bug to TI in the BB-xM documentation, so I can get a TI engineer to actually look at this? I’m basically convinced at this point that IF the silicon really does have a set of working UART1 TX, CTS, RTS pins, then they’re definitely NOT at P13-pin#15, P11-pin#4, P11-pin#3 respectively in MUX mode 2. If they exist, then they must be somewhere else, but finding them by trial and error is not really a good option. I would like to have a TI engineer look into this? Is there someone I can contact?

I’ve spent an incredible amount of time on this, and clearly something is broken.
Thanks for any suggestions.
-Eric

5

So I wrote a bit of code to read the pin mux registers from the DM3760 chip. Using the “sprugn4o.pdf” reference manual for the BB-xM processor (DM3760), you can look up in table 13-4 (on page 2460) to find the pin mux configuration registers. Each pin of the DM3760 uses a 16-bit register to configure the pin mux for a single pin. I wrote the following program:

`

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/mman.h>

static const char *bitbuf16(unsigned short value,char *buf);

int main(int argc,char argv[])
{
char bbuf[100];
int fd = open("/dev/mem", O_RDWR | O_SYNC);
if (fd<0) return 1;
/ Pad configuration */
volatile ulong pinconf;
pinconf = (ulong) mmap(NULL, 0x10000,
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x48000000);
if (pinconf == MAP_FAILED) {
close(fd);
return 1;
}
printf(“UART2-CTS 0x48002174[15:00] = 0b%s\n”,bitbuf16(pinconf[0x2174/4] & 0xffff,bbuf));
printf(“UART2-RTS 0x48002174[31:16] = 0b%s\n”,bitbuf16(pinconf[0x2174/4] >> 16,bbuf));
printf(“UART2-TXD 0x48002178[15:00] = 0b%s\n”,bitbuf16(pinconf[0x2178/4] & 0xffff,bbuf));
printf(“UART2-RXD 0x48002170[31:16] = 0b%s\n”,bitbuf16(pinconf[0x2170/4] >> 16,bbuf));
printf("\n");
printf(“UART1-CTS 0x480020DC[15:00] = 0b%s\n”,bitbuf16(pinconf[0x20DC/4] & 0xffff,bbuf));
printf(“UART1-RTS 0x480020DC[31:16] = 0b%s\n”,bitbuf16(pinconf[0x20DC/4] >> 16,bbuf));
printf(“UART1-TXD 0x480020E8[15:00] = 0b%s\n”,bitbuf16(pinconf[0x20E8/4] & 0xffff,bbuf));
printf(“UART1-RXD 0x480020E8[31:16] = 0b%s\n”,bitbuf16(pinconf[0x20E8/4] >> 16,bbuf));
close(fd);
return 0;
}

static const char *bitbuf16(unsigned short value,char buf)
{
int n;
for (n=0; n<16; n++) buf[n] = ‘0’+((value>>(15-n)) & 0x01);
buf[16] = ‘\0’;
return buf;
} / bitbuf */

6

So the problem with UART1 (/dev/ttyO0) is “solved”, but not really a solution.

There is a note in the beagleboard-Xm system reference manual on page 89 (figure 44) that describes how DSS_DATA0 - DSS_DATA5 were “moved” to accomodate 720p resolution on the DVI video. Well, DSS_DATA0 and DSS_DATA1 happen to be the pins where the UART1 RTS and CTS signals are muxed. So UART1 simply doesn’t have the RTS and CTS pins available on any external header any more, now that they’ve been moved. This means our beagleboard project is now dead since we require these pins.

I did manage to find the missing CTS and RTS pins on the unpopulated RP1 (resistor pack 1), so theoretically I could follow the instructions on page 89 of the SRM and move RP2 chip to RP1 (and also move RP7 to RP5) to go back to “legacy mode”. This really isn’t an option for us, since we need to be able to manufacture these units by the hundreds, and reworking tiny surface mount RPs on each beagleboard won’t be cost-effective. Perhaps the beagle bone is a better option for us since it seems to have more serial ports populated on its expansion headers.

It’s rather unfortunate that in every area of BB-xM documentation, it shows DSS_DATA0 and DSS_DATA1 on the P11 expansion headers, with the exclusive single exception of the one paragraph of text on page 89 of the SRM (under the section header “DVI-D interface”). The expansion header pin tables (page 121 table 33, and page 111 table 24, and page 95 table 16) are quite misleading and I would recommend that they be fixed to reflect the fact that a bunch of pins were moved. I wasted about a month of engineering only to end up dead in the water because of this. I suppose it’s my fault for not having read every word of the BB-xM SRM from start to finish before beginning, but I guess that’s why they say there is “no warranty” with any BB-xM design materials.

Oh well…
-Eric

7

Hi Eric,

I’ve looking or a way to enable RX/TX/RTS/CTS pins for UART2 (I am usin pin muxing instead). It seems that you did it (I assume using u boot) by fixing a kernel dirver. Could you share the bug please?

I ended up trying to activate UART1 but after reading your post I really think this is a dead end.