xorg broken on Beaglebone black revision 300438
ian at freebsd.org
Tue May 24 21:59:19 UTC 2016
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
> 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.
> 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.
More information about the freebsd-arm