Last updated: June 23, 2010

[edit]About SysLink

SysLink is the next generation IPC driver developed for OMAP4 and beyond. SysLink is an evolution of both the previous-generation IPC drivers - DSPBridge and DSPLink. It provides a symmetric IPC interface on both the host processor and remote/slave processors. It is easily scalable to support more than 2 processors. SysLink provides features to control and communicate with slave processors enabling parallel processing for multimedia acceleration. SysLink integrates with D-OMX enabling MPU to offload some OMX components to slave processors.

Some of the key features of SysLink are:

• Messaging: Ability to exchange fixed size control messages with Co-Processors
• Dynamic memory management: Ability to dynamically map files to Co-Processor‘s address space
• Dynamic loading: Ability to dynamically load new components on Co-Processors at run time
• Power Management: Static and dynamic power management for DSP
• Zero-copy shared memory: Ability to "pass" data buffers to other processors by simply providing its location in shared memory.
• TILER-based memory allocation: Allocate 2-D buffers with mirroring and rotation options, suitable for video
• Remote function calls: One processor can invoke functions on a remote processor.

[edit]SysLink Architecture

The above diagram shows the components found in SysLink. The two processors shown have slightly different components because one plays the role of the host and one plays the role of the slave. The host thus needs to load a system image onto the slave processor (Loader), get it up and running (ProcMgr), handle the slave virtual memory mapping (IOMMU), etc.

The key component of SysLink is the Remote Command Messaging (RCM) module, which handles remote function calls. Using RCM, a host processor can take advantage of slave processors‘ multimedia acceleration functions. The host can request the slave to run audio or video processing functions on a data buffer. The host can then proceed to other tasks. By delegating this processing to the specialized remote processors, the system can support high-bandwidth audio and video playback without a performance impact on the core.

[edit]SysLink Usage

The above diagram illustrates the process by which an application on a host processor can execute a function on a slave processor. It is simplified and many details of the process are not shown.

1. Application calls RCM client object on local processor to request execution of a remote function.
2. RCM client object passes function request message to remote RCM server through local MessageQ.
3. Local MessageQ puts message in remote MessageQ‘s list of received messages.
4. Local MessageQ requests local Notify module to send notification to remote processor that a message has arrived.
5. Local Notify module notifies remote Notify module.
6. Remote Notify module tells Remote MessageQ object to check its list of received messages.
7. Remote MessageQ object gives remote RCM server the function request message it received.
8. Remote RCM Server calls remote function.

[edit]Getting Started with SysLink

NOTE: These instructions are to compile branch in kernel-syslink dev.omapzoom project.

The latest SysLink that is available on the kernel-syslink git tree along with the userspace files repository(recommended)

Before proceeding, check for the tools:

Set up a tool chain, the tool chain versions commonly used are Code Sourcery ARM Sourcery G++ 2009q1.

Set cross compile variable.

  export CROSS_COMPILE=arm-none-linux-gnueabi-

  export PATH varible to arm codesourcey cross compiler.
  export ARCH=arm

Be sure that you have the mkimage tool visible in the exported PATH, this is generated while compiling u-boot under u-boot/tools folder, you can clone u-boot repository from here.

[edit]Building Kernel Image with SysLink Driver Support (git tree approach)

Clone linux-syslink repository with the following command:

  git clone git://dev.omapzoom.org/pub/scm/tisyslink/kernel-syslink.git

Checkout syslink_next branch. syslink_next branch is based on the cutting edge Kernel revision. This tree is based on kernel-omap4-base tree on dev.omapzoom.org, any porting to other kernels may require some fetch and merge.

The user-space Syslink has a dependency on Tiler tree, so make sure you fetch the Tiler changes from Tiler tree [1] before building the SysLink Kernel. If you don‘t care about working with the latest SysLink version then it is recommended to use the Integration kernel. The Integration kernel has all the dependent Multimedia drivers including Tiler driver [2]

  cd kernel-syslink
  git checkout -b syslink_next --track origin/syslink_next  

Configure your board.

  make omap_my_board_defconfig  

Select any desired kernel options

  make menuconfig  

Select from menuconfig the option to enable SysLink driver in the Device Drivers section as shown in the figures below:

SysLink driver options menu: Enable the selected SysLink modules.

Make the Kernel Image after saving your changes in menuconfig.

   make uImage  

At this point, you should have a uImage. At present building syslink as loadable kernel modules is not supported.

[edit]Build Userspace Files

[edit]Need to check for the following before using autotools

[edit]Tools Prequisites

• Autoconf version: 2.61 and above.
• Automake version: 1.9.6 and above.
• libtool version : 1.5.6 and above.

[edit]Set the following environment variables

export ARCH=arm
export CROSS_COMPILE=arm-none-linux-gnueabi-

Also, point your shell(sh) to bash. It is assumed that the references to sh in this README documents is actually pointing to /bin/bash

[edit]To enable DEBUG Option

You can enable the DEBUG option by uncommenting the following line in the build_directions.sh file.:

ENABLE_DEBUG=--enable-debug

You can also enable the DEBUG option by entering:

./configure --enable-debug.

Note: please check for ./configure --help before running configure.

[edit]Steps to Build Syslink

• Clean build:

sh build_directions.sh --clean

• Normal Build:

sh build_directions.sh

• Enter the Prefix path, e.g.:

/omap_data/development/projects/userspace-syslink

• Enter the Tiler-Userspace Path, where you cloned [3], e.g.:

/omap_data/development/projects/tiler-userspace

• Enter the path to kernel-syslink, e.g.:

/omap_data/development/projects/kernel-syslink

• Enter the Toolchain Path, e.g.:

/omap_data/omapts/arm-2009q1-203/bin

• The libmemmgr.so is built and installed in $(PREFIX)/target/lib folder.
• The Syslink APIs, daemons and samples will be built and installed in $(PREFIX)/target/lib and $(PREFIX)/target/syslink folder, respectively.

[edit]Working with SysLink driver

[edit]Bootargs

Set the following bootargs when working with SysLink IPC.

Bootargs: Make sure to set "mem" option in bootargs 49M less than your total RAM size.
Eg: For a 512M Ram size the mem option should be less than or equal to 463M.

SysLink IPC is currently using this 49M for IPC purpose.

Boot your kernel, when you receive the console prompt:

[edit]Booting Ducati Cores

[edit]Booting using SysLink Daemon

syslink_daemon binary is used to load and initialize the Ducati Cores. The images to be be loaded on Ducati Cores should be mentioned as the argument to the syslink_daemon.out binary. The first argument is the image to be loaded on SYS-M3 (Core-0) and the second argument is the image to load on App-M3(Core-1)

  ./syslink_daemon.out </binaries/sysm_m3_image> </binaries/app_m3_image>
 

Full path to the images should be provided.

SysLink Daemon apart from loading images also starts MemMgr server.

The MemMgr server handles the Tiler requests coming from Co-processor. MemMgr server interfaces with the Tiler Driver through MemMgr library. Currently there is a design discussion with DOMX team to push move this MemMgr server to DOMX proxy component.

[edit]SysLink Samples

 Coming soon ...

[edit]SysLink Driver Code

The latest SysLink source code exists on the dev.omapzoom Git Tree under drivers/dsp/syslink folder.
syslink_next branch holds the latest code

[edit]User space SysLink libraries and samples

Userspace Git Tree

[edit]Ducati/Tesla IPC Source Code

Ducati/Tesla IPC code is available on GIT Ducati code 

[edit]Tools

CodeGen tools download
BIOS download 
XDC download

[edit]SysLink User-space Project

The SysLink user-space project is located at sl_bios_ipc. SysLink related Documents along with BIOS sample images would be made available here.

[edit]SysLink Releases

• SysLink Kernel should be build from the Integrated Kernel
  • git://dev.omapzoom.org/pub/scm/integration/kernel-omap4.git
• SysLink Userspace should be build from SysLink userspace GIT tree
  • git://dev.omapzoom.org/pub/scm/tisyslink/userspace-syslink.git
• SysLink Ducati Binaries used for this released should be picked from userspace project releases
  • http://dev.omapzoom.org/?p=tisyslink/bios-syslink.git;a=summary
• Tiler Userspace should be build using Tiler tree
  • git://dev.omapzoom.org/pub/scm/tiler/tiler-userspace.git

Following provides the release information of above SysLink repositories

[edit]L24.8

• Kernel: branch - L24.8
• Userspace: branch - syslink-2.0; tag - ti-syslink-mpu-rls-24.8
• Ducati Images: images
• Tiler userspace: branch - memmgr_1.0; tag - 24.8

[edit]L24.9

• Kernel: branch - L24.9
• Userspace: branch - syslink-2.0; tag - ti-syslink-mpu-rls-24.9-p1
• Ducati Images: es2.0-wa images es1.0 imageses2.0 nowa images
• Tiler userspace: branch - memmgr_1.0; tag - 24.9
• SysLink Release Notes: release_notes

[edit]L24.10

• Kernel: branch - L24.10
• Userspace: branch - syslink-2.0; tag - ti-syslink-mpu-rls-24.10
• Ducati BIOS: ti-bios-ipc-rls-2.2-p1.2
• Tiler userspace: branch - memmgr_1.0; tag - 24.10.1
• SysLink Release Notes: release notes

[edit]L24.11

• Kernel: branch - L24.11
• Userspace: branch - syslink-2.0; tag - ti-syslink-mpu-rls-24.11
• Ducati BIOS: ti-bios-ipc-rls-2.3
• Tiler userspace: branch - memmgr_1.0; tag - 24.11
• SysLink Release Notes: release notes

[edit]Documents

• SysLink Programming Guide 2.0
• Syslink Overview Final-Public
• Syslink API Reference

http://omappedia.org/wiki/Syslink_Project