From owner-freebsd-arm@freebsd.org Tue Jun 13 00:49:51 2017 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 BAB03D87E34 for ; Tue, 13 Jun 2017 00:49:51 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80A921E3D for ; Tue, 13 Jun 2017 00:49:51 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v5D0nmr4053894; Mon, 12 Jun 2017 17:49:48 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v5D0nmeZ053893; Mon, 12 Jun 2017 17:49:48 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201706130049.v5D0nmeZ053893@pdx.rh.CN85.dnsmgr.net> Subject: Re: Creating armv7 MACHINE_ARCH In-Reply-To: <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> To: Mark Millard Date: Mon, 12 Jun 2017 17:49:48 -0700 (PDT) CC: Russell Haley , "freebsd-arm@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 00:49:51 -0000 > On 2017-Jun-12, at 12:16 PM, Russell Haley wrote: > > > On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard wrote: > >> > >> On 2017-Jun-12, at 8:39 AM, Warner Losh wrote: > >> > >>> . . . > >>> > >>> Plus, we aren't quite doing what Ian wanted. He wanted a full rename. The > >>> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not to rename or > >>> remove armv6. Sadly, that will still be there since the RPI foundation > >>> keeps finding new ways to repackage the rpi into new boards that are just > >>> too cheap to ignore. > >> > >> On 2017-Jun-12, at 6:59 AM, Andrew Turner wrote: > >> > >>> I like this. My understanding is adding armv7 would also fix many of the currently broken ports that assume they are being built for armv7 as many Linux distros target ARMv7+. > >>> > >>> It should also be noted the GENERIC kernel is likely to only ever target ARMv7+ even without an armv7 TARGET_ARCH. > >> > >> > >> Hopefully the choices related to TARGET and TARGET_ARCH > >> for armv7 end up identifying the context to port builds > >> so that many would just automatically do the right thing. > >> > >> > >> As for GENERIC: > >> > >> powerpc has. . . > >> > >> TARGET=powerpc TARGET_ARCH=powerpc and GENERIC > >> TARGET=powerpc TARGET_ARCH=powerpc64 and GENERIC64 > >> > >> So there is precedent for more than one GENERIC* > >> for a family, with which one being appropriate > >> being based on TARGET_ARCH. > >> > >> For powerpc TARGET=powerpc implicitly uses > >> TARGET_ARCH=powerpc when TARGET_ARCH is not > >> specified (if I remember right). Which should > >> be the default for armv6 vs. armv7 might go > >> the other direction (TARGET_ARCH=armv7 by > >> default). > >> > >> > >> Side note: > >> > >> A caution about talking about "rpi2" as > >> an example. . . > >> > >> Raspberry Pi 2 Model B V1.2 is Cortex-A53 based > >> (so arm64/aarch64). (A BCM2837, not a BCM2836.) > >> This dates about to something like 2014 based > >> on the pictures showing the (c) notice on the > >> boards. > >> > >> V1.1 and before were armv7 (BCM2836) based. > >> > >> Unless a kernel and world are made that can > >> also configure/handle a Cortex-A53 in a > >> armv7-like manor there will be two different > >> GENERIC builds in order to span the "rpi2" > >> family, based on just V1.2+ vs. V1.1 and > >> before. > >> > >> (A single, modern distribution of the official > >> Raspbian software for the rpi2 does support > >> all the V1.x boards if I understand right.) > > > > I am confused. I don't see any documentation about Raspbian supporting 64 bit? > > 64-bit Cortex-A53's can be configure to operate in a > 32-bit mode (AArch32). Raspian does that for RPI2 V1.2 > and for RPI3. > > Raspian does not (yet?) support a 64-bit mode (AArch64). > > The Cortex-A53 can support either. As I understand it > is possible for an OS to allow a user processes to be > one or the other, different processes using the different > modes. That does not mean that all operating systems > bother to. > > If I remember right the official Ubuntu for an ODroid-C2 > allows both AArch64 and AArch32 user programs (and > so processes, with shared library types tracking). It would be very nice if we had an AArch32 that could run on the RPI3. For me it does not make a huge amount of sense to run 64 bit pointers on a machine that can never physcially have more than 2G of memory. I do understand, and am greatful, that basically this was done to bring up the AArch64 platform, but can we go the extra mile and have both? > > > From Arm at https://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php: > > "The Cortex-A53 supports the full ARMv8-A architecture. It not only > > runs 64-bit applications also seamlessly and efficiently runs legacy > > ARM 32-bit applications." > > > > I assume that means it handles armv7-A without issue? (In fact, many > > on this board know it does) > > I've not gone through the details but targeting AArch32 > probably means targeting a subset of armv7. Or may be > to support both requires targeting a common subset of both. > (My guess is that AArch32 is the definition of a common > subset for 32-bit, at least for user processes.) > > Raspian targets just AArch32 on armv7 and Cortex-A53 > (user space). (If I've got the definition of AArch32 > right: otherwise a common subset.) > > FreeBSD targets armv7 and AArch64 separately (via > separate GENERIC kernels). I'm not aware of FreeBSD > targeting AArch32 at all on cores capable of AArch64. > FreeBSD possibly does not restrict itself to AArch32 > (user processes) on armv7 if AArch32 is really a > subset. Isnt this just a wonefully confusing world! > Mark Millard > markmi at dsl-only.net -- Rod Grimes rgrimes@freebsd.org