dsplink config

sandeep kalra said:

1. There is no reset-ctrl section in the dsp image that i got. Do I need to write one small dsp program that I download to RESETCTRL address to reset the DSP?

You don't necessarily need a section named RESETCTRL, but you do need some section for it.  This section would be uninitialized, and DSPLink will use it to write a special "reset vector" stub that is used as the program starting point after the DSP is released from reset.  This vector will simply branch to the program's entry point (typically _c_int00).  This vector is separate from your regular runtime vector table.

So, once you carve out the 0x80 bytes needed for this usage, you point to it by setting RESETCTRLADDR (in your CFG_*.c file) to the base value of this section.

sandeep kalra said:

2. Shall I mention the whole address range (11800000 - c40000000 ) in DSPLink DATA section(CFG_xxx.c)?

or , can i remove all the existing sections in the CFG_##.c file, and introduce these 5 sections?

No, one big address range would surely eat up all the virtual space in Linux.

You should remove existing sections and put in your own.

sandeep kalra said:

3. Is there a DSPLink document explaining what these existing sections in CFG_XXXX.c and .tci file means?

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

Regards,

- Rob

Hi Rob,

Thanks for the suggestion.

I have made changes in the CFG and .tci files as per your suggestion , and to some extend the problems are resolved, but i still see runtime error related to pool initialization. I am attaching all the config files and also the error log. If possible, kindly suggest me areas where I need to change further.

Regards,

Sandeep

Hi Sandeep,

Maybe your POOL entry Id is off.  You can take a look at this:

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

Best regards,

    Janet

Thanks Janet, it was off, and my u-boot hole was smaller than what was required for the application.

I am now able to PROC_setup, PROC_attach and POOL_open.

Now I am stuck with PROC_load. It fails with error DSP_EFAIL,

Hi Sandeep,

Good to see you found the POOL problem.  To figure out why PROC_load() is failing, you can enable DSPLink trace.  Here is a wiki article on how to do that:

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

Best regards,

    Janet

Here is what I am seeing after I enabled the tracing in DSPLink. 

Failure status [0x80008008] File [0x200] line [909]

As suggested, I looked at the entry Ids, but could not see any obvious mistake. I am new to DSP work, and DSPLink.. so I must be doing something wrong...Is it possible to do a double check at your end?

I am attaching a zip with detail error_logs, the coff_executable_image.map file, the dsplink kernel .tci file, and also CFG_ files that I modified.

Also, my u boot parameters looks like this:

setenv bootargs console=ttys2,115200n8 noinitrd rw mem=32M@0xc0000000 mem=32M@0xc6000000 root=/dev/nfs nfsroot=${serverip}:/rfs,nolock ip=dhcp

Regards\

Sandeep

Sandeep,

I'm not sure why PROC_load() is failing, because the trace is only showing messages from the User side.  I think you should enable trace on the Kernel side too.  You can look at the DSPLink User's Guide, chapter 30 "Debugging Applications" for all the details, but basically:

1. Re-run the dsplinkcfg script with the --trace=1 option, for example:

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

2.  In the file dsplink/gpp/src/pmgr/Linux/2.6.18/drv_pmgr.c, enable PROC trace by uncommenting lines:

            TRC_ENABLE (ID_LDRV_PROC)       ;

            TRC_SET_SEVERITY (TRC_ENTER) ;

3.  Rebuild your dsplink.ko, dsplink.a, and app.

If you don't get enough information, you can try uncommenting more lines in drv_pmgr.c, but I think PROC trace is a good start.

Best regards,

    Janet

attached is the new err file.

oops, forgot the attachment

Hi Sandeep,

I still don't see any kernel trace in your log.  Did you insmod the new dsplink.ko?  Also, when you ran the dsplinkcfg step with --trace=1, did you copy the line I had posted?  That was just meant to be an example that I pulled from the Install guide.  Your trace is now showing RingIO that was not in your previous trace.  Was that intentional?  If not, please check your dpslinkcfg --comps option.  Your DSP and Arm apps must both be built with the same components, otherwise PROC_start() could fail.

Best regards,

    Janet

I am sorry, I will do another build and give you the traces  soon.

Status: 8000
Leaving DRV_Invoke ()   status [0x8000]
Leaving _IDM_USR_acquireId ()   status [0x8000]
Leaving _SYNC_USR_createCS ()   status [0x8000]
Leaving _MPCS_OS_open ()        status [0x8000]
Leaving MPCS_open ()    status [0x8000]
Leaving _MPLIST_init ()         status [0x8000]
Entered _SYNC_USR_leaveCS ()
        csObj   [0x14c020]
Leaving _SYNC_USR_leaveCS ()    status [0x8000]
Leaving PROC_attach ()  status [0x8000]
PROC_ATTACH SUCCESS
Entered POOL_open ()
        poolId  [0x0]
        params  [0x50308]
Entered _SYNC_USR_enterCS ()
        csObj   [0x14c020]
Leaving _SYNC_USR_enterCS ()    status [0x8000]
Entered DRV_Invoke ()
        drvObj  [0x14c008]
        cmdId   [0xc018e03f]
        arg1    [0xbeb0fc40]
        arg2    [0x0]
Status: 8000
Leaving DRV_Invoke ()   status [0x8000]
Entered _SYNC_USR_leaveCS ()
        csObj   [0x14c020]
Leaving _SYNC_USR_leaveCS ()    status [0x8000]
Leaving POOL_open ()    status [0x8000]
Pool_Open SUCCESS.
Entered PROC_load ()
        procId  [0x0]
        imagePath       [0x38e90]
        argc    [0x0]
        argv    [0x0]
Entered _SYNC_USR_enterCS ()
        csObj   [0x14c020]
Leaving _SYNC_USR_enterCS ()    status [0x8000]
Entered DRV_Invoke ()
        drvObj  [0x14c008]
        cmdId   [0xc018e015]
        arg1    [0xbeb0fc44]
        arg2    [0x0]
Status: 80008008
Leaving DRV_Invoke ()   status [0x80008008]

Failure: Status:[0x80008008] File:[0x200] Line:[909]
Entered _SYNC_USR_leaveCS ()
        csObj   [0x14c020]
Leaving _SYNC_USR_leaveCS ()    status [0x8000]
Leaving PROC_load ()    status [0x80008008]
ProcLoad Failed. Status = 0x80008008

Looking at the code, it looks like driver fails to get semaphore in PROC_load()------->_SYNC_USR_enterCS()---->waits for semaphore (else EFAIL)

One more thing I wanted to add here. I have followed all steps to enable kernel logs as in chapter-30, but the above logs are all I am getting.

There are my steps:

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

modified drv_pmgr.c (DRV_InitializeModule()) to enable _PROCs, set severity to LEVEL6.

I even upgraded from DSPLink1.65.01.05_eng, to DSPLink1.65.02.09 to see if that helps, but there was no change in behavior.

Hi Sandeep,

Could you try adding a printk() to one of the dsplink kernel source files (eg, drv_pmgr.c), and see if you at least get that?  Kernel prints go out the serial port, so you need to have a serial port connection to view them.

Thanks,

    Janet

Hi Sandeep,

I'm glad you were able to get the kernel trace now.  It looks like your memory map on the DSP is not matching the Arm side.  Here are some links you may find useful:

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

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

You must have made changes to CFG_OMAPL138GEM_SHMEM.c and not updated dsplink-omapl138gem-base.tci.

Best regards,

    Janet

Janet,

I have already uploaded all the files(CFG and .tci, and also memory map) in zip format(in earlier messages) . I am not very good in understanding map files to fill CFG_<platform>.c and .tci, and i am suspecting that there is some problem in them..

Is there a possibility that you can take a look at them ?

Regards

Sandeep

Sandeep,

It looks like "DSPLINKMEM1" (SHAREDMEMORYADDR1) in the Arm config is where you have the POOL config on the DSP.  Maybe that is the problem?

Best regards,

    Janet

Thanks a lot Janet.