Syslink 02 00 00 56 c6x 01 alpha2

The Initial port of SysLink for c6x is based on Syslink 02_00_00_56_alpha2. This is the second iteration of the release and adds support for building SysLink with Code Sourcery gcc tool chain. The functionality supported in SysLink c6x release is discussed below :-

changes from syslink 02_00_00_56_c6x_alpha2

 * Updates to support building with gcc tool chain
 * Simplified sample user land applications to start IPC with remote cores through ProcMgr API calls. Means no need to run ProcMgr application per core basis before running the sample application.
 * ProcMgr application now starts IPC with all of the remote cores. Thus user can just run one instance of the ProcMgr application before running Kernel sample modules.
 * Added support for building rtos sample applications from the top level linux-c6x-project directory

ProcMgr
ProcMgr provides basic slave processor control. A thin layer of ProcMgr functionality is implemented in the c6x port. ProcMgr assumes that slave core is loaded and run external to SysLink. Only a small subset of the ProcMgr APIs are used in c6x. There is no support for the following:-

* Host loads the slave with slave executable present in host file system * Host starts the slave * Host stops the slave execution * Host unloads the slave

This means the related API calls are not supported on this release. Before invoking any SysLink API call, the slave core is to be loaded and started. Typically on c6x, application do a ProcMgr_open followed by a call to ProcMgr_attach to get a handle for a slave core. It then skip the load part and initialize an IPC instance with the slave core using Ipc_CONTROLCMD_LOADCALLBACK IOCTL command. The Ipc_ResetVector address is provided as an argument to this command. This will allow SysLink to read the slave processor configuration from the slave processor's memory. After this the processor start part is skipped. The Ipc with the remote slave is started using Ipc_CONTROLCMD_STARTCALLBACK IOCTL command. Once this is complete, application can start IPC with the remote core and IPC module services are available. This includes services provided by Notify, MessageQ etc.

IPC Modules
Supports MessageQ protocol using Shared memory transport. For testing this functionality on c6x, shared memory is assigned from the upper 16M of the DDR2 address space on Faraday (C6474) and from SL2 RAM for Tomahawk (C6472).

IPC building blocks
Following are supported:-

* Notify. Uses the IPC hardware on the platform to support notify. * SharedRegion * HeapMemMP * HeapBufMP * ListMP * GateMP - GateHWSem. This module is available on Faraday to implement system gates. This is        implemented using the hardware semaphore hardware available on Faraday. - GateAAMonitor. This module is available on Tomahawk for system gates and is implemented using the Atomic Access monitor hardware. Currently this module requires the shared memory be allocated on SL2 RAM. That is the reason for allocating shared region on SL2 RAM for Tomahawk.

Getting Started
Release Notes: This document provides information on the current release.

Install Guide: This document provides information to get started with installing SysLink and its dependencies, building SysLink and its sample applications, and executing the sample applications.

API Reference Guide
API reference guide is provided within the SysLink product package in folder syslink/docs/doxygen/html/index.html. It provides doxygen generated API reference guide for the application developers. This release re-uses the documentation from Syslink 02 00 00 56 alpha2 release.

CDOC Source Reference Guide for RTOS IPC
CDOC source reference guide is provided within the SysLink product package in folder syslink/docs/cdoc/index.html It provides cdoc generated Source Code reference guide for RTOS IPC.