• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 715 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

C6678 local reset errata

Joel Keller
Expert 1305 points

Hello,

Like many others, I am using the c6678 as a PCIe peripheral and have a linux driver which is able to load and run executable images on the DSP cores.

I have run in to the odd behavior described in the following posts (plus several others):

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/294703.aspx

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/327340.aspx

In each case, someone has pointed to the Advantech PCIE driver which contains the following comment:

/*-------------------------------------------------------------------------
* The following code is a work around to flush the cache, without this
* Any dirty cache lines in L1D may cause corruption of the downloaded
* image
*/

The code then proceeds to perform a workaround where a 8 instruction program consisting of only IDLE opcodes is written to 0xc0000000 (MSMCRAM).  The DSP cores are then brought out of reset to execute the IDLE loop program, then placed back in reset & have the "real" program loaded.

I am also using this workaround, and it appears to work.  I would like answers to the following 2 questions:

1).  Is the comment actually correct?  Does releasing the DSP core from reset not only invalidate the L1D cache, but actually perform a write-back?  Are there other important details/caveats? Is there any more detailed explanation on what is being worked around? an errata document entry?

2)   Are there any implicit requirements on the subsequent program that is loaded when using this workaround?  For example, should the 1st cache line of MSMCRAM not be used?  I'm guessing that it is okay to use, as the "IDLE program" should not cause any entries in L1D during its execution.  Correct?

Thanks,

Joel

 

  • 0
    Expert 1305 points

    Here are (hopefully) proper links to the E2E threads mentioned above:

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/294703.aspx

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/327340.aspx

    I'd really like to understand what is wrong with the local reset/cache invalidation mechanism that supposedly requires this workaround.   TI employees, can you please look in to this?

    Thanks in advance,

    Joel

  • 0
    TI__Genius 9065 points

    Joel,

    1) comment is correct. While we are working on a more detailed explanation, the silicon errata doesn't appy here.

    2) there is no implicit requirements on subsequent program.

    I am checking with design team on more explanations. I will keep you posted.

    regards,

    David

  • 0 in reply to dzhou
    TI__Genius 9065 points

    Joel,

    Releasing the DSP from lreset will invalidate the L1D cache, so all data is lost – this is true for the L1 and L2 caches.

    lreset will not perform a write back. If you need that data, it will need to be written back prior to asserting lreset.

    regards,

    David

     

  • 0 in reply to dzhou
    Expert 1305 points

    Hi David,

    Thank you for your reply.  That is indeed how the hardware documentation describes lreset.  However, previously you mentioned that the comment in the Advantech driver was correct:

    " Any dirty cache lines in L1D may cause corruption of the downloaded image"


    So, what is the issue being worked-around in the driver?   If the L1 & L2 caches are invalidated with no write-back,  how is the image corrupted?

    I ask because performing lreset over PCIe is critical to my application.  It must work completely reliably & robustly, therefore I really want to understand what is going on, and what caused these crashes. 

    Thanks for all your assistance,

    Joel

  • 0 in reply to Joel Keller
    TI__Guru* 95265 points

    Joel,

    We need to understand: the reason that your code could not run correctly because you have some dependency on L2 SRAM data, which is loaded during local reset and getting lost after release of local reset? Or you only have program/data in MSMC?

    Regards, Eric