• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 265 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.

out of range error: PROC_load failed to load DSP Executable

Kalaiyarasan ES
Intellectual 680 points
Other Parts Discussed in Thread: OMAPL138

Hi ,

    I am using omapl138 for our project. We are using  "dvsdk_omapl138-evm_04_03_00_06_setuplinux". 

In our project we are Dsplink, ARM boot up. Once Linux comes up our application will boot DSP.

We are facing problem, We are not able to boot DSP using PROC component in DSPLINK. 

We are getting out of range error. When our application tries to load DSP  Executable using PROC_load.

Then we found problem with DSP code placement. Some part of DSP code is placed  in 128K shared RAM (between ARM & DSP).

 When we see Linux memory map using command   "cat /proc/iomem". We found 128K RAM is used by PRUSS.0

Can you please explain. 

                        is  128K RAM used by ARM? for What purposes?

                       can we use 128K for our application from DSP?

                       Please explain what is the PRU and its use.  Where can i get information about PRU.

                     Can we rebuild  DSPLINK by changing configuration to support 128K shared RAM. if yes What are changes we have to do?

Thanks & Regards

KalaiyarasanES

  • 0
    TI__Mastermind 18260 points

    Hi Kalaiyarasan,

    I don't have any particular knowledge of the PRUSS itself, I'm responding on behalf of DSPLink support...

    Kalaiyarasan ES said:
    is  128K RAM used by ARM? for What purposes?

    I would guess that the only ARM usage of that 128K shared RAM (L3_CBA_RAM) is by the PRUSS driver.

    Kalaiyarasan ES said:
    can we use 128K for our application from DSP?

    I would assume so, as long as you can prevent PRUSS from using it.  PRUSS contains a kernel module, which can be either built-in to the Linux kernel or built as a loadable module.  In the case of the loadable module, I believe it is named uio_pru.ko, and you can either just not "modprobe uio_pru.ko" (if you're somehow doing that now) or you can remove it with "rmmod uio_pru".  If it's built-in to the kernel, you would need to unconfigure it in the kernel's configuration and rebuild the kernel.

    Kalaiyarasan ES said:
    Please explain what is the PRU and its use.  Where can i get information about PRU

    Here is a good starting point: http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader.  There are other links on that page that you might want to follow to learn more about PRUSS.

    Kalaiyarasan ES said:
    Can we rebuild  DSPLINK by changing configuration to support 128K shared RAM. if yes What are changes we have to do?

    I would imagine that your DSPLink and DSP code are already set up to use the 128K shared RAM, since you stated that "Some part of DSP code is placed  in 128K shared RAM (between ARM & DSP)."  The DSP executable is built according to its memory map, and the DSPLink configuration C file must contain a matching memory map (which is used by the DSPLink kernel driver to map those sections into the ARM memory for loading the DSP and communicating between the ARM and DSP in the DSPLINKMEM sections).

    If you do wish to change the DSP's memory map, you can do that but must also change the DSPLink configuration C file.  See here for instructions on that: http://processors.wiki.ti.com/index.php/Changing_DSPLink_Memory_Map

    Regards,

    - Rob