[U-Boot] memcpy/memset on arm64 platforms

[Philipp Tomsich]

> On 11.01.2019, at 23:28, Alexander Graf <agraf at suse.de> wrote:
> 
> 
> 
> On 11.01.19 17:44, Philipp Tomsich wrote:
>> 
>>> On 07.01.2019, at 10:13, Lokesh Vutla <lokeshvutla at 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).

"B2.5.2 Alignment of data accesses” in the AArch64 Architecture Manual has
the full rules.

For non-normal memory, unaligned accesses will almost always spell trouble.
They are specifically forbidden for device memory.

And yes, I oversimplified a bit: there’s the SCTLR_ELx register that controls
whether alignment checks are performed.  Unfortunately, this field resets to
"a value that is architecturally UNKNOWN”, so unless explicitly enabled these
will be disallowed… which is the default on a number of implementations.

There’s some added ugliness in the specification of alignment faults, if the
faulting access crosses cache lines (I don’t want to go dig for the specific
reference in the AArch64 ARM).

Unless we have trap handlers installed, the alignment fault will stop us with
a data abort…

So from a bootloader-perspective it will probably be best to stay away from
unaligned accesses unless we want to deal with the complexity of setting up
SCTLR fully and differentiating between normal and non-normal memory for
things like a memcpy.

> 
>> 
>>> 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