Slaveloader issue

Forgot to metion one more thing. The DSP image, with code ovelay,  is loading properly through CCS.

Elamparithi,

This is most likely a bug in slaveloader (or rather, in the loader code used by slaveloader). We will have to investigate and fix, which will probably take some time.

~Ramsey

Thanks for the response Ramsey.

It would be very helpful, if you give us the fix. This is very much needed for our codec's performance.

Regards,

Parithi

Elamparithi,

We are waiting to hear back from the RIDL team. It still remains to be determined if we will be able to fix this. I will certainly update this post when we have more information.

~Ramsey

Parithi, we heard back from the RIDL team (they provide the loader SysLink uses).  The loader _should_ be loading code into the 'load' address.  And since neither the loader nor SysLink provide any overlay support, it will be your responsibility to copy the code from load addr to run addr at the "right time" - much like is described here:
    http://processors.wiki.ti.com/index.php/CodecEngineCodeOverlays

Are you sure the loader's not loading the code to the load addresses?  If it's not, in your success case (without the UNION), can you successfuly load one of the codecs into L1PSRAM successfully (assuming both don't fit and that's why you want to overlay the memory)?  I just want to sanity check that, independent of overlaying, loading into L1PSRAM is working for you.

Chris

Chris, Thanks for the reponse.

Yes we are  coping code from load address to run address at run time.

I am sure that the loader is not loading the code to load address. To verify this, we corrupted some values in load address intentionally and then we loaded the image through slave loader. The expected result is that the slaveloader should modify the data we have corrupted by actual code, but it didn't modify those values.

Your assumption is TRUE, both section will not fit in to L1P, that's the reason we are using UNION. In success case(without the UNION)  loader is loader is loading the code in DDR properly as my load address is DDR.  I'll do the experiment of loading one the code section in to L1P and update you my findings.

Hi Chris,
I did some experiments for this issue. Please find the details and my observation below.

1) Without load/run, directly placed "ittiam_h264_mp_dec_ciram_1_1" code section in L1P
Command file snippet:
-------------------------------
              .ittiam_h264_mp_dec_ciram_1_1 : LOAD = L1PSRAM, ALIGN = 128
                             LOAD_START(g_h264_mp_dec_ciram_1_1_load_addr),
                              RUN_START (g_h264_mp_dec_ciram_1_1_run_addr),
                              LOAD_SIZE (g_h264_mp_dec_ciram_1_1_size)
Observation:
------------------
Slaveloader is loading the code properly in L1P. But in runtime it got corrupted after Ipc_attach() call. I couldn’t find the cause for this issue.
I have dumped the data after load (CCS_L1P.dat) and after the corruption (SlaveLoader_L1P_runtime.dat). This issue exists even if load the code through CCS.

2) Kept only one section in UNION as shown below.
Command file snippet:
-------------------------------
UNION run = L1PSRAM
  {
         .ittiam_h264_mp_dec_ciram_1_1 : LOAD = DDR3_DSP, ALIGN = 128
                             LOAD_START(g_h264_mp_dec_ciram_1_1_load_addr),
                              RUN_START (g_h264_mp_dec_ciram_1_1_run_addr),
                              LOAD_SIZE (g_h264_mp_dec_ciram_1_1_size)
  }
Observation:
------------------
Slaveloader is not loading the code in load address, instead it is loading the code in run address.

3) Same as experiment 2 But the run address is DDR3_DSP.
Command file snippet:
--------------------------------
UNION run = DDR3_DSP
  {
         .ittiam_h264_mp_dec_ciram_1_1 : LOAD = DDR3_DSP, ALIGN = 128
                             LOAD_START(g_h264_mp_dec_ciram_1_1_load_addr),
                              RUN_START (g_h264_mp_dec_ciram_1_1_run_addr),
                              LOAD_SIZE (g_h264_mp_dec_ciram_1_1_size)
  }
Observation:
------------------

Slaveloader is loading the code in run address, also the loaded data is differing in many places. Mostly it is one bit difference, please refer the dump UNION_Slaveloder_DDR.dat.

3823.Slaveloader_dump.zip

Elamparithi,

Thanks for all the good information. I've been able to reproduce the failure. We are investigating further to see what options we have. I'll update this thread with our findings.

~Ramsey

Thanks Ramsey. It's good to hear that you can able to reproduce the issue. Hope you find a solution for this.

-Parithi

Thanks Ramsey for the quick fix. I'll check this patch and let you know the update.

Thanks Ramsey,

This patch solves our issue. Thanks a lot for your support.

Elamparithi,

That's good news. Thanks for validating and giving us the update.

~Ramsey