• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Subscribers 101 subscribers
  • Views 1807 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.

Questions about DSPLINK.

Misha
Intellectual 625 points
Other Parts Discussed in Thread: OMAP-L137, OMAPL138, OMAP-L138

I am developing a DSPLINK application on a custom target based on OMAP-L137 EVM.
The target runs @ 216 Mz, and is provided with 32M SDRAM.
The application uses SIO_Issue/Reclaim calls on DSP side to transfer data to ARM by way of CHNL_Issue/Reclaim calls.

DSP side:
IDE CCS 3.3.82.13
BIOS : 5.41.03.17
CGT: v6.1.13
DSPLINK: 1.65.00.01

ARM side:
OS: Linux 2.6.37
DSPLINK: 1.65.00.01

I need inspect the behaviour of CHNL_Issue/CHNL_Reclaim on ARM side.
I could enable the trace mode of ARM components:
I followed User Guide and Wiki explanations, however I could not reduce the amount
of console logging levels that actually slow down too much my application.
Setup of TRC_ENABLE() in file gpp/src/pmg/Linux/2.6.18/drv_pmgr.c is useless: once --trace=1, all debug levels appear to be always enabled.

[Tue Jul 15 15:29:44.172 2014] Entered CHNL_issue ()
[Tue Jul 15 15:29:44.172 2014]  procId [0x0]
[Tue Jul 15 15:29:44.172 2014]  chnlId [0x1]
[Tue Jul 15 15:29:44.172 2014]  ioReq [0xee26c]
[Tue Jul 15 15:29:44.188 2014] Entered DRV_Invoke ()
[Tue Jul 15 15:29:44.188 2014]  drvObj [0xf4058]
[Tue Jul 15 15:29:44.188 2014]  cmdId [0x6d03]
[Tue Jul 15 15:29:44.188 2014]  arg1 [0x40078c64]
[Tue Jul 15 15:29:44.188 2014]  arg2 [0x0]
[Tue Jul 15 15:29:44.188 2014] Entered _POOL_xltBuf ()
[Tue Jul 15 15:29:44.188 2014]  poolId [0x0]
[Tue Jul 15 15:29:44.188 2014]  bufPtr [0x40078b58]
[Tue Jul 15 15:29:44.188 2014]  xltFlag [0x200]
[Tue Jul 15 15:29:44.204 2014] Leaving _POOL_xltBuf ()  status [0x8000]
[Tue Jul 15 15:29:44.204 2014] Status: 8000
[Tue Jul 15 15:29:44.204 2014] Leaving DRV_Invoke ()  status [0x8000]
[Tue Jul 15 15:29:44.204 2014] Leaving CHNL_issue ()  status [0x8000]
[Tue Jul 15 15:29:44.204 2014] Entered CHNL_reclaim ()
[Tue Jul 15 15:29:44.204 2014]  procId [0x0]
[Tue Jul 15 15:29:44.204 2014]  chnlId [0x1]
[Tue Jul 15 15:29:44.219 2014]  timeout [0xc8]
[Tue Jul 15 15:29:44.219 2014]  ioReq [0xee26c]
[Tue Jul 15 15:29:44.219 2014] Entered DRV_Invoke ()
[Tue Jul 15 15:29:44.219 2014]  drvObj [0xf4058]
[Tue Jul 15 15:29:44.219 2014]  cmdId [0x6d04]
[Tue Jul 15 15:29:44.219 2014]  arg1 [0x40078c64]
[Tue Jul 15 15:29:44.219 2014]  arg2 [0x0]
[Tue Jul 15 15:29:44.219 2014] Entered _POOL_xltBuf ()
[Tue Jul 15 15:29:44.219 2014]  poolId [0x0]
[Tue Jul 15 15:29:44.235 2014]  bufPtr [0xee26c]
[Tue Jul 15 15:29:44.235 2014]  xltFlag [0x2]
[Tue Jul 15 15:29:44.235 2014] Leaving _POOL_xltBuf ()  status [0x8000]
[Tue Jul 15 15:29:44.235 2014] Status: 8000
[Tue Jul 15 15:29:44.235 2014] Leaving DRV_Invoke ()  status [0x8000]
[Tue Jul 15 15:29:44.235 2014] Leaving CHNL_reclaim ()  status [0x8000]

1) How can I actually select the enabling of different levels ?

I could not find in DSPLINK docs which is the correct management of CHNL_Issue or SIO_Issue
in case of errors.
2)Should such call be repeated until no error whatever results ?

In DSPLINK docs I found that is SIO_Issue call fails, the call can be repeated, but a previous SIO_flush
call must be executed.
3)What about CHNL_Issue errors ?

4)What about SIO_reclaim and CHNL_reclaim errors ?

5)Which are the constraints about allocation of SIO buffers ? Can they be allocated on external SDRAM ?

My application runs nicely for a long time on most of our targets, but on a small number of them after
some time the ARM core hangs completely (Linux drivers,console, and application appear to be frozen).
This problem occurs always when ARM executes a call to CHNL_Reclaim: the call never returns.
The DSP core is safely running: of course SIO_Issue calls continuously do report an error.
6)Any hint/suggestion about the fault origin  ?

Many thanks for your attention.

 

 

  • 0
    TI__Genius 12025 points

    Misha,

    For DSPLink trace, did you look at the following wiki page?

    http://processors.wiki.ti.com/index.php/Enabling_trace_in_DSPLink

    For user-level trace, there is no module level control. You can turn it off as described in the link above and then enable specific call sites by replacing PRINT_printf with just printf.

    For kernel-level trace, you should be able to control the trace level. There are two settings: 1) which module to enable, and 2) what level of trace. Unfortunately, you cannot set the level per module. The details are also in the wiki link above.

    Unfortunately, we don't have good examples of error handling. But, in normal operation, you should not get any errors. If you do get an error, simply trying again will probably not work. You will have to decode the error and find out what is wrong. Most errors simply validate the input arguments. Some errors relate to runtime resouce failures. The best I can suggest is to find where the error is raised in the code. Sometimes, just looking at the code will help. If not, post your specific error on the forum.

    I wonder if the Linux kernel hang is due to a memory leak. Maybe you can monitor /proc/meminfo while your program is running. Perhaps you will see memory loss.

    ~Ramsey

  • 0 in reply to Ramsey
    Intellectual 625 points

    Thank you for your prompt support.

    I followed http://processors.wiki.ti.com/index.php/Enabling_trace_in_DSPLink ,
    which actually is out of date for my installation: however I could patch myself the
    right files, and enable "all" debug levels: the problem is I could not limit their number..
    I could enable SET_FAILURE_REASON printouts, even if trace was disabled.

    I am actually resuming the project of a resigned colleague, and I found
    some "strange" results in the scripts he left for compiling ARM side DSPLINK.
    I hope you can solve my questions.

    1)Compilation is performed tharough kbuild, according to http://processors.wiki.ti.com/index.php/Building_DSPLink_with_kbuild
    Only dsplink.lib is created: User Guide states only that for DSP side
    other libs are necessary: dspdata.lib, dspmsg.lib and so on...
    Is dsplink.lib the only library required for ARM side ? (User Guide does not cover the topic, wiki only reports dsplink.lib and dsplinkk.ko)
    Application is actually links regularly with dsplink.lib only...and works.

    2)I found this "strange" message when compiling:
    Chosen DSP OS for DSP0:
              Identifier:   DSPBIOS5XX
              Description:  DSP/BIOS (TM) Version 5.XX

    ****************** ADVICE !!! ***************************
    Binaries for DSP can be generated at preferred location
    For example: --dsp0_temp=/home/dsplink/dsp<#>/bin

    Chosen GPP OS for selected DSP(s):
            Identifier:     ARM
            Description:    GIT LSP for OMAPL138/DA850 and ARM toolchain

    But the target is OMAP-L137 which is based on DA830 !

    dsplinkcfg.pl perl file is set up according to:

    perl ./config/bin/dsplinkcfg.pl --platform=OMAPL1XX --nodsp=1 --dspcfg_0=OMAPL1XXGEMSHMEM --dspos_0=DSPBIOS5XX --gppos=ARM --comps=ponslrmc --DspTskMode=1 --trace=0
    Is     --gppos=ARM correct ? Or different option is required ?

    3) http://processors.wiki.ti.com/index.php/Building_DSPLink 
    tells about an LSP package for Omap-l137. How can I found if such package is regularly installed on the development environment ?

    Many thanks.

    Misha.

     

  • 0 in reply to Misha
    Intellectual 625 points

    I believe this files in attached appoggio.zip can help you:

    1)build - kbuild based compilation script

    2)dbg.txt - console output during compilation.

    3)CURRENTCFG.TXT - compilation configuration.

    4)Makefile - kbuild Makefile.

    Regards.

    Misha.

     

    appoggio.zip
  • 0 in reply to Misha
    TI__Genius 12025 points

    Misha,

    Re #1. I am not familiar with the build script you sent me. Maybe it's an Arago recipe? I always build DSPLink using a makefile. There are three steps to building DSPLink.

    1. Configure the product for your platform and the components you want. This is done using the dsplinkcfg.pl perl script.

    2. Build DSPLink for the GPP. This step produces a user-mode library (dsplink.lib) which is linked in with your ARM application, and a Linux kernel driver (dsplinkk.ko) which you must install before you run your application.

    3. Build DSPLink for the DSP. This step produces several libraries depending on the components you selected in the configuration step.

    I have attached a makefile for OMAP-L138. I know that you are using OMAP-L137, but I don't have a setup for that device. I hope you can make the necessary change to my makefile for OMAP-L137. Also, you will need to edit the top of this makefile to specify the install paths for your products. Then you can build DSPLink with the following command:

    make -f dsplink_omapl138.mak dsplink

    If you want to build the samples as well, you can use the following command:

    make -f dsplink_omapl138.mak samples

    Re: #2. I think you can ignore the message regarding OMAP-L138. It is probably just a typo in the script. Your configuration options look correct.

    Re: #3. I don't understand your question. I did not find a download link for the OMAP-L137 LSP on that page.

    The latest (and final) version of DSPLink is DSPLink 1.65.02.09. You can download it from this link. Maybe you want to update to it.

    http://downloads.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/DSPLink/index.html

    Have you considered using OMAP-L138 LCDK? This is the latest development kit and supports newer software. There is very little support for DSPLink. Here is the home page.

    http://processors.wiki.ti.com/index.php/L138/C6748_Development_Kit_(LCDK)

    Here is a link for software version information.

    http://processors.wiki.ti.com/index.php/OMAPL138_SW_%26_HW_Comparison

    ~Ramsey

    dsplink_omapl138.mak
  • 0 in reply to Ramsey
    Intellectual 625 points

    Hi Ramsey,
    thank you your attention to my questions.

    Re #1. I am not familiar with the build script you sent me. Maybe it's an Arago recipe?
    No, it is a Linux script I designed to automate the building of DSPLINK versions
    and integrate them into my projects...I believe it actually works safely.

    Have you considered using OMAP-L138 LCDK?
    The device we are designing is about to be delivered to market, so we cannot change
    OMAP...Still we cannot figure if the problem I told you is caused by software or hardware...
    It is surely related with the internal Shared Ram...
    Unfortunately enabling trace in DSPLINK is slowing down the device too much.

    I am now going to update the DSPLINK drivers to 1.65.02.29....

    1)Is the patch referred in:
    http://processors.wiki.ti.com/index.php/Building_DSPLink_with_kbuild
    required even for 1.65.02.29 ?

    If 1.65.02.29 will not solve the problem, I will be compelled to patch the drivers of the ARM side myself...

    2)Have you any news about Shared Ram problems for some production lots...?

    Thank you for your support.

    Misha.

     

  • 0 in reply to Misha
    Guru 26430 points

    There is some oddness with in your CURRENTCFG.MK. There are references of C64XX instead of c674x. Updating to the latest of 1.65.02.09 would be a good idea. Maybe a bug in the perl script. Several years ago, I built DSPLINK 1.65.00.03. That one needed the ioctl() patch. I used dsplinkcfg.pl argument "--comps=ponslrmsc". I don't know if the extra "s" matters. With my version of DSPLINK, it is hard-coded to use the upper 32MB of 64MB for DSPBIOS and DSPLINK. The kernel is limited to lower 32MB. As is, it might not work on a 32MB system.

  • 0 in reply to Norman Wong
    TI__Genius 12025 points

    Misha,

    You do not need the patch for building DSPLink 1.65.02.29. The makefile I gave you should work fine.

    I don't know of any hardware issues regarding memory on the OMAP-L137. You might try posting your question on the OMAP hardware forum.

    http://e2e.ti.com/support/dsp/omap_applications_processors/default.aspx

    I assume your are placing SR_0 in external memory? Or are you putting it in the on-chip memory? Either one should work fine, but you only have 128 KB of L3 memory.

    ~Ramsey

  • 0 in reply to Norman Wong
    Intellectual 625 points

    Norman,
    many thanks for your very interesting warning....
    With my version of DSPLINK, it is hard-coded to use the upper 32MB of 64MB for DSPBIOS and DSPLINK.

    I hope you can give me additional clarifications.

    1)For "my version of DSPLINK" do you mean the standard 1.65.00.03 ?

    2)Where in 1.65.00.03 sources did you figure out the upper 32MB of 64MB usage ?

    3)According to you, is it possible to patch 1.65.00.03 sources in order to use lower 32MB for DSPLINK and kernel ? Or some other constraints are pending ?

    If 1.65.00.01 actually uses upper 32MB of 64MB in a 32 MB target, the explanation for the target to work
    could be that 1.65.00.01 upper 32MB memory allocation ranges are "mirrored" in ranges of  target 32MB memory which do not interfere with other kernel/user space processes...   

    I am longing for your advice....

    Thank you for your attention.

    Misha.

                  

     

     



     

     

  • 0 in reply to Ramsey
    Intellectual 625 points

    Ramsey,
    thank you very much for your continuous support.

    Will you please tell me what do you mean for SR_0 ? (sorry for the question if it is silly...)
    I assume your are placing SR_0 in external memory? Or are you putting it in the on-chip memory? Either one should work fine, but you only have 128 KB of L3 memory.


    ~Misha

     

  • 0 in reply to Misha
    Guru 26430 points

    In DSPLINK 1.65.00.03:
    0xC0000000 = Base address of DDR RAM
    0xC2000000 = Start of upper 32MB
    0xC4000000 = One past the upper 32MB

    DSPLINK:

    dsp/inc/DspBios/5.XX/OMAPL1XXGEM/dsplink-omapl1xxgem-base.tci
    RESET_VECTOR.base = 0xC3E00000 ;
    RESET_VECTOR.len  = 0x00000080;
    SDRAM.base        = RESET_VECTOR.base + RESET_VECTOR.len ;
    SDRAM.len         = 0xFFF80;
    DSPLINKMEM.base   = SDRAM.base + SDRAM.len;
    DSPLINKMEM.len    = 0x30000;
    POOLMEM.base      = DSPLINKMEM.base + DSPLINKMEM.len ;
    POOLMEM.len       = 0xD0000 ;

    I think these are autogenerated.
    Linker command files:
    dsp/BUILD/OMAPL1XXGEM_0/LOOP/BIOS_*/loopcfg.cmd
    dsp/BUILD/OMAPL1XXGEM_0/MESSAGE/BIOS_*/messagecfg.cmd
    dsp/BUILD/OMAPL1XXGEM_0/MESSAGE_MULTI/BIOS_*/message_multicfg.cmd
    dsp/BUILD/OMAPL1XXGEM_0/MPCSXFER/BIOS_*/mpcsxfercfg.cmd
    dsp/BUILD/OMAPL1XXGEM_0/MP_LIST/BIOS_*/mp_listcfg.cmd
    dsp/BUILD/OMAPL1XXGEM_0/RDWR/BIOS_*/readwritecfg.cmd
    dsp/BUILD/OMAPL1XXGEM_0/RING_IO/BIOS_*/ring_iocfg.cmd
    dsp/BUILD/OMAPL1XXGEM_0/SCALE/BIOS_*/scalecfg.cmd

    Typical memory definition in linker command files:
    MEMORY {
       RESET_VECTOR : origin = 0xc3e00000,  len = 0x80
       SDRAM        : origin = 0xc3e00080,  len = 0xfff80
       DSPLINKME M  : origin = 0xc3f00000,  len = 0x30000
       POOLMEM      : origin = 0xc3f30000,  len = 0xd0000
    }

    Not sure if this file is autogenerated.
    config/BUILD/CFG_OMAPL1XXGEM_SHMEM.c
    config/all/CFG_OMAPL1XXGEM_SHMEM.c
    #define  RESETCTRLADDR      0xC3E00000

    For LINUX/U-BOOT:
    U-Boot tells Linux how much memory to use here:
    include\configs\da830.h
    #define CONFIG_BOOTARGS ..."mem=32M"...

  • 0 in reply to Misha
    Guru 26430 points

    A bit of searching:

    http://processors.wiki.ti.com/index.php/Changing_DSPLink_Memory_Map

    Odds are somebody else has encountered the problem. The cursed are the first ones.

  • 0 in reply to Norman Wong
    TI__Genius 12025 points

    Misha,

    Re: SR_0. Sorry, I was mixed up with another thread. SR_0 refers to Shared Region #0, which is used by SysLink, not DSPLink. You can ignore that comment.

    I'm wondering if you found a solution because this thread is marked as answered. If not, would you help me to re-focus by stating the problem again. I think you were trying to work out the correct error handling for CHNL (on ARM) and SIO (on DSP). Have I got this correct? Is that still your focus?

    Have you looked at the loop sample?

    dsplink/gpp/src/samples/loop/loop.c
    dsplink/dsp/src/samples/loop/tskLoop.c

    Thanks
    ~Ramsey

  • 0 in reply to Norman Wong
    Intellectual 625 points

    Thank you Norman,

    I will keep you informed as soon I can switch to the DSPLINK problem again.

    P.S. About the first ones...I know myself what your statement means....!

    Misha.

  • 0 in reply to Ramsey
    Intellectual 625 points

    Ramsey,

    Thank you for your support.
    The thread was marked as "solved" by me for a mistake.
    Yes, I already looked at the loop samples.
    Unfortunately I was forced to switch to another thread.
    As soon I can resume this thread and possibly find other issues I will check your suggestions
    and acknowledge your support.

    ~Misha.