This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Keystone 2 code and IPC support is a total and complete mess

I have now spent over TWO weeks just trying to get basic IPC working on the 66AKH12 chip for ARM->DSP and DSP->DSP. The basic shared memory DSP/DSP IPC library/configuration/examples were fine, but the more I dig into the ACTUAL implemented and tested support for ARM->DSP and virtio/messageQ it is becoming clear that the codebase is immature, incomplete and almost unusable. I have read through multiple threads, posted numerous questions that have gone unanswered (shocked, welcome to the new TI), and tried EVERY combination of IPC examples scattered through the various named and renamed "modulea" (BIOS/SDK/PDK) and have tried to configure every way I could find by guessing, reading scattered and incomplete documentation across Wikis, actual Doxygen, and here.

I think we are now at a point that the one of the basic strengths of TI chipset is almost completely gone. The mature/robust code base, clear example, and really good documentation that got us up and going are now gone. I have one engineer spending three months building and rebuilding kernels with patches that are not included, and currently we have discovered TI decided to disable DDRB for no real reason other than they wanted to, breaking a lot of things. mpmcl does not work and hangs on this kernel. You can not load DSP code from CCS to test ARM->DSP because of dependencies and decisions that are completely unclear looking at the actual hardware.

And asking for ONE clear example code for this chip has yielded nothing, because there isn't one. It is almost as if no one has actually used this chip for IPC at TI during development. Posts here indicate that it is near impossible to support to transports for communication at the same time.

I am on the verge of giving up and just rewriting my own IPC codebase using the hardware support that seems well in place for a simple clean implementation. So I'll ask ONE MORE TIME, can anyone point me to ONE existing ARM->DSP and DSP->DSP IPC example for THIS particular keystone processor at TI?

  • Hi, Edmund

    I agree with you that IPC is unstable when it is applying to communication between ARM and DSP. However, we need to admitted that TI offer

    us the IPC demo comed with MCSDK3.14, if you install correct cross-copiler tools, I think it is fine to run the IPC demo in EVMK2H. About how to copiler

    the IPC demo you can refer to below thread.

    Then, I  want to share my opinion about ARM2DSP or DSP2ARM communication mechnism by unsing driver in ARM side and DSP run on NO OS rather

    SYS/BIOS. If we only want to archieve simple inter processor communication, I think we can do it in a much simple way. Here we assumed that communication

    between ARM0 <--> DSP0.

    In DSP0 side, we can configure IPC interrupt event to CPU hard interrupts, the event named IPCGN in datasheet. In ARM0 side , we run Linux system, so

    need configure IPC interrupt in linux driver. We can inform DSP0 by ioctl function to write value to IPCGR0, which DSP0 side can receive the command through

    IPCAR0 in DSP hardware interrupts. In the same way, we can Inform ARM0 in DSP0 side by writing specific value to IPCGR8, then ARM0 can received the

    command through IPCAR0 in the driver interrupts. 

    In the same time, we can share memory in the DDR3 anywhere throungh mmap function. Then we can share the memory in the DDR3 rather share

    memory. However, there are some problems need to solve when configre GIC-400 interrupt controller. The problem I am encountered is that I can't insmod the

    driver which I have compiler sucessfully. Although it can't work now, it is a way to implement ARM2DSP communication.

  • Thanks for the reply but this illustrates exactly my point. First of all there are MANY demos for many platforms and it is either guesswork, reading hardware manuals and comparing datasheets or digging through many e2d posts and contradictory and incomplete Wikis across MCSDK->PDK and DSP BIOS->RT BIOS to try to put it all together. Which is insane. Can you imagine trying to hand off development to software person without actual DSP hardware knowledge? Which btw would be completely possible with a complete set of documentation and one example program. Instead we have to sort thought renaming of same code for no apparent reason, only to find out that RT BIOS is really an incomplete implementation on ARM anyway and near useless.

    Meanwhile I have 5 different IPC examples I have found, but NONE are for this chip. Closest one if for the tci variant and loading that causes a run time "incorrect chip" exception. So yes I know I can get one working eventually after having to go through a LOT of work for what should be a trivial example. But then what's the point when its an incomplete and untested example? And this is before I even bring up the fact that CCS is almost unusable at this point since the Eclipse transition. A rebuild of a single source file example takes over 5 minutes to build and over a minute to load/run. Maybe this is ok for a hobby system but this is supposed to a professional development environment for high end DSP processing. I could get work done in pre-eclipse CCS even with the crashes, but now I spend most of the day waiting.

    To your point: in about 3 hours I have already mostly finished implementing a shared memory based private IPC framework. Same as you I am using shared memory (MCSM) and simply freeze the L1D on the DSPs to for cache coherency during access (L2D is already bypassed for this). And on the Linux side will do kernel drives. I am curious why you are not using the IPC Generation interrupts for signaling?

  • Hello Edmund,

    Did you have the chance to look at IPC FAQ?



  • dzhou said:

    Hello Edmund,

    Did you have the chance to look at IPC FAQ?



    Yes, I have seen this, and all the scattered and incomplete Wikis, and all the scattered links from all the e2e posts where the same questions come up over and over and over again. Did you even read my original post? Because if I ask a questions either no answer is forthcoming if I am specific enough, or a generic useless answer like this one is posted. I am guessing this is good for support matrix while completely alienating actual customers. And I have already seen the confirmation that there is no way to have ARM->DSP and DSP->DSP IPC using two methods, and that there are tons of other limitations on how to run code, and how you can't load and debug from CCS for DSP but have to load from kernel then attach. Which sounds fine to anyone who actually has NEVER DONE ACTUAL HIGH DEMAND DSP processing, but is ridiculous for a real life development/test cycle.

    And the fact that whoever developed the linux load utility (which is pretty bad anyway) never realized a command line option to RELEASE the DSP from reset would be very useful during development is very telling to the experience of the development team. Because the alternative is a 8-10 step process in CCS to connect with a config file, show the hidden cores, connect to the debug core, then load a gel, and THEN finally run a script to release the DSPs out of reset. This is the only way to use the DSPs after the Linux kernel boots. So in a real life development cycle where we are not just setting an EVM to no boot no one has realized a quick flag would be useful to release the DSPs out of reset.

    And let me quote from the doc you yourself have referred to. Do you realize how ridiculous this is for a device whose PRIMARY function is parallization of tasks across DSP cores?

    1. For KeyStoneTM II, are there any CCS based examples to demonstrate a simple communication between ARM® core to DSP?

      No. There are only image processing demos. In MCSDK 3.x, the ARM® core only runs Linux kernel and user Space applications. There is not a Linux application example using CCS; an example like this would use Linux commands. 

  • Hi, Edmund

    I think this is a good example for you understand the mechnism of communication between ARM and DSP, Which can be

    work fine in CCS. This is a bare-metal program, run in DSP0 and ARM0 respectively. I think this demo can be modified and work

    fine in any K2 Plaform.

    Whatsmore, my evaluation module is EVMk2H. What I have done in ARM driver is according to this demo. Altough I can't move this 

    program to linux driver sucessfully, I think it is a good example to understand IPC mechnism.