Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

AM6548: About STREX/LDREX between two clusters.

Part Number: AM6548

Tool/software:

Hi, support team!

The STREX/LDREX instructions should undoubtedly work effectively within CC_ARMSS0, but will they function properly between CC_ARMSS0 and CC_ARMSS1?

  • Yes, when set up for coherent SMP, like our Linux, the load store exclusives work using the A53 L2 controllers. Linux SMP relies on these instructions.

      Pekka

  • Thanks for reply.

    We have enabled the SMP setting in the CPUECTLR for each core and the Shareability bit in the Page Table Entry for the MMU as part of the configuration for coherent SMP. However, is that insufficient?

  • So you have coherency working but are you saying LDREX STREX pair does not work? Are you getting a bus error or what is the issue? For memory marked normal cacheable and shared the exclusives should work.

  • Sorry for late reply.

    We have confirmed that the STREX/LDREX instructions themselves are executed normally without any exceptions occurring. However, based on the behavior observed in the module using STREX/LDREX, it appears that a value stored by STREX on one core may be read as an unintended value by an LDREX on another core. In other words, it seems that cache coherence is not being maintained.

    Until now, we have been using MSMC SRAM as SRAM, but when we tried setting the entire MSMC SRAM region as L3 cache (value set to 8), there were cases where it functioned correctly and cases where it did not.

  • Do you have this same sequence working as expected with the two cores on the same cluster? So one A53 cluster, two threads on two different cores works, but if accross clusters it does not.

    Weather or not you have L3 cache does not impact the coherency working logically correct.

    Please attach the code sequence you are running and a description of how you ensure they are run on the two cores in the order you think they are run.

  • Sorry for late reply.

    Test program we use has problem. And, we fix it, then test program works well.

    At the moment, the test program is functioning as expected on all four cores.

    Thanks for your support !