the stack alignment requirement only means that code can assume sp to be aligned to 16 to be able to place types that need this in the local frame at alignments <=16, not that any access to the stack needs to be that granularity (that would be wasteful for smaller data)
in this case it seems that the compiler incorrectly assumes that the address of a new instance of the ruspiro_uart::uart type doesn't need 16-alignment
then the constructor uses the stp instruction to store two full 128-bit registers, which does require 16-alignment [on this hardware, i don't think it's a general ARM thing]
this may still be a compiler bug, but an incorrect alignment requirement for the type would be just as much of a problem anywhere else; on the heap, or in the global data
edit: it looks like aarch64-unknown-none has feature +strict-align enabled, but aarch64-unknown-linux-gnu does not; i don't know if this is a oversight, or the explicit assumption that linux-capable aarch64 hardware will support unaligned accesses
it might be possible to enable through Cargo.toml somehow