xorg broken on Beaglebone black revision 300438

[Mark Millard]

On 2016-May-24, at 2:59 PM, Ian Lepore <ian at freebsd.org> wrote:

> On Tue, 2016-05-24 at 14:35 -0700, Mark Millard wrote:
>> Quoting from Otacílio Tue May 24 00:06:10 UTC 2016 and its locore
>> -v6.S changes:
>> 
>>> -    orr    r7, #CPU_CONTROL_UNAL_ENABLE
>>> -    orr    r7, #CPU_CONTROL_AFLT_ENABLE
>>> +    bic    r7, #CPU_CONTROL_UNAL_ENABLE
>>> +    bic    r7, #CPU_CONTROL_AFLT_ENABLE
>> 
>> -r295256 (2016-Feb-14) changed from:
>> 
>> bic     r7, #CPU_CONTROL_UNAL_ENABLE
>> 
>> to:
>> 
>> orr     r7, #CPU_CONTROL_UNAL_ENABLE
>> 
>> in two places (moving it a few lines down for each example as well).
>> So this much of the proposed changes would be reverting the -r295256
>> change. The check in comment indicates the bit is RAO/SBOP for armv7.
>> For armv6 the check in comment claims it controls armv5 compatible
>> alignment support.
>> 
>> But:
>> 
>> orr     r7, #CPU_CONTROL_AFLT_ENABLE
>> 
>> has been in locore-v6.S since the file's first checkin. So this
>> change to bic here be new.
>> 
>> What is the FreeBSD intent for each of the two new settings for
>> armv7? armv6?
>> 
> 
> It was always wrong to clear CPU_CONTROL_UNAL_ENABLE on armv7 (it's
> documented as RAO/SBOP).  Setting it on armv6 makes the v6 (which is
> only the RPi in our world) behave the same as v7.  So that change was
> just a bugfix.
> 
> I think FreeBSD is the only major OS left that is enforcing strict
> alignment on armv6/v7 and it causes a lot of trouble for ports and
> other 3rd party software, and prevents us from enabling certain
> compiler options and optimizations.  I'm very close to a commit to stop
> enforcing strict alignment (clear rather than CPU_CONTROL_AFLT_ENABLE).
> I've been testing it yesterday and today, and haven't run into any
> trouble at all.
> 
> -- Ian

Good to know. I had submitted at least one port bug report that will likely need to be canceled if this goes through. Effectively its an ABI change allowing a wider variety of code to be compliant.

Is the kernel involved in emulating access/instructions via some technique for misaligned access for armv6/armv7 for some types of instructions? Are there performance issues/tradeoffs that might contribute to sometimes choosing to be careful about alignment?

In one way I liked the strict alignment environment being around: It allowed easily testing if software was more portable for such issues vs. not. (Not that FreeBSD should use such criteria for its choices.)

===
Mark Millard
markmi at dsl-only.net