On 11.01.19 17:44, Philipp Tomsich wrote:
On 07.01.2019, at 10:13, Lokesh Vutla lokeshvutla@ti.com wrote:
Hi All, I am trying to enable CONFIG_USE_ARCH_MEMSET/MEMCPY on arm64 platforms and realized that there is no arm64 specific memcpy available in u-boot. So I tried porting arm64 specific memcpy from kernel[1]. Memcpy stopped working after that and observed that if destination address is unaligned then system hangs.
After doing a bit more research, understood that unaligned access to device or strongly ordered memories will fail. And the memory system (even normal RAM) behaves like strongly ordered memory when the MMU is disabled[2]. In u-boot MMU is enabled very late after relocation and SPL doesn't enable MMU at all.
ARMv8 does not allow unaligned accesses in privileged (i.e. except in EL0) modes.
Do you have a reference to this in the spec somewhere?
So far, I always assumed that the only constraint on AArch64 to have workable unaligned accesses is to enable caching and have the maps be declared as normal (for which you need to enable the MMU and provide PTEs that do so).
Before I proceed any further wanted to hear from others if anyone have already tried and have any working solution. If not should we update the kernel memcpy to use unaligned destination address and use it in u-boot?
Just make sure you're only doing aligned accesses and you're fine? Most memcpy code checks start and end for alignment, does aligned operations on those bits and then bigger chunks for the middle piece. I would assume you will find something like that in glibc for example.
The reason the kernel gets away without is that it knows that hardware unaligned access is always available, because it controls the page tables and it only ever runs from normal ram.
In SPL however, we may run from XIP or SRAM or whatever. In that case, even if you wanted to, you could not declare memory as normal and thus could not rely on hardware unaligned fixups.
Alex