Note that because the processor executing the CP15 broadcast operation cannot complete that operation, it cannot enter any debug-mode, and cannot take any interrupt. If the processor executing the branch-to-self loop cannot be interrupted (e.g., if it has disabled its interrupts, or if all interrupts are routed to other processor), then this issue might cause a livelock in the system.
|Impact:||Minor. This issue might impact the performance of the system, or in the worst case, if the processor executing the branch-to-itself loop cannot be interrupted it might cause a system livelock.|
|Work-around:||Break the continuous stream of requests generated by the CPU, refer to Work-around Details.|
|Configurations Affected:||Systems that use two CPUs.|
|Device Revision(s) Affected:||All. No plan to fix. Refer to (Xilinx Answer 47916) - Zynq-7000 AP SoC Silicon Revision Differences.|
|Third Party Errata:||ARM Errata 799769|
To work around this problem, you can break the continuous stream of requests generated internally in the processor executing the branch-to-self loop. Software usually executes a branch-to-self loop while waiting for an external event to happen, for example a lock-release in a multiprocessor environment. The recommended work-around is to replace the branch-to-self loop by a loop containing a WFE or WFI instruction, as recommended by the ARM Architecture Reference Manual. Other work-arounds, such as adding a NOP in the loop, or moving the branch-to-self instruction to any location other than the last cache line of the page, would avoid the issue.
If the software executing the branch-to-self loop cannot be modified, the recommended work-around is to force the processor executing the loop to regularly take an interrupt that acts as a watchdog. There are several ways this periodic interrupt might be generated, and these can be system-specific. Possible candidates are interrupts generated by the local timer, global timer, or Performance Monitor Unit cycle counter overflow.