Herostratus’ legacy

words from a lazy coder

Diving into SysLink v2

Following with our SysLink saga, now we will dive into its internals.As we stated before, SysLink is a software stack which implements an Inter-Processors Communication (IPC), whose the purpose is enabling the Asymmetric Multi-Processing (AMP).

Most of the readers are more familiar with the concept of the Symmetric Multi-Processing (SMP), which is the most common approach to handle multiple processors in a computer, where a single operating system controls and spreads the processing load among the available processors. Typically these processors are identical.

On the contrary, AMP is designed to deal with different kind of processors, each one running different instances of operative systems, with different architectures and interfaces. The typical approach is to have a master processor with one or more slave units, all of them sharing the same memory area, hence the operating system running in the master processor expose the other processors as other devices available in the system (figure 1).

Asymmetric Multi-Processing (AMS)
Figure 1

The main advantage of AMP, as we mention in the previous post, is that we can integrate specialized processors and delegate them tasks that are rather expensive to execute in our general purpose processor, such as multimedia, cryptography, real-time processing, etc.

All the operating systems, executed in an AMP system, must share, at least, one key component: a mechanism of Inter-Processors Communication, because with it, they will be able to interchange data and synchronize tasks among each other.

Basically there are two types of IPC: shared memory and message passing. With the shared memory we avoid copying the data to process in other unit, but also we will demand complicated semaphoring protocols, in order to avoid overlapping, what lead to the data corruption. On the other hand, message passing is oriented to the transfer of small chunks of data, called messages, sent by one processor and received by another, and are used to notify, to control and synchronize.

Therefore, SysLink version 2.0, provides a set of components for IPC, for both shared memory and message passing (figure 2):

SysLink v2
Figure 2

All these operations are done through ioctl operations to the /dev/syslink_ipc device.

Nonetheless, SysLink v2.0, being a master/slave configuration, it must provide a way to control the slave processors, operations like starting and stopping, to load an operative system into them, and so on. In that regard, there is a module called the Processor Manager, which is operated also through ioctl calls to the /dev/syslink-procmgr device, and also to the specific processors, what are also mapped to the device file-system as /dev/omap-rproc[0-9], in the case of the OMAP processors.

Now, on top of all these IPC facilities, there must be a façade for all the remote operation that we could execute, and that façade is called Remote Command Messaging (RCM). Our application, which is running in the master processor, will act as client RCM and will request remote commands on the RCM server, which is running in a slave processor. DCE (Distributed Codec Engine) is an open source RCM, developed by Rob Clark, to expose distributed multimedia processing in the OMAP4.

And I continue developing a thin API for SysLink 2.0 :)

References