When Ldaxr Doesn't Work: Exclusive Accesses and Cacheability on AArch64

The author implements a simple spin lock on AArch64 using ldaxr/stxr (load/store exclusive) pairs to achieve atomicity and acquires/releases (ldaxr/stlr). The lock behaved correctly under QEMU and rpi4 emulation but crashed on real Raspberry Pi 5 hardware with a Data Abort (EC 37) precisely at the ldaxr. Replacing exclusive instructions with a normal load-acquire and plain store avoided the exception but removed atomic semantics. Investigation focused on memory types and attributes: MAIR_EL1 entries, shareability (Non-, Inner-, Outer-Shareable) and cacheability. Architecturally guaranteed atomicity requires Normal memory that is Inner- or Outer-Shareable and Inner/Outer Write-Back with read/write allocation hints and non-transient; Device or non-cacheable memory (or memory treated as non-cacheable by the implementation) may not support atomic exclusives.

The root cause was a global cacheability control: SCTLR.C was 0 by default on the rpi5, disabling the data cache so cacheable mappings were treated as non-cacheable and incoherent, which breaks exclusive monitors. Setting SCTLR.C=1 removed the exception. Changing MAIR to a non-write-back attribute also reproduced the fault, confirming exclusive operations depend on proper cacheable write-back attributes and shareability. QEMU did not expose this hardware requirement, so on real hardware either enabling the data cache or configuring MAIR appropriately is required for ldaxr/stxr to work.