• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 1798 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.

RTOS/AM5728: ARM-DSP mailbox usage conflict

Christopher Peters
Genius 3380 points
Part Number: AM5728

Tool/software: TI-RTOS

AM5728 on custom board, DSP running TI-RTOS and ARM running Linux, both on latest Processor SDK 4.0.0.4.

At the conclusion of this thread, https://e2e.ti.com/support/arm/sitara_arm/f/791/t/604259, it was decided for our purposes to abandon the use of MessageQ due to its usage of a SWI and the resultant task preemption, and use a custom messaging implementation that will use MAILBOX to interrupt the DSP/ARM as needed.  This sounded pretty easy, but as the say, the devil is in the details. 

The intent on the DSP side was to copy the code from "C:\ti\ipc_3_46_00_02\packages\ti\sdo\ipc\family\tda3xx\InterruptDsp.c" and use that in my CCS project to setup the Mailbox for DSP->ARM and ARM->DSP interrupts. 

However, as the ARM developer looked into this, he brought up the idea that we use remoteproc to load the DSP and remoteproc might be using Mailbox and thus we would have a conflict.

So, the question here is this, if on the DSP side I no longer use MessageQ, will I be able to setup and use the Mailbox's as is used in the code referenced above, or we need to find some way to play along with it, like adding a special case to call our messaging callback?  Similar question for the Linux side of course.

Thanks,

Chris

  • 0
    TI__Guru**** 161600 points
    RTOS team is notified. Feedback will be posted here.
  • 0 in reply to Yordan Kovachev
    TI__Mastermind 43296 points
    Chris,

    I am trying to get confirmation from the remoteproc developer and see if any workaround/solution to alleviate the potential conflict of mailbox usage.

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Genius 3380 points
    Alternate question would be is there another method for the ARM and DSP to interrupt each other? We do not have any GPIO crossconnected, so that is not an option.
  • 0 in reply to Christopher Peters
    TI__Mastermind 43296 points
    Chris,

    Sorry for the late response. Some updates from development team:
    1. Remoteproc framework doesn’t impose any constraints on what software stack you run on the slave processor. That said, our current deliverable is integrated closely with certain features like the rpmsg-based transport, some pre-defined mailbox messages for PM and Error Recovery purposes.

    2. There is nothing stopping a customer from picking a different set of mailboxes and use them in a custom driver to be able to communicate with their image on DSP-side. However, any memory addresses etc would have to be retrieved from remoteproc core, and the custom driver has to be tied to the remoteproc statemachine somehow if you are not planning to use rpmsg transport.

    3. you can always define separate mailbox channels in DT and use them in their custom driver. The IPC driver integration with remoteproc boot state-machine may need some custom glue logic though to tie into the remoteproc’s state machine.

    There is no IPCGRx registers in AM572x for inter ARM/DSP interrupt as in Keystone 2 device. With above guidance, hopefully you can move forward.

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Genius 3380 points

    Thanks for the reply Garrett.  This is going to take some digesting to be sure.  Couple of clarifications though...

    1)  You mention "remoteproc statemachine" and "remoteproc boot state-machine".  I assume those are the same.  Can you point me to the code for that?  Is that Linux or DSP RTOS or both?

    2)  Is says, "mailbox channels in DT".  Sorry, but what is DT?

  • 0 in reply to Christopher Peters
    TI__Mastermind 43296 points
    Chris,

    1) Yes, the 'remoteproc statemachine' and 'remoteproc boot state-machine' refer to the same. The code is located in Linux kernel drivers/remoteproc/omap_remoteproc.c.
    2) DT stands for Linux Device Tree - data structures of device/board info for kernel boot up, see Linux kernel arch/arm/boot/dts

    Some mailbox related documents are in

    Documentation/devicetree/binding/remoteproc/ti,davinci-rproc.txt
    Documentation/devicetree/binding/mailbox/omap-mailbox.txt
    Documentation/devicetree/binding/mailbox/ti,message-manager.txt

    and as an example, the dts configuration for mailbox used by IPC
    am57xx-beagle-x15-common.dtsi: mboxes = <&mailbox6 &mbox_dsp2_ipc3x>;

    Regards,
    Garrett