Date: Tue, 24 May 2016 15:19:49 -0700 From: Mark Millard <markmi@dsl-only.net> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: xorg broken on Beaglebone black revision 300438 Message-ID: <E268D55F-7E4D-4FF7-B38E-0912F275BF0C@dsl-only.net> In-Reply-To: <1464127156.1204.10.camel@freebsd.org> References: <AE62E2F1-1D9F-418F-97E8-6D7F0E6B4B87@dsl-only.net> <1464127156.1204.10.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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=EDlio Tue May 24 00:06:10 UTC 2016 and its locore >> -v6.S changes: >>=20 >>> - orr r7, #CPU_CONTROL_UNAL_ENABLE >>> - orr r7, #CPU_CONTROL_AFLT_ENABLE >>> + bic r7, #CPU_CONTROL_UNAL_ENABLE >>> + bic r7, #CPU_CONTROL_AFLT_ENABLE >>=20 >> -r295256 (2016-Feb-14) changed from: >>=20 >> bic r7, #CPU_CONTROL_UNAL_ENABLE >>=20 >> to: >>=20 >> orr r7, #CPU_CONTROL_UNAL_ENABLE >>=20 >> 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. >>=20 >> But: >>=20 >> orr r7, #CPU_CONTROL_AFLT_ENABLE >>=20 >> has been in locore-v6.S since the file's first checkin. So this >> change to bic here be new. >>=20 >> What is the FreeBSD intent for each of the two new settings for >> armv7? armv6? >>=20 >=20 > 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. >=20 > 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. >=20 > -- 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.) =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E268D55F-7E4D-4FF7-B38E-0912F275BF0C>