[U-Boot] [PATCH] arm: Disable the strict alignment of data on armv7

[Michal Simek]

On 9.3.2018 13:23, Mark Kettenis wrote:
>> From: Wolfgang Denk <wd at denx.de>
>> Date: Fri, 09 Mar 2018 12:26:01 +0100
>>
>> Dear Michal,
>>
>> In message <f144e491-5ce5-2ad0-70a8-d36397752863 at xilinx.com> you wrote:
>>>
>>>> Can you please add some comments what the consequences of this
>>>> change are?  I guess there are advantages, but I also guess these
>>>> come at a price?
>>>
>>> That's something what I am expecting from this discussion if there are
>>> any corner cases which we are not aware of.
>>>
>>> We found this setting based on randomized testing where simply non
>>> aligned access for memory read was causing exception.
>>
>> Hm... One possible position one can take is that unaligned accesses
>> are likely an indication for incorrect or sloppy programming.
>> usually we design data structures, buffers etc. such that no
>> unaligned accesses take place.  Most code is explicitly written in
>> such a way that it also runs on architectures where unaligned access
>> simply don't work.
>>
>> I feel that providing such an option just opens the door for lousy
>> programmers who don't think throroughly about the code they write.
>>
>> Yes, in some cases this may be conveniendt.  But there are also
>> cases where the problem is just papered over, and hits all the
>> harder later like when you also enable caching.
> 
> That is pretty much why we run OpenBSD in strict alignment mode on as
> much architectures as possible.  More strict-alignment architectures
> means that bugs are found quicker.  So as long as U-Boot supports
> hardware that cares about alignment (e.g. older ARM, MIPS, SuperH) I'd
> say there is a clear benefit of running armv7 in strict alignment mode.
> 
> Also note that some armv7 instructions still require properly aligned
> data.  And that really old ARM hardware silently fetches the wrong
> data for a misaligned load instruction.
> 

No problem with this at all. I wanted to check that this is intended setup.

Thanks,
Michal