IPC 3.x Migration Guide

Introduction

This article describes differences between SysLink 2.x/IPC 1.x and IPC 3.x. See the IPC 3.x article for more product details. When applicable, OS-specific details are separated into their own sections.

Slave Loading

SysLink 2.x provided the ProcMgr API set to control the slave processors. Often slave management was delegated to an external application (e.g. slaveloader, firmware_loader) so many applications weren't exposed to the ProcMgr APIs. This "keep the loader independent of the apps" approach also enabled better integration with multiple applications, each of which used the slave, but didn't need/want to know about each other.

In IPC 3.x, the slaves are loaded as needed, typically at driver load time. The application doesn't need to call any runtime APIs.

The IPC 3.x-using slaves are configured to include a Linux-defined resource table. This resource table is parsed at load time, resources are allocated (on the HLOS side) and provided to the slave.

NOTE

Although the Linux community defined the resource table, the IPC port to QNX also uses the same resource table.

On some devices, the loader can detect slave crashes and reload the slave automatically. This feature is not available on all platforms, especially in early IPC 3.x releases.

Linux

The Linux slave loader builds on the kernel remoteproc driver. Slaves are loaded when the remoteproc driver is loaded. To unload the slaves, you can remove the driver. The Linux IPC Install Guide has more details.

QNX

The QNX loader is part of the resource manager, and the slaves are loaded when the resource manager is launched. The QNX IPC Install Guide has more details.

Setup

In IPC 1.x, for BIOS-using peer-to-peer setup, or BIOS-side slave-to-slave setup when an HLOS was in the system, users would call IPC_start(), IPC_attach(), IPC_detach() and IPC_stop() to 'attach' and 'detach' from each other.

In SysLink 2.x, HLOS-side applications would use SysLink_setup() and SysLink_destroy() to initialize the SysLink library. Then they would 'attach' and 'detach' with discreet slaves using Ipc_control() with the LOADCALLBACK, STARTCALLBACK, and STOPCALLBACK commands. These host-side APIs required cooperating slave-side calls to IPC_start(), IPC_attach(), IPC_detach() and IPC_stop().

In IPC 3.x, the slave and host APIs were brought into alignment. There is no SysLink_setup() or SysLink_destroy(), and both sides now call IPC_start() and IPC_stop() to enable/disable use of IPC services.

Removed APIs

The HLOS-BIOS communication options have been reduced in IPC 3.x. This was done in response to user feedback that the APIs were too complex, and also to bring it into general compliance with HLOS conventions (primarily in Linux) that user-space should have limited access to hardware. On the HLOS side, only the IPC_*, MessageQ, NameServer and MultiProc APIs remain. In some HLOS environments, GateMP is also provided.

NOTE

For HLOS users of SysLink 2.x's memory APIs (e.g. HeapMemMP), many Linux SDKs are recommending/providing CMEM as a shared memory solution. There are limitations (e.g. you cannot alloc on HLOS and free on RTOS), but these are in line with using the HLOS as a master (owning all resources) and RTOS as a slave (using resources provided by the master).

On the BIOS side, for BIOS-to-BIOS communication, all IPC APIs remain. Note, however, that RingIO and FrameQ were provided by the SysLink 2.x product (not the IPC 1.x product), and are no longer provided in IPC 3.x.

Added APIs

Specifically to support existing OMAP multimedia stacks (e.g. dce, OMX, dvp), IPC has added the 'MmRpc' HLOS-side APIs. These APIs enable invoking a function on a remote processor (much in the same way RCM does). The MmRpc APIs are intended for use by TI's multimedia stacks.

Roadmap-wise, users are encouraged to MessageQ for user-mode endpoint to BIOS endpoint communication.

Device Support

For devices running an HLOS (e.g. Linux, QNX), IPC 3.x is only supported on a few devices. See the release notes for details as specific device support evolves over time.

For devices running BIOS on all cores, IPC 3.x initially supports all the same devices as the last IPC 1.x releases. The BIOS-side code is all the same.