• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 1213 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

K2H DSPCore2DSPCore IPC (virtio)

Janos Balazs
Intellectual 380 points 
We are trying to use IPC on a K2H device to communicate between arm and dsp cores
and also between dsp's. The only example we found helped a lot to configure the virtio module and arm-dsp
messaging works just fine.
But when we attempt to connect from one dsp to another's MessageQ it blocks indefinitely.
In the documentation it is also mentioned that it is possible to send messages without connecting so we
checked this too, but then MessageQ_put gives us the following:

[C66xx_0] 3 Resource entries at 0x800000
registering rpmsg-proto service on 61 with HOST
[t=0x00000007:e61daff3] ti.ipc.rpmsg.RPMessage: RPMessage_send: no object for
endpoint: 53
[t=0x00000007:e659379e] ti.ipc.rpmsg.RPMessage: RPMessage_send: no object for
endpoint: 53
[t=0x00000008:2356a1ee] ti.sdo.ipc.MessageQ: ERROR: line 459: assertion failure:
A_unregisteredTransport: transport is not registered
ti.sdo.ipc.MessageQ: line 459: assertion failure: A_unregisteredTransport: transport
is not registered
xdc.runtime.Error.raise: terminating execution

The MessageQ_QueueId is the same as the arm uses succesfully.

So, is it even possible to send msgs or events from dsp to dsp when virtio transport
is configured?
What is this virtio module anyway? Must be something new since it's not easy to find
any documentations on it.

Smells like some more .cfg magic is needed on the dsp side...
When we use shared memory transport setup for IPC on dsp, it certainly works. (dsp core -> dsp core in the same chip)

Documentations also mention that it is in fact possible to setup two IPC transport at the
same time but I couldn't find any example yet.

Any help would be much appreciated!
  • 0
    TI__Mastermind 20790 points

    Hi,

    You can find the IPC based example code at:mcsdk_bios_3_xx_xx_xx\demos\image_processing\ipc
    Refer the IPC part of the code from this project and understand the work flow.
    The IPC in this context is MessageQ based IPC between ARM to DSP and between DSP to DSP.
    This transport is based on rpmsg for communication between ARM and DSPs, and a
    proprietary shared memory protocol for communication between DSPs.
    MessageQ is a reliable control path for inter-processor communication.
    You see the messageQ test code at: ipc_x_xx_xx_xx\packages\ti\sdo\ipc

  • 0 in reply to Pubesh
    Intellectual 380 points 
    Hi Pubesh,

thank you for the clarification!
    Unfortunately, there's been some confusion in my question: the virtio name comes from the
linux side and must have something to do with the rpmsg driver. I really meant "rpmsg
based MessageQ's" there.

What we did so far, is that we used the cfg from the image_processing
example you mentioned, and got it working between arm-dsp but not between dsps. We were able to check
    the shared memory transport based messages between dsps in a different project, where the arm cores
weren't used. (no linux there, nothing)

My point here really is how we could merge the two projects?

Do you actually mean that the image_processing example .cfg setup should work for
dsp-dsp messages as well and we merely looked over something?

What fuels my suspicion that something more is needed is that the image-processing
demo only shows arm dsp messages and that's what we got working as well.
I couldn't find any ccs example projects in the  ipc_x_xx_xx_xx\packages\ti\sdo\ipc project you suggested, 
    and I'm afraid I won't be able to reverse engineer the project to create an xgconf script for dual transport IPC setup .

Do you think you have any examples or documentation on this? 

    Thanks a lot!

    Best regards,

    Janos
  • 0 in reply to Janos Balazs
    Intellectual 380 points

    Still stuck on the same point, thought I'd just give this thread a bump... Any help here would be much appreciated

  • 0 in reply to Janos Balazs
    TI__Mastermind 20790 points

    Janos,

    There is no test code as per your requirment, but you can find the transport module files at the IPC package.
    You may create the project using this APIs.
    Go through the SYS/BIOS Inter-Processor Communication (IPC) User’s Guide to get detailed information.

  • 0 in reply to Pubesh
    Intellectual 380 points
    Hi Pubesh,

    it seems that simultaneous communication between ARM-DSP _and_ DSP-DSP via IPC wouldn't work with any backend. One follow up question could be: we've got a project using virtio IPC which has stopped working ever since we've upgraded to mcsdk-hpc_03_00_01_12.
    Unfortunately, we need the best of both worlds... Could it be that in this HPC environment this kind of low level ARM DSP virtio IPC has never been tested? Actually, sometimes we see messages on the DSP cores but not for all the cores and the phenomena seems chaotic. Furthermore, messages that do arrive have wrong content. The compiler has no complaints though, that's why we suspect
    IPC code version difference on ARM and DSP side. Could you please address this?

    Regards,

    Janos
  • 0 in reply to Janos Balazs
    Expert 1070 points
    Hi Janos,
    Did you get anywhere closer to that?
    I am having same problem as I need ARM-DSP and DSP-DSP messageq communication.
  • 0 in reply to Pubesh
    Intellectual 300 points

    Well I stumbled upon this thread probably having the same issues as others. First there is NO explicit K2H IPC demo in the IPC folder you specify. And there is NO singular and clearly defined set of implemented IPC transports for K2H for ARM->DSP and DSP->DSP. Only thing that is clear the the shared memory DSP->DSP transport. This is maddening and a waste of all our time. And the IPC implementation for DSP->DSP requires 5 uSeconds for message passing, which is insanely slow for shared memory implementation.

    Add to this the constant renaming of the SDKs without clear definitions and reason, incomplete and asymmetrical support across ARM and DSP. Honestly for such an incredibly well designed part it seems there has been nothing but half baked and incomplete software support of one of the MOST important components, core to core communication.

    So I am still stuck running around in circles between the various redefined packages, with no clear documentation on WHICH IPC transports are implemented and tested for ARM->DSP and DSP->DSP for K2H, and not a SINGLE K2H SPECIFIC demo.

    Please prove me wrong and just point me to ONE example specifically for K2H and one page where we can all see the matrix of what IPC transports are available to us across Linux and RTOS. I know I for one have wasted entirely too much time on this and am on the verge of just rolling my own solution. But this is not an option for everyone.