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.

Linux/BEAGLEBOARD-X15: How to offload generated .out file on DSP, from Cortex A15 running Linux?

Part Number: BEAGLEBOARD-X15
Other Parts Discussed in Thread: AM5728,

Tool/software: Linux

Hi

I have compiled a simple C code for DSP using ti_cgt_c6000 tool. The result is a .out file which must be offloaded to DSP. There are some tools like DSPLINK and DSP-Bridge which seem outdated and not supporting AM5728. Is that right? If yes, I know that I have to use IPC. Should I switch to TI-SDK Linux? Isn't there any approach to load the .out file to DSP from usual Linux?

  • Hi,

    To be precise, you need to use remoteproc to download the binary to DSP. Please refer to the section of "Run IPC Linux examples" in Linux IPC Quick Start Guide, http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_IPC.html#ipc-quick-start-guide
     
    A note on this which you may have known is that the DSP application needs to include the resource table. It is not needed for standalone DSP application. The resource table is communicated to Linux on what resources is needed by remote processors. For info on resource table, please refer to the RTOS IPC User Guide on Resource Table: processors.wiki.ti.com/.../IPC_Resource_customTable

    Rex

  • Thanks for your fast response

    Looking at the links made two questions for me. One old and one new.

    The first link contains the word "RTOS". As I asked, Do I have to install it or any other SDK to be able to target the DSP? Isn't there any solution to stay with the current Linux image that I have download from beagleboard-x15 site (beagleboard.org/latest-images)

    and the second question: All TI documents which explain using IPC for DSP, are running a .xe66 file. How can I change that .out file (generated from ti_cgt_c6000 compiler) to a .xe66 file?

  • I modified the first link after I posted it. I can't remember if I copied the link from RTOS page. The change was meant to correct the url from Linux IPC User Guide to one level down to IPC Quick Start Guide. If I understand correctly, the beagleboard.org downloads Linux Processor SDK nightly and run its nightly test. So, it should have the same features as Linux Processor SDK.
    I am not familiar with the images (or the debian distribution) from beagleboard.org site, but you may want to see if there is any indication that remoteproc is supported, like if /lib/firmware has dsp images as indicated in the next paragraph, or if direcotry exists for remoteproc, /sys/kernel/debug/remoteproc/..., /sys/bus/platform/drivers/omap-rproc/.., "lsmod | grep rproc", or lsmod and grep for rpmsg, etc. RTOS SDK will only be needed if you are doing RTOS development. You would use APIs the packages in SDK.

    Remoteproc during Linux kernel coming up, it checks a particular file name to download to other cores. To distinguish between DSP and M4 binaries, the binaries have different file extension, xe66 for DSP C66 cores, and xem4 for M4 cores. For AM57xx platforms, remoteproc search for dra7-dspX-fw, dra7-ipuX-fw, or dra7-pruX-fw files in /lib/firmware to download. These are just naming convention. You can either rename your .out file accordingly or "ln -s" your .out file to .xe66, but again, resource table is needed in the .out file if Linux is running on ARM.

    Depending on how much DSP programming involved, you could use different mechanisms. In the Linux IPC page, there is a document of "Multiple Ways of ARM-DSP communication", software-dl.ti.com/.../Foundational_Components_IPC.html
    Since you mentioned in your post that you wrote a DSP application, the OpenCL may not be what you want, and eventually pointed you to IPC.

    Rex
  • Hi Rex

    Thanks for the rich explanations

    I just checked the directories you mentioned and the good news is that the Debian image provided by beagleboard has all the things you mentioned. Now I can soft link the  dra7-dsp1-fw.xe66 to my .out file and reload the DSP1 with this executable. But to run it, I must have the app_host file as stated in the link:

    and this "app_host" is in the ex02_messageq example which itself is in the RTOS SDK as stated in the link:

    could you please provide me a zip file containing this example? I don't want to install RTOS SDK just because of this example.

    Zana

  • Hi, Zana,

    Do you just need the binary of app_host? All IPC example binaries are located in /usr/bin/ipc/examples. You may want to start with both host and dsp binaries of ex02_messageq in the release package instead of your .out file as the baseline. The app_host is written as an messageq example to work with that for DSP. It may not work with your dsp application.

    If you want the source code of ex02_messageq, please install RTOS SDK to get it.

    Rex
  • Hi Rex

    Unfortunately, there is no /usr/bin/ipc/examples files or directory in the beagleboard debian image. So I guess I have to install both ti-processor-sdk as well as ti-rtos. 

    Just one question:

    Can you give me a rough estimation of OpenCL's overhead compared to using IPC? Which one do you think to be faster? Let me explain that I will use pure C/C++ code with IPC and don't use any DSP directives for optimization in my C/C++ code. My goal is to implement a high-level image processing algorithm and offload some parts of it to DSP for sake of acceleration. 

    Zana

  • Hi, Zana,

    You should be able to take the ipc exmples from Linux filesystem in the Linux ProcSDK release package. RTOS SDK isn't needed unless you want to take a look at the source code or rebuild the examples.

    We don't have the overhead measuremeant. I searched on internet and the overhead is not the call itself, but the compilation and transferring data. Here is the link and you may get some idea from it,
    stackoverflow.com/.../the-overhead-of-a-opencl-or-cuda-call

    I don't mean to confuse you with different redirections on how your project should do. For image processing, have you looked at the OpenCV in Processor SDK Linux Developer's Guide,
    software-dl.ti.com/.../Foundational_Components_OpenCV.html

    With OpenCV, you should be able bypass IPC sending messages between ARM and DSP. Hope this help in some degree.

    Rex