SYSLink build for X86 standard linux of FReeScale ARM processor

Hi, Claude,

Syslink does not run on Linux host machine and is for Keystone 1 product. You may want to look into Desktop Linux SDK which supports the communication between Desktop Linux and Keystone via PCIe.

Rex

Please refer to http://software-dl.ti.com/sdoemb/sdoemb_public_sw/desktop_linux_sdk/latest/index_FDS.html

This software release supports C6678 cards plugged into a PCIE slot of a Desktop linux PC. And includes a simple mailbox  communication mechanism from x86 host to C6678 based EVMs through PCIE interface.  Also has an out of the box demo.

See if this meets your requirements.

Refer to the getting started guide on more details and related links:

http://processors.wiki.ti.com/index.php/Desktop-linux-sdk_01.00.00_Getting_Started_Guide

I did saw this Interface. But it is completely different from Syslink.  

Forget about x86 then, The idea was to use an API, to communicate between a standard ARM processor and the DSP, that is the same as the one on a keystone II or an OMAP processor. I know OMAP has Sys/DSP link library on the Linux/ARM side and keystone II will also have something similar.

My questions are

1- Why did TI made the decision to use another API for the PCIe interface on x86 ?

2- Can I use the SYSLink SDK (or the OMAP DSK) to build Syslink to run on a FreeScale Arm processor such as the Imx6. The interface will probably be PCIe (Which is

supposed to be supported by TI IPC (unless What is called IPC on some TI document is not necessarily Syslink) I am confused

Thank you

Hi, Claude,

There are many reasons that TI implemented different interfaces on different platforms. They could be availability of the technology at the time of development, backward compatible, road map, etc. The Syslink is a higher layer API over IPC which provides some levels of abstraction for users. I may not speak well about the syslink because I am not in that syslink group. They may be able to answer better than I. I can not comment on FreeScale product. It is inappropriate in this forum.

Rex

Rex, 

How do I contact those people from the Syslink Group. Do they have access to this forum ? or is there another communication mechanism to contact them. I really need that information since it is part of my evaluation of the TI Processor and if I cannot communicate easily with the DSP then there is not point in getting a TI over another brand. 

The mention of the IMX6 is just an example of a generic ARM processor that would interface to a TI DSP. I don't think that it is inappropriate to talk about things that the TI DSP can interface with.  It is to TI's benefit to help people integrate a DSP with another environment. I would have prefer to go for the keystone II but it is not available yet and there is no arm based GPP from TI that is good enough and cheap enough for my need so I have to rely on alternatives. 

Claude

Rex:

>   2- Can I use the SYSLink SDK (or the OMAP DSK) to build Syslink to run on a FreeScale Arm processor such as the Imx6.

  No.

  SysLink is built and tested for TI SoCs, over shared memory IPC, and though it comes with source code, there is no "porting kit" to other OS, physical IPC transports, or host processors.

Regards,

Claude,

Just came across your post. I understood you are planning to partition your application between keystone 1 (C6678?) along side of another processor (x86 or A15 or something else) and you want to use PCIe interface. Can you please provide some details about the application? # of messages/sec exchanged between the 2 processors? I/O bandwidth requirement between the processors? Any latency requirements, etc?

From previous posts, I believe you had a chance to review Desktop Linux SDK. It is basically all user-mode modules (bufferManager, mailboxes, download manager, PCIe userspace driver etc). There are only 2 things running in Kernel mode [CMEM driver & standard Ubuntu PCIe driver (i.e. libpciaccess)]. We need CMEM because, we want to be able to allocate physically contiguous memory on host processor side, so we can employ EDMA to do data transfers to/from DSP's DDR. Desktop Linux SDK is simple, and we use it as a foundation package for MCSDK Video 2.1 (where we offload video codec processing to DSP from host via PCIe) and also in OpenCL (where any generic kernel can be offloaded to DSP). So, you can consider Desktop Linux SDK to be mature, and if you encounter any issues - it is fully supported. Another advantage of using Desktop Linux SDK is that, as all the modules are user-space, it is easily portable - and you can have control over the latency and throughput.

Moving forward, for Keystone-2 the plan is to port Desktop Linux SDK components over to A15, to maintain the same north-bound APIs, and in the south-bound, instead of using PCIe, we'll be employing shared-memory based transport (as A15 and DSP are in the same device). 

I believe, Desktop Linux SDK package should suffice your needs for the application. Once you provide your application requirements, we can discuss about how to proceed further.

Regards,

Vivek

Hi , 

Thank you very much this answer. It certainly answers many of my concerns. One of them being that I wanted to write code that I could easily port to the Keystone-2 if ever we decide to go that way eventually. So It is good to know that Desktop Linux SDK will be ported over to the A15 of the keystone-2.

Is it going to be part of MCSCK 3 ? or is it going to be a separate thing ?

In terms of detail, I can tell you that we are doing audio so the through put will mainly be high quality (not telephony) audio frames (up to 32 or more if we can: 3MBps), received/sent IP on the GPP (X86 or ARM) Side and encoded/decoded by the DSP. Latency must be very low (<1ms) and it must sustain with minimum jitter the flow of the audio stream. DSP will mainly acts as an Audio Process/Card for the GPP (Including Audio Codec, Echo Cancellation, Filtering, mixing)

You are mentioning Ubuntu PCIe Driver. If I use some other  OS (Linaro, Open-Embedded) on a ARM processor, is it going to work without too much porting work ? Can TI give us Hints about porting it ?

By the Way we think in using the 6657 (not the 6678) because of pricing, I presume that it will also work the same ?

Regards, 

Claude

Claude,

Thanks for the details about your application. The throughput necessary for your application is really negligible compared with the available PCIe bandwidth. Mailbox based communication between host and DSP bypasses the Kernel and should help in your latency requirements. In the Desktop SDK example filetestdemo, we have a busy poll-based mechanism to pick up mailbox messages from DSP but you can consider implementing an interrupt based notification to host. 

Desktop Linux SDK components (mailbox, bufMgr etc) will be part of MCSDK 3.x. We will be obsoleting download Manager in Desktop SDK but instead use MPM (Multiproc Manager) that currently takes care of reset, download of DSP images. In future, MPM will get the capabilities to do DSP crash notification, coredump, debug tracing etc. Porting effort should be really simple to move to Keystone-2. 

Regarding PCIe driver, we use "libpciaccess". I believe it or its equivalent shall exist in other OSes as well. I am not too familiar with this. Please post if you have any specific questions and other gurus on the e2e forum can help.

Regarding C6657, I don't have personal experience (we use C6678). However, I'd think it works the same way.

Regards,

Vivek

Vivek Chengalvala said:

Desktop Linux SDK components (mailbox, bufMgr etc) will be part of MCSDK 3.x. We will be obsoleting download Manager in Desktop SDK but instead use MPM (Multiproc Manager) that currently takes care of reset, download of DSP images. In future, MPM will get the capabilities to do DSP crash notification, coredump, debug tracing etc.

Vivek:

Has dnldmgr been replaced already by MPM?  I'm starting a new project now, and I want to only use the features that will be supported in the future.

I also notice: a search on e2e for "dnldmgr" yields 6 (six) results... seems like it isn't very well used!

Hi, Chris,

MPM is not implemented on C6678, but on Keystone 2. MPM allows ARM core to download application to DSP cores. On c6678, there isn't an ARM core.

Rex