• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 898 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.

Original question:

AM6548: Cache coherence questions

AM6548: Cache coherent issue on Non-sharable MMU attribute DDR area

Guohu Xu
Prodigy 70 points
Part Number: AM6548

Hi Ti experts,

I learned from the AM65X TRM and the E2E post() that the MSMC can handle the cache coherent issue when doing DMA transfer, which means it's not necessary to care the cache coherency before and after DMA transfer.

It really brings great performance benefits.

But in my situation, I need to set some DDR regions to Non-sharable MMU attributes as not intending to share those regions with other CPU cores.

Once setting the DDR regions to Non-sharable, the core cannot read the correct data from the memory which DMA destine to.

The data is incorrect even after doing cache invalidation on the DMA region.

I knew the MEM_ATTR tables in North Bridge and DRU may impact the result, so all the MEM_ATTR table entries have been set to Non-sharable(0x40), the result is same.

My questions are, can the AM65x handle the cache coherency upon Non-sharable MMU attribute regions by hardware?

If yes, how to achieve that?

If no, what's the operating sequence to guarantee the cache coherency?

Thanks and Best Regards,

Guohu Xu

  • 0
    TI__Mastermind 27050 points

    Hi Gouhu Xu,

    Are you executing DSB barriers after each SW cache management operation?

    "I need to set some DDR regions to Non-sharable MMU attributes as not intending to share those regions with other CPU cores" I'm not clear on why you need to try to get SW managed cache coherency working. What are you trying to achieve with not marking some area of DDR not-shared but still normal cacheable in an A53 when the HW supports coherency?

    Shareable can be used for both single core IO coherent traffic where only DMA/DRU and a single A53 share data or true SMP sharing. MSMC includes a snoop filter so there are no drawback to using shared memory and only having DMA and a single core access it.

      Pekka

  • 0 in reply to Pekka Varis
    Prodigy 70 points

    Hi Pekka,

    Thanks for replying promptly.

    "Are you executing DSB barriers after each SW cache management operation?"

    Yes.

    "I'm not clear on why you need to try to get SW managed cache coherency working. What are you trying to achieve with not marking some area of DDR not-shared but still normal cacheable in an A53 when the HW supports coherency?"

    The architecture code of our OS has been using Non-sharable MMU attribute for Unique Processor(UP) configuration from the beginning.

    Lots of other ARM platforms have been supported in the OS. It's preferred to have the ARM architecture code in unitized behavior. To achieve this goal, giving up some performance is accepted.

    If the cache coherency  is impossible for Non-sharable memory, we need to introduce some configuration constrains to allow the sharable memory in UP configuration for AM65x only, which may also be acceptable for us.

    Best Regards,

    Guohu

  • 0 in reply to Guohu Xu
    TI__Mastermind 27050 points

    Ok.

    My suggestion would still be to use normal cacheable shared memory and rely on HW cache coherency.

    We can still try to figure out why SW managed cache coherency does not work. Double checking the MEM_ATTR table entries match the MMU entries corresponding to the same 16MB area is critical for correct operation of coherent traffic. But here the intention is to run the DMA into DDR without coherency (traffic comes into MSMC through NB configuration), while still have the same DDR configured and writeback cacheable for A53. Could you try a different MEM_ATTR setting? MEM_ATTR table entries to 0x00 (device) or 0xC0 (non-cacheable), so the coherency logic thinks it is not cached as we pushed the responsibility for cache coherency to SW.

      Pekka

  • 0 in reply to Pekka Varis
    Prodigy 70 points

    Hi Pekka,

    Thank you very much for the suggestion.

    I tried the MEM_ATTR setting of 0x00(device) and 0xc0(non-cacheable), but the SW cache coherent operation still doesn't work in both cases.

    So we tend to change the Unique-Processor MMU attribute to sharable for AM65x.

    I'll mark this issue as resolved.

    But if you have further advice, please update the post.

    I'm happy to go further.

    Best Regards,

    Guohu