• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 102 subscribers
  • Views 2123 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.

AM57x Independent DSP Control

Gerard
Expert 1290 points
Other Parts Discussed in Thread: AM5728, OMAPL138

I realize that for the AM5728 the Processor SDK (Linux) powers on and loads both DSP cores automatically with images with a predefined filename.

I need to be able to power on and load different images on each DSP independently. I'm looking for some guidance as to the best approach for me to take to make this happen. I realize older versions of the IPC package provided APIs for this functionality which has since been removed.

Is the best approach to re-engineer the Linux remoteproc driver to not automatically power on/load the cores and instead do it via some IOCTL?

Is this kind of functionality in the TI roadmap?

Thanks

  • 0
    TI__Guru**** 393215 points
    I will ask the software team to comment.
  • 0 in reply to Biser Gatchev-XID
    Expert 1290 points
    Biser,

    Any update? This independent DSP control functionality is critical for my program.

    Thank you
  • 0 in reply to Gerard
    TI__Guru**** 393215 points
    Feedback will be posted directly here when available.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 390 points
    Gerard, do you have any findings on this subject ? I want to ask about same, so far we are using SYSLINK software with omapl138 which allows loading/starting/stopping DSP execution from ARM host CPU. We want to swith to AM57x Sitara but this functionallity is crucial for us.
  • 0 in reply to Embedded Solutions
    Expert 1290 points

    I did some initial digging - I had to pause the investigation to look at some other issues but here are some initial notes:

    • I never got a response to my questions from TI
    • My initial thought was that a re-engineering of the OMAP remoteproc driver to add some IOCTL control (to provide the independent control) would be the way to go
    • The Keystone remoteproc driver does just that: they have an IOCTL interface to control the remote processor state (I'm assuming the TI IPC package utilizes that interface)
    • I started modifying the OMAP remoteproc driver based on the Keystone implementation; the next step would be to prototype this with some user space application that utilizes the new IOCTL interface

    That's where I paused. Ideally none of my work would be necessary and TI would include this independent DSP/remote processor control functionality as it seems like a very common need/use case.

    TI - any update here? Is adding independent DSP/remote processor control in the road map for the OMAP remote processor driver utilized on the AM5728?

  • 0 in reply to Gerard
    TI__Guru* 80245 points
    Gerard,

    It is possible to load/boot different images on DSPs or IPUs supported by the OMAP remoteproc driver using sysfs interface without any changes, and do independent control. The firmware name expected by the OMAP remoteproc driver would still remain the same, you would have to just point it to the new image you would want to load. I use soft-links for the firmware image name expected by OMAP remoteproc driver to point to a new image, rather than copying over. Both work, but very easy to loose track of what image is currently loaded if you copy over.

    Eg for reloading a new image on DSP1:
    ln -sf <new firmware> /lib/firmware/dra7-dsp1-fw.xe66
    echo 40800000.dsp > /sys/bus/platform/drivers/omap-rproc/unbind
    echo 40800000.dsp > /sys/bus/platform/drivers/omap-rproc/bind

    In terms of roadmap, I don't intend to add any IOCTL interface to the OMAP remoteproc driver. The sysfs read/write can be coded into a userspace utility/application to load instead of making an IOCTL call. remoteproc/rpmsg is the upstream replacement solution for SysLink, with MessageQ interface from SysLink supported in IPC 3.x. That said, I am looking at the ability to set a custom firmware name, but this is gonna depend on upstream acceptance.

    regards
    Suman
  • 0 in reply to Suman Anna
    Expert 1290 points
    To follow up, I've been using this technique successfully. Thank you