google
Big-endian support
Hi there, I've been running into some issues with this crate when the CPU is in big-endian mode (i.e. the code compiled for aarch64_be). It appears that the crate assumes the endianess of the CPU to be little endian.
The GIC-600 technical reference manual states:
The GIC-600 supports data only in little-endian format.
And the Linux kernel also converts all data accesses from little endian to current CPU endianess and back. Something similar should probably be done here.
To my understanding, only the memory-mapped IO accesses need to be endian aware, since ARM endianess only affects load/store. It seems like safe-mmio is not endian aware.
It seems that this patch gets it working as intended: https://github.com/Gelbpunkt/safe-mmio/commit/9ba84bf7af075d81769f142f2ea74e4a2b5a621f (but I assume you'll want something nicer for configurable endianess of the MMIO)
Hi! Indeed we haven't tried this on a big-endian configuration yet.
One way to approach this would be to use the types from zerocopy::byteorder. E.g. rather than using ReadPureWrite<u32> we could use ReadPureWrite<zerocopy::byteorder::little_endian::U32>. I'm not sure how we'd handle the various bitflags types though. I've filed https://github.com/bitflags/bitflags/issues/455 to request support there.
For bitflags (and explicit endianess integers) https://docs.rs/endian-num/latest/endian_num/ implements the necessary traits and might do the trick :)
I'd prefer to avoid an extra dependency if possible, but if the zerocopy::byteorder types don't work then we can try those. Would you like to give it a go and send a PR?
Sure, I'd love to. I won't have time until next week, but I should definitely get to it on Monday or Tuesday.
This repository has been migrated to https://review.trustedfirmware.org/q/project:arm-firmware-crates/arm-gic, so please send the patch there instead when you get to it. Any further issues can go to https://github.com/ArmFirmwareCrates/arm-gic/issues.