From owner-freebsd-arm@freebsd.org Tue May 24 22:26:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A597B49BD3 for ; Tue, 24 May 2016 22:26:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-190.reflexion.net [208.70.211.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A44531775 for ; Tue, 24 May 2016 22:26:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17962 invoked from network); 24 May 2016 22:20:19 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 May 2016 22:20:19 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Tue, 24 May 2016 18:19:55 -0400 (EDT) Received: (qmail 32606 invoked from network); 24 May 2016 22:19:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 24 May 2016 22:19:54 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 168B11C43D2; Tue, 24 May 2016 15:19:45 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: xorg broken on Beaglebone black revision 300438 From: Mark Millard In-Reply-To: <1464127156.1204.10.camel@freebsd.org> Date: Tue, 24 May 2016 15:19:49 -0700 Cc: freebsd-arm Message-Id: References: <1464127156.1204.10.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 22:26:37 -0000 On 2016-May-24, at 2:59 PM, Ian Lepore 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