• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 101 subscribers
  • Views 1136 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

OMAPL138 MessageQ example failing with -22 on Nameserver Socket Connect

Douglas Pepelko
Prodigy 130 points

I currently have a Linux distro running (TI's 3.14.18 with RPMSG and RemoteProc) on the Arm. I have XDC 3.30.6.67_core with IPC 3.36.2.13 and SYS/BIOS 6.42.2.29. I have compiled up the examples of the MessageQ example and have not been able to get them to run.

I have shared memory at 0xC2000000 and pass this to Linux in the RPMSG_VRING1_DA of a custom resource table. I am certain Linux is getting this DA although it throws it away. :(

I removed the line "BIOS.addUserStartupFunction('&IpcMgr_ipcStartup')" and instead call Ipc_start in the top of my first task. Tracing in I can see that I am stuck waiting on the Linux side to write PROCSYNCSTART into remote->startedKey at 0xC2000000

On the Linux side the MessageQApp calls Nameserver_attach. Deep down inside the net/rpmsg/rpmsg_proto.c the connect fails because there are no VRP entries in the tree.

Is the DSP responsible for adding values to the VRP radix tree?

Is the Linux side responsible for writing a PROCSYNCSTART into the shared memory?

  • 0
    TI__Mastermind 18260 points

    Douglas,

    I already replied to your other post that seems to be the same issue (here: https://e2e.ti.com/support/embedded/linux/f/354/p/448867/1615440#1615440), and hopefully that will help, but I'll answer your questions here...

    Douglas Pepelko said:

    I removed the line "BIOS.addUserStartupFunction('&IpcMgr_ipcStartup')" and instead call Ipc_start in the top of my first task. Tracing in I can see that I am stuck waiting on the Linux side to write PROCSYNCSTART into remote->startedKey at 0xC2000000

    For Linux <-> DSP IPC you shouldn't be calling Ipc_start(), since you'll end up in the function (that contains the above startedKey stuff) dealing with synchronizing the SharedRegion (which also should *not* be in play for Linux <-> DSP IPC).  The "BIOS.addUserStartupFunction('&IpcMgr_ipcStartup')" is the right thing to have.  Or you could call IpcMgr_ipcStartup() manually in a SYS/BIOS task.

    Douglas Pepelko said:

    On the Linux side the MessageQApp calls Nameserver_attach. Deep down inside the net/rpmsg/rpmsg_proto.c the connect fails because there are no VRP entries in the tree.

    Is the DSP responsible for adding values to the VRP radix tree?

    No, the Linux kernel handles the VRP radix tree, but I think that action is spurred by DSP activity after the two sides have attached.  So if you're not getting past the "attach" sync point then there won't be any sockets available in rpmsg.

    Douglas Pepelko said:

    Is the Linux side responsible for writing a PROCSYNCSTART into the shared memory?

    Not PROCSYNCSTART (since that's just a SharedRegion mechanism) but a similar flag in the resource table gets set by the Linux side, thereby unblocking the DSP spin in VirtQueue_startup():

    /*!
     * ======== VirtQueue_startup ========
     */
    Void VirtQueue_startup()
    {
        ...
        while (Resource_getVdevStatus(VIRTIO_ID_RPMSG) != VRING_BUFS_PRIMED);

    This is where your DSP code should end up when calling IpcMgr_ipcStartup() (which is called via the .cfg "BIOS.addUserStartupFunction('&IpcMgr_ipcStartup')").

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Prodigy 130 points

    Ok, above advice worked.

    I now get an NS announcement (I rebuilt IPC lib to move to version RPMSG_NS_2_0 so I now get 72 bytes in that message).
    However in rproc_get_alias_id I get -19 (ENODEV).

    Again I am stuck. How does the alias ID get set?

    I am still getting no vrp and -22 on socket connect. I do get positive results on socket bind now. And bind can create 'HOST' key. But 'SLAVE_DSP' key is not found.

    -Doug

  • 0 in reply to Douglas Pepelko
    Prodigy 130 points
    Additional Info:
    Tracing into rproc_get_alias_id I find that the dev pointer looks valid but device node is null.
  • 0 in reply to Douglas Pepelko
    Prodigy 130 points
    I found an alternate rproc_get_alias_id which calls rproc_get_platform_id. That call succeeds but on the Linux host seems to return a "0". This is unexpected. I would have thought that a 1 (DSP) would be the id.
  • 0 in reply to Douglas Pepelko
    Prodigy 130 points

    The call to rproc_get_platform_id seems to work.  It returns 0 and that allows the probe to proceed.

  • 0 in reply to Douglas Pepelko
    TI__Mastermind 18260 points

    Douglas Pepelko said:

    I found an alternate rproc_get_alias_id which calls rproc_get_platform_id. That call succeeds but on the Linux host seems to return a "0". This is unexpected. I would have thought that a 1 (DSP) would be the id.

    ...

    The call to rproc_get_platform_id seems to work.  It returns 0 and that allows the probe to proceed.

    The DSPs id will generally be different between remoteproc (in kernel) and IPC.  IPC actually has a mapping between the two that is used internally.

    I'm glad to hear that you were able to get the probe to proceed, since I couldn't offer much help.

    Regards,

    - Rob