This might happen when the write request is followed by another write into the same naturally aligned double-word memory region, without a DMB between the two writes. The second write request must not be performed to the exact same bytes as the first store. The repetition of the write usually has no impact on the overall behavior of the system, unless the repeated write is used for synchronization purposes.
A write request to Normal memory region is treated as Uncacheable in the following cases:
This behavior might have implications in a multi-master system where control information is passed between several processing elements in memory using a communication variable, for example a semaphore. In such a system, it is common for communication variables to be claimed using a Load-Exclusive/Store-Exclusive, but for the communication variable to be cleared using a non-Exclusive store. Due to this malfunction, the clearing of such a communication variable might occur twice. This might lead to two masters apparently claiming a communication variable, and therefore might cause data corruption to shared data.
A scenario in which this might happen is:
This scenario is valid when the communication variable is a byte, a half-word, or a word.
There are several possible work-arounds:
1) Add a DMB after clearing a communication variable:
Also, any IRQ or FIQ handler must execute a DMB at the start to ensure as well the clear of any communication variable is complete.
2) Ensure there is no other data using the same naturally aligned 64-bit memory location as the communication variable:
3) Use a Store-Exclusive to clear the communication variable, rather than a non-Exclusive store.
|Work-around:||There are several, refer to Detailed Work-arounds.|
|Configurations Affected:||Systems that use the CPUs.|
|Device Revision(s) Affected:||All. No plan to fix. Refer to (Xilinx Answer 47916) - Zynq-7000 SoC Silicon Revision Differences.|
05/16/2013 - Initial release