The following example describes one scenario that might trigger the issue:
In this example, the arbitration scheme of the Cortex-A9 MPCore always gives priority to the write requests from CPU1, preventing successful reads from CPU0. CPU0 is stalled and cannot make further progress.
Note that because CPU0 cannot complete its coherent read access, it cannot enter any debug-mode and cannot take any interrupt. If CPU1 also cannot be interrupted, for example if CPU1 has disabled its interrupts, or if all interrupts are routed to CPU0 only, this might cause a system livelock.
|Impact:||Minor. The denial of service on the other coherent agent might cause performance issues, or a possible system livelock. |
The system livelock might happen if it is not possible to interrupt the processor that is performing the continuous write stream.
|Work-around:||Break the continuous write stream, refer to the Work-around Details.|
|Configurations Affected:||Systems that use two CPUs or one CPU and the ACP.|
|Device Revision(s) Affected:||All. No plan to fix. Refer to (Xilinx Answer 47916) - Zynq-7000 SoC Silicon Revision Differences|
|Third Party Errata:||Arm Errata 791420|
To work around this issue, you can break the continuous write stream that causes the livelock by inserting a DMB instruction in the loop performing the write stream.
If the software causing the write stream cannot be modified, the recommended work-around is to force CPU1 to regularly take an interrupt which acts as a watchdog.
There are several ways this regular interrupt might be generated, and these can be system-specific. Interrupts generated by the local timer, global timer, or Performance Monitor Unit cycle counter overflow are possible candidates.