Project

General

Profile

RS232 UART Needed

Added by Jeff Benshetler over 11 years ago

For my immediate project, I need:
1) an RS-232 TTL-level input with RX, TX and an edge-triggered interrupt on DCD;
2) a GPIO line for output
3) it would be preferable if the RS232 lines could come out of an existing connector, e.g. J504.
4) After verifying functionality in the ARM, the edge-triggered interrupt on DCD needs to trigger an interrupt handler in the C6000.

I'm trying to setup J504 UART2 as RS232 rather RS485, following the information from
[[http://support.criticallink.com/redmine/boards/10/topics/927?r=952#message-952]]
[[http://support.criticallink.com/redmine/boards/10/topics/217?r=223#message-223]]

However, these references appear to be out of date. No function da8xx_pinmux_setup exists nor does the data structure da850_uart2_pins in MDK 2012-03-12. Looking at linux-davinci/arch/arm/mach-davinci/da850.c there are 3 clocks setup for UARTs as well as MUX_CFG for each. I certainly don't want to give up the serial console. I'm using MDK_2012-03-12.

root@mityomapl138:/proc# uname -a
Linux mityomapl138 2.6.34-rc1 #1 PREEMPT Thu Mar 31 19:35:51 EDT 2011 armv5tejl unknown
root@mityomapl138:/proc#
root@mityomapl138:/proc# dmesg | grep -i UART
UART[0] = 0, 0, 0, 115200
UART[1] = 1, 1, 0, 115200
UART[2] = 0, 0, 0, 115200

I have successfully built and booted a kernel on Linux, and loaded, run, and debugged programs on both the ARM and the C6000. Can someone point me in the right direction?


Replies (7)

RE: RS232 UART Needed - Added by Jeff Benshetler over 11 years ago

Thinking ahead, how does I get the ARM to "let go" of GPIO pins for use by the DSP?

RE: RS232 UART Needed - Added by Michael Williamson over 11 years ago

Hi Jeff,

Can you confirm you are running the kernel you are building out of MDK_2012-03-12? The uname command you ran indicates a 2.6.34 kernel, and that MDK should have a 3.2 release kernel and a newer filesystem. If you are running from a git cloned area, make sure you are using the mitydsp-linux-v3.2 branch (the MDK_2012_03_07 tag is the one used for the release).

To have the DSP take control of the UART port, you can have it do the pinmux settings for the UART2 pins and control the UART. Or you can have the ARM configure the pinmux settings (but you'll need to disable the ARM/linux uart driver for UART2).

To have the ARM set up the pinmux, you need the code per http://support.criticallink.com/redmine/boards/10/topics/927?r=952#message-952 but replace the da8xx_pinmux_setup() with da8xx_cfg_reg_list(0. TI renamed the function between 2.6.34 and 3.2, sorry for the confusion.

To disable the ARM UART2 drivers, you'll need to modify the enabled_uarts field of the mityomapl138_uart_config structure in board-mityomapl138.c from 0x07 to 0x03 (it's a bitmask of enabled ports).

I should warn you that the tcDspSerial.cpp class provided in our DSP core API may not be tested. I believe it was roughed out and pushed into our SVN trunk and was picked up in our release process (and compiles), but I don't see any test software for it here, which means the base class code may not be mature. Not sure if you are using that code or are using your own serial port code (perhaps from Starterware libraries), if you run into trouble let me know and we'll give you a hand. Most of our customers use the ARM for serial port I/O. I'm very sorry for any inconvenience and will check into the tcDspSerial class maturity when I get into the office next week.

For the GPIO, you can use the ARM (or the DSP) to configure the pinmux setting. The ARM won't configure the port or enable the driver, etc., unless you explicitly call for it in the kernel with gpio_**** or using the sysfs access (e.g., echo $pinnum > /sys/devices/class/gpio/export). So the DSP should be able to take control a non-ARM interested GPIO without messing with the linux kernel. Just be careful that you don't mess with other GPIO's that the ARM might be used (as the control registers span several GPIO in the same 32-bit space). There are write-1-to-set/clear registers to allow both processors to behave well for GPIOs "near" one another in register space.

Hope this helps.

-Mike

RE: RS232 UART Needed - Added by Jeff Benshetler over 11 years ago

OK, I think I found the ARM part of the solution. Part of it comes from this wiki [[http://support.criticallink.com/redmine/boards/28/topics/1365]]. The other part comes from [[http://processors.wiki.ti.com/index.php/Enabling_UART1_on_AM18X/DA850/OMAP-L138_running_Linux]].

How do the Critical Link BSP releases correspond to TI PSP releases?

RE: RS232 UART Needed - Added by Michael Williamson over 11 years ago

They don't. The critical link BSP linux kernel is tracking the mainline, not the TI PSPs for the OMAP-L138. TI has pushed most peripheral support from it's PSP into the mainline, with a couple of minor exceptions. We felt tracking the mainline was more appropriate as TI tends to "overwrite" history on their PSP releases, you can't really track their PSPs as upstream repositories because of that.

We do monitor their PSPs and roll in changes needed for MityDSP-L138, but for the most part that has been fairly quiet. The exception is for the USB 2.0 CPPI 4.1 DMA engine, and we are planning to push that into our kernel here (right now the USB 2.0 I/O is CPU driven, not DMA driven).

-Mike

RE: RS232 UART Needed - Added by Jeff Benshetler over 11 years ago

Summary

  1. Is my approach to enabling UART2 on the ARM sound?
  2. What is the correct way to install the additional modules provided for the FPGA and DSPLINK?

Detail

When I came in this morning, I posted my prior question without refreshing my browser so I missed that you had already replied. Thank you for your promptness.

At your prompting, I realized that I was still booting the prior MDK on the MMC. Now I'm running the 3.2.0 kernel, first off NFS and now off the MMC.

root@mityomapl138:~# uname -a
Linux mityomapl138 3.2.0 #1 PREEMPT Mon Mar 12 11:47:48 EDT 2012 armv5tejl GNU/Linux
root@mityomapl138:~#

Enabling UART2 on ARM

Structure Not as Expected

I am unable to find da8xx_cfg_reg_list. What I can find is davinci_cfg_reg_list in a number of files under arch/arm/mach-davinci.

Searching for cfg_reg_list

Working with What Is Present

After looking at numerous files in the mach-davinici directory, this is my plan:
  1. da850.c defines DA850_UART2_RXD and DA850_UART2_TXD using CFG_MUX. I'm using these as the pin identifiers.
  2. There is nothing that directly defines uart2_pins (or even uart1_pins for that matter) for any of the DA850, IndustrialIO, or MityOMAP boards. So I am creating the definition of uart2_pins in baseboard-industrialio.c as the UART physically resides on the Industrial I/O carrier board.
  3. I'm modelling the definition of uart2_pins on board-tnetv107x-evm.c, since that is the only .c file in this directory that both defines the pins and calls davinci_cfg_reg_list.

Kernel Build

I just build the 3.2 kernel from source to make sure I could and that it would run, using

$>. /usr/local/oecore-i686/environment-setup-arm5te-angstrom-linux-gnueabi
$> INSTALL_PATH=<install-into-embedded-fs> make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage
$> INSTALL_MOD_PATH=<install-into-embedded-fs> make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- modules_install

Installation of additional kernel modules?

Do I simply copy the modules for the FPGA and DSPLINK into $INSTALL_MOD_PATH?

Pardon any typos, copy-and-paste from Virtual Box stopped working and I haven't rebooted the VM yet to fix it.

davinci_cfg_reg_list.png (291 KB) davinci_cfg_reg_list.png Searching for cfg_reg_list

RE: RS232 UART Needed - Added by Michael Williamson over 11 years ago

Sorry. da8xx_cfg_reg_list should have been davinci_cfg_reg_list(), typo, my mistake.

For the FPGA drivers, you should be able to cd to the FPGA drivers directory (MDK_2012-03-12/sw/ARM/linux/drivers/fpga) on the MDK and run:

$> make -C <path-to-kernel> M=`pwd` ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- INSTALL_MOD_PATH=<install-into-embedded-fs> modules_install

It's just an out of place module build-and-install cycle.

Your plan sounds OK to me.

The uart1 pins don't get pinmuxed (even though they should) and "it works" because u-Boot already configured them for the console. For completeness, the linux kernel should reset them anyway, in case you load the kernel via some other means (like JTAG). Good catch, I will patch that in here as well.

-Mike

RE: RS232 UART Needed - Added by Jeff Benshetler over 11 years ago

Initial indications are good that the ARM changes worked. Attached are the two files modified: baseboard-industrialio.c and da850.c. The originals for both are from the 2012-03-12 MDK with a path of MDK_2012-03-12/sw/ARM/linux/linux-davinci/arch/arm/mach-davinci.

I'll need to setup an app to actually test, but writing to the device /dev/ttyS2 produces no errors and shows an increment in the TX character count in /proc/tty/driver/serial.

root@mityomapl138:/proc/tty/driver# cat serial
serinfo:1.0 driver revision:
0: uart:16550A mmio:0x01C42000 irq:25 tx:0 rx:0 CTS
1: uart:16550A mmio:0x01D0C000 irq:53 tx:7922 rx:139 RTS|CTS|DTR
2: uart:16550A mmio:0x01D0D000 irq:61 tx:248 rx:0
root@mityomapl138:/proc/tty/driver# cat serial > /dev/ttyS2
root@mityomapl138:/proc/tty/driver# cat serial
serinfo:1.0 driver revision:
0: uart:16550A mmio:0x01C42000 irq:25 tx:0 rx:0 CTS
1: uart:16550A mmio:0x01D0C000 irq:53 tx:8375 rx:162 RTS|CTS|DTR
2: uart:16550A mmio:0x01D0D000 irq:61 tx:456 rx:0
root@mityomapl138:/proc/tty/driver#
uart2-industrialio.tar.bz2 (9.44 KB) uart2-industrialio.tar.bz2 Enable UART2, disable GPIO0[9] and disable I2C1 bus
    (1-7/7)
    Go to top
    Add picture from clipboard (Maximum size: 1 GB)