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.

How does the syslink kernel pick up the shared memory slot for dsp on omapl1xx ?

Hi,

I'm just working on messageQ sample code coming from syslink beta1 package and it looks working on OMAPL137 EVM .
(syslink beta1 from http://software-dl.ti.com/dsps/dsps_public_sw/SysLink/index.html)

I almost understand how linux app/driver and dsp executable works, but I don't understand how the syslink kernel populates the information for physical shared memory slot (sr0 and sr1) for its works. I could not find the related source code... Does Anyone know the detail about that ? If possible, please let me know the information for the related code set.

Best Regards,

kawada

  • In Platform_loadCallback(), we are passing NULL pointer as an argument, so the code is doing the followings:

    1. get reset vector address form dsp executable(via its simbol) and then get Platform_SlaveConfig infomation from there.
    2. apply the byte offset of sizeof(Platform_SlaveConfig) to reset vector address and then get Platform_SlaveSRConfig  information from there.

    Now, Platform_SlaveSRConfig includes address information for sr0 and sr1 phy memory.

    I'm wondering if Platform_SlaveSRConfig information might come from the memory generated by xdctools with ti\syslink\samples\rtos\common\SysLinkSamples_common.cfg.xs ... To clarify this, I tried to find map file (*.map) from rtos side build context in order to check Platform_SlaveSRConfig information was lay down just like mentioned the above, but I could not find the map file...

    So, if my understanding is correct, I think xdctool intentionally arranges the memory map around reset vector... does anyone comment on this ?

    Best Regards,

    kawada