Date: Mon, 12 Jun 2017 13:00:36 -0700 From: Mark Millard <markmi@dsl-only.net> To: Russell Haley <russ.haley@gmail.com> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Creating armv7 MACHINE_ARCH Message-ID: <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> In-Reply-To: <CABx9NuQTOkf6HK=RacUCBR=W_WDfgZwbVHYwsRdx0YJd=zr51w@mail.gmail.com> References: <CANCZdfpUjPBRpxpmjtwK-wpiK=%2BwHscS4UmVeatrE7vrm260tw@mail.gmail.com> <20170612152808.6094931.74364.27128@gmail.com> <CANCZdfrxTo8vLsnjU_VerO%2B3%2BU=06cok7%2BuKba3FM8_nXFozhQ@mail.gmail.com> <B19EDB95-2A23-4F8F-8414-3F4E0E65AC4B@dsl-only.net> <CABx9NuQTOkf6HK=RacUCBR=W_WDfgZwbVHYwsRdx0YJd=zr51w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Jun-12, at 12:16 PM, Russell Haley <russ.haley@gmail.com> wrote: > On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard <markmi@dsl-only.net> = wrote: >>=20 >> On 2017-Jun-12, at 8:39 AM, Warner Losh <imp at bsdimp.com> wrote: >>=20 >>> . . . >>>=20 >>> 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. >>=20 >> On 2017-Jun-12, at 6:59 AM, Andrew Turner <andrew@fubar.geek.nz> = wrote: >>=20 >>> 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+. >>>=20 >>> It should also be noted the GENERIC kernel is likely to only ever = target ARMv7+ even without an armv7 TARGET_ARCH. >>=20 >>=20 >> 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. >>=20 >>=20 >> As for GENERIC: >>=20 >> powerpc has. . . >>=20 >> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc and GENERIC >> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 and GENERIC64 >>=20 >> So there is precedent for more than one GENERIC* >> for a family, with which one being appropriate >> being based on TARGET_ARCH. >>=20 >> For powerpc TARGET=3Dpowerpc implicitly uses >> TARGET_ARCH=3Dpowerpc 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=3Darmv7 by >> default). >>=20 >>=20 >> Side note: >>=20 >> A caution about talking about "rpi2" as >> an example. . . >>=20 >> 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. >>=20 >> V1.1 and before were armv7 (BCM2836) based. >>=20 >> 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. >>=20 >> (A single, modern distribution of the official >> Raspbian software for the rpi2 does support >> all the V1.x boards if I understand right.) >=20 > 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). > =46rom 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." >=20 > 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=20 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. =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?2A90A527-7DCA-4442-9322-0EA96236583C>