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.

[OMAPL138] Hello DSPLink Program

Other Parts Discussed in Thread: OMAPL138, OMAP-L137, OMAP-L138, TMS320C6748

Hello,

I am looking for most basic examples on DSPLink specially for OMAPL138

(Hawkboard) For both Linux/Arm Side & DSP Side.

 

Examples specially what a DSP books teaches,Like convolution ,cross correlation ,FFT etc

even much simple apps like multiply a location of shared area by contanst by DSP etc will too suffice.

Sample programs in the DVSDK is too complex to be understood by students/new to 

DSP/ARM (OMAP).

 

Any help on this program,API documentation for Linux to Use dsplinkk.ko etc 

would be greatly appreciated.

 

Thx,

Alok

 

  • This example uses OMAPL137 SDK and EVM sample codes.  Can OMAPL138 use the codes directly?  

    Thanks

  • Kevin,

    I'm not 100% sure, but I think the code is at a high enough level to where it abstracts the board-layer differences if you compile using the L138 environment.

    -Tommy

  • Hi Kevin, Tommy,

    The Hello DSP example uses the OMAP-L137 BSL, so it needs adaptation to work with L138.

    For a DSPLink example for L138, please see:

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

    Or you can use any of the DSPLink examples inside the DSPLink installation that does not touch the hardware in the DSP side.

  • Hi,

     

    I'm going to try the hello DSP example on Omap-L138, is there a BSL available for Linux?

     

    Thanks,

    clliu

  • Hi clliu,

    Not sure if I understand.

    1) As  I mentioned before in this post, it would be better to start from the AudioSoc example if you are using OMAP-L138.

    2) The hello DSP example uses the OMAP-L137/C6747 BSL. This BSL is provided by spectrum digital that is the board manufacturer. The BSL is not for Linux, but it runs in the DSP core. The hello DSP example runs part of the code in the DSP core and that is why it uses the BSL as part of it.

    3) There is a BSL for OMAP-L138/C6748 from the Logic PD, the manufacturer of the board for OMAP-L138 that has some test codes, but the hello DSP example does not detail how to integrate Logic's code. For the BSL, go to LogicPD's web site. Click on the Kit Contents tab, at the bottom of the page click at: TMS320C6748 SOM-M1 GEL, CCS Setup, & BSL Files - you will need to create an account in their website if you do not have one already and download the files

  • Hi Mariana,

    Thanks,

    I've successfully compiled the helloDSP DSP side example to L138, here is what I did:

    1, Downloaded and unzipped the BSL package to /home/user/OMAP-L138_X_X_X_X/boards and changed the folder name to ./evmomapl138_v1 and the lib name to evmomapl138bsl.lib(btw, the proper way to do it is to modify the corresponding contents in Makefile and other project files).

    2, Modified the Makefile and project source files accordingly.

    3, Commented out  led_test() in tskMessage.c(I don't need to try it and will replace it with my one later).

    4, Changed all the SDRAMs in helloDSP.tcf to DDR.

    5, Changed SDRAM in helloDSP.cmd to DDR.

     It needed a few iterations to figured out what to modify.

     Then it's done.

    But I have two questions:

    1, Each time make clean  is run, the helloDSPcfg.h is deleted, and following make command will complain it can't find that file, so I have to either comment out the line '@rm -f *cfg.*' in Makefile or back up it somewhere and copy it back before make. It sounds like L137 compilation tools generate this file automatically during make every time and L138's doesn't. Is it true?

    2, The original content in helloDSP.cmd is:

    SECTIONS {
      .data:DSPLINK_shmBaseAddress: fill=0xC3F05000 {} > SDRAM
    }

    Now i've changed SDARM to DDR, should I change 0xC3F05000 to some other value that is specific to L138 EVM?

    That's the reason that although it can be compiled successfully,  I haven't physically run it on the board yet.

     

    clliu

     

     

  • Hi Everyone,

    After last post, tried to run helloDSP example, met problem even before  touching the executible, stuck on loading the dsplinkk.ko, got error message:

    insmod: error inserting 'dsplinkk.ko': -1 Invalid module format

    I knew it's because of the mismatch of the vermagic of dsplinkk.ko and kernel running on the experimentor board, tried to compile new dsplinkk.ko, met some problems, tried to solve these problems, then met even more problems, more and more problems coming to me. I am new to embedded linux, it takes time to make things running smoothly, but my project won't wait for me, and I'm just going to do some evaluation, so can any one provide a dsplinkk.ko that can run on my board?

     

    I'm using the experimentor kit from logicPD, its kernel info is:

     root@arago:/media/ram# uname -a
    Linux arago 2.6.31-rc7-davinci1-06298-g9f9abac #1 PREEMPT Thu Sep 17 17:49:44 IST 2009 arm

    Thanks,

    clliu

  • Ok, finally got dsplinkk.ko recompiled, base on the correct linux kernel, which is in DaVinci-PSP-SDK-03.20.00.06.

    Transferred 3 files to the board, dsplinkk.ko, helloDSP.out and helloDSPgpp, the the module loading is successful, the program running is failed.

    If adding +x to both  helloDSP.out and helloDSPgpp, stuck here:

    root@arago:/media/ram# ./helloDSPgpp helloDSP.out 2
    ========== Sample Application : helloDSP ==========
    Entered helloDSP_Create ()

    if  adding +x to  helloDSPgpp only, stuck here:

     root@arago:/media/ram# ./helloDSPgpp helloDSP.out 2

     

     Regards,

    clliu

  • Clliu,

    This looks like PROC_start API is waiting on a handshake. This can happen if the memory map on ARM and DSP side is different. Can you check if the memory map is same. Check if this link helps: http://processors.wiki.ti.com/index.php/Troubleshooting_DSPLink_configuration_issues#Problem:_PROC_start_failed_with_configuration_mismatch.2Ffailure

    Deepali

  • Hi Deepali,

    Thanks, but I don't understand how this could happen, as I never touched the settings in tci and tcf file besides changing SDRAM to DDR.

    The strange thing is that sometime can see this: Entered helloDSP_Create ()

    sometime can't.

     

    clliu

  • Clliu,

    If you suspect DSPLink API , you can enable trace. See here: http://processors.wiki.ti.com/index.php/Enabling_trace_in_DSPLink

    If you suspect other code, you will have to add some more print based logging.

    Deepali

  • It's been a few days, no much progress.

    What I have done is:

    1, Re-configured the dsplink using command:

    perl dsplinkcfg.pl --platform=OMAPL138 --nodsp=1 --dspcfg_0=OMAPL138GEMSHMEM --dspos_0=DSPBIOS5XX --gppos=ARM --comps=ponslrmc --trace=1 --DspTskMode=1

    This turns on the trace function.

    2, Re-build dsplink following this link: http://processors.wiki.ti.com/index.php/Building_DSPLink

     Made some modifications to use 3 script files instead of 2,

    paths.sh:

    #!/bin/sh

    # paths.tcsh

    # This file simply creates environment variables.  We will utilize

    # these variables in build_dsplink.tcsh by passing them on the

    # command line.

     

    export PERL_DIR=/usr/bin

     

    export ARM_BASE_BUILDOS=${HOME}/OMAP-L138_arm_1_00_00_11/DaVinci-PSP-SDK-03.20.00.06/src/kernel/linux-03.20.00.06

    export ARM_BASE_TOOLCHAIN=${HOME}/CodeSourcery/Sourcery_G++_Lite

    export ARM_BASE_CGTOOLS=${ARM_BASE_TOOLCHAIN}/bin

     

    # ARM_CGTOOLS_NAME is just a "helper variable" (i.e. not directly used in make)

    export ARM_CGTOOLS_NAME=arm-none-linux-gnueabi

     

    # ARM_CGTOOLS_VERSION is just a "helper variable" (i.e. not directly used in make)

    export ARM_CGTOOLS_VERSION=4.3.3

     

    export ARM_COMPILER=$ARM_BASE_TOOLCHAIN/bin/$ARM_CGTOOLS_NAME-gcc

    export ARM_LINKER=$ARM_BASE_TOOLCHAIN/bin/$ARM_CGTOOLS_NAME-ld

    export ARM_ARCHIVER=$ARM_BASE_TOOLCHAIN/bin/$ARM_CGTOOLS_NAME-ar

    export ARM_OSINC_TARGET=$ARM_BASE_TOOLCHAIN/$ARM_CGTOOLS_NAME/include

    export ARM_OSINC_PLATFORM=$ARM_BASE_TOOLCHAIN/lib/gcc/$ARM_CGTOOLS_NAME/$ARM_CGTOOLS_VERSION/include

     

    export DSP_BASE_CGTOOLS=${HOME}/OMAP-L138_arm_1_00_00_11/cg6x_6_1_9

    export DSP_BASE_SABIOS=${HOME}/OMAP-L138_arm_1_00_00_11/bios_5_41_02_14

     

    build_dsplink_gpp:

    #!/bin/sh

    # You shouldn't need to modify this file.  Only your paths should change

    # and that should be done in paths.tcsh.

    #

    # You should make this file executable and putting it in the "dsplink"

    # directory for your build.

    source ./paths.sh

     

    export MAKE_ARGS_ARM="DSPLINK=$DSPLINK BASE_CGTOOLS=$ARM_BASE_CGTOOLS TOOL_PATH=$ARM_BASE_CGTOOLS COMPILER=$ARM_COMPILER LD=$ARM_LINKER ARCHIVER1=$ARM_LINKER ARCHIVER2=$ARM_ARCHIVER LINKER=$ARM_COMPILER KERNEL_DIR=$ARM_BASE_BUILDOS BASE_BUILDOS=$ARM_BASE_BUILDOS BASE_OSINC=$ARM_BASE_BUILDOS/include OSINC_PLATFORM=$ARM_OSINC_PLATFORM OSINC_TARGET=$ARM_OSINC_TARGET BASE_PERL=$PERL_DIR"

     

    make -s -C $DSPLINK/gpp/src $1 $MAKE_ARGS_ARM

    build_dsplink_dsp:

    #!/bin/sh

    # You shouldn't need to modify this file.  Only your paths should change

    # and that should be done in paths.tcsh.

    #

    # You should make this file executable and putting it in the "dsplink"

    # directory for your build.

    source ./paths.sh

     

    export MAKE_ARGS_DSP="DSPLINK=$DSPLINK BASE_CGTOOLS=$DSP_BASE_CGTOOLS BASE_SABIOS=$DSP_BASE_SABIOS"

     

    make -s -C $DSPLINK/dsp/src $1 $MAKE_ARGS_DSP

     

    3, re-build helloDSP application for both GPP and DSP sides.

    when running the program, got thse messages from terminal console:

    ......

    ......

    Leaving _RingIO_init ()         status [0x8100]
    Entered _SYNC_USR_leaveCS ()
            csObj   [0x29020]
    Leaving _SYNC_USR_leaveCS ()    status [0x8000]
    Leaving PROC_attach ()  status [0x8000]
    Entered POOL_open ()
            poolId  [0x0]
            params  [0x281e0]
    Entered _SYNC_USR_enterCS ()
            csObj   [0x29020]
    Leaving _SYNC_USR_enterCS ()    status [0x8000]
    Entered DRV_Invoke ()
            drvObj  [0x29008]
            cmdId   [Á18e03f]

    or like this:

    ......

    ......

    Leaving _RingIO_init ()         status [0x8100]
    Entered _SYNC_USR_leaveCS ()
            csObj   [0x29020]
    Leaving _SYNC_USR_leaveCS ()    status [0x8000]
    Leaving PROC_attach ()  status [0x8000]
    Entered POOL_open ()
            poolId  [0x0]
            params  [0x281e0]
    Entered _SYNC_USR_enterCS ()
            csObj   [0x29020]
    Leaving _SYNC_USR_enterCS ()    status [0x8000]
    Entered DRV_Invoke ()
            drvObj  [0x29008]
            cmdId   [0xc018e03f]
            arg1    [0xbed8ac08]
            arg2    [0x0]
    Status: 8000
    Leaving DRV_Invoke ()   status [0x8000]
    EîÑ•Éÿ

    Each time it hung at almost the same place, please nothce the unreadable charactors.

    If run it with trace disabled, got these:

    ----- Before helloDSP_Main
    ========== Sample Application : helloDSP ==========
    Entered helloDSP_Create ()
    ----- After PROC_setup


    ----- Before helloDSP_Main
    ========== Sample Application : helloDSP ==========
    Entered helloDSP_Create ()
    ----- After PROC_setup


    root@arago:/media/ram# ./helloDSPgpp ./helloDSP.out 2
    ----- Before helloDSP_Main
    ========== Sample Application : helloDSP ==========
    Entered helloDSP_Create ()
    ----- After PROC_setup
    ----- After PROC_attach
    ----- After POOL_open
    ----- After MSGQ_open
    ----- After MSGQ_setErrorHandler
    ----- doDspCtrl !=  DSP_BootMode_NoBoot
    ----- After PROC_load


    root@arago:/media/ram# ./helloDSPgpp ./helloDSP.out 2
    ----- Before helloDSP_Main
    ========== Sample Application : helloDSP ==========
    Entered helloDSP_Create ()
    ----- After PROC_setup
    ----- After PROC_attach
    ----- After POOL_open
    ----- After MSGQ_open
    ----- After MSGQ_setErrorHandler
    ----- doDspCtrl !=  DSP_BootMode_NoBoot

    The messages started with dashes were added by me.

    My questions:

    1, the dsp application should be given the absolute name or just the name itself(it 's in the same directory with gpp exectable)? before adding './' to the dsp application name, proc_load() was never executed.

    As I am unable to boot the experimentor board through NFS, still failed after googling and trying many times, i copy the necessary files to the /media/ram using tftp and run there. The directory /home/root is too small to save the files. So:

    2, Is /media/ram the right place to run application?

    3, Why /home/root is so small?

    4, Combining 2 & 3, is the linux pre-built on the experimentor board ready to run application(sorry for this question, it may be out of boundary)?

    5, Should I have to re-build kernel and rootfs for running application on the board standalone?

    6, My current testing setup is: Windows XP host + Fedora 12 VMware client, the board connects to XP through a USB-ethernet adapter, compilation is done in Fedora, the biggest problem is the board can't ping fedora. Tried setting the NAT and brighed(Vnet0 + USB-ethernet adapter) mode of fedora network, no luck. Now have to ftp files to XP and tftp get to put them o the board. Any hints?

    Thanks,

     

     

     

     

     

     

     

     

  •  

    I have a few questions.

    1) Have you updated the mem variable in the Linux bootargs for the memory map that you are using?

    2) Can you share the BIOS version that you are using? I will check if the there is an overlap in the default timer which could be causing the hang?

    Deepali

  • Hi,clliu :

          Do you solve this problem? I am facing to this problem now. Can you give me some advices? Thank you!

  • Hi,Deepali:

          Can you give me some advices to solve this problem, I am facing to it now . Thank you !

  • Hi,Deepali:

          Can you give me some advices to solve this problem, I am facing to it now . Thank you !