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

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

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?

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

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.

Working with What Is Present¶

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.

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

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#