Does SpinMutex from spin crate not work on aarch64?

[RedDocMD]

Hi!
Instead of using the NullLock defined in this tutorial, I am using the spin-lock from the spin crate. However, it seems that the lock is never acquired and it always blocks forever. Is there some specific setup required to use spin on Raspberry Pi 3A+?

[jakubfijalkowski]

Spin lock uses atomics under the hood, but atomics work on ARM only if you have MMU configured and enabled. MMU is introduced later than the NullLock, so I assume that is the case (it was in my case).

The forever spinning isn't really spinning - CPU raises an exception, but you must have not configured the handler yet so it raises an exception from an exception handler, freezing forever (cause handlers are introduced even after MMU).

[andre-richter]

What @jakubfijalkowski says. On the RPi you get an exception, if you have them enabled already, if you try atomics on non-cacheable memory.

There is also a hint starting tutorial 10 in main.rs:

rust-raspberrypi-OS-tutorials/10_virtual_mem_part1_identity_mapping/src/main.rs

Lines 134 to 142 in ea8ef5a

	/// - The init calls in this function must appear in the correct order:
	/// - MMU + Data caching must be activated at the earliest. Without it, any atomic operations,
	/// e.g. the yet-to-be-introduced spinlocks in the device drivers (which currently employ
	/// NullLocks instead of spinlocks), will fail to work (properly) on the RPi SoCs.
	unsafe fn kernel_init() -> ! {
	use driver::interface::DriverManager;
	use memory::mmu::interface::MMU;
	if let Err(string) = memory::mmu::mmu().enable_mmu_and_caching() {

Implementation of exclusive load/store (atomics) is often tied to / implemented on top of the CPU’s cache (leveraging the HW-coherency it provides).