Creating armv7 MACHINE_ARCH
Rodney W. Grimes
freebsd-rwg at pdx.rh.CN85.dnsmgr.net
Tue Jun 13 00:49:51 UTC 2017
> On 2017-Jun-12, at 12:16 PM, Russell Haley <russ.haley at gmail.com> wrote:
>
> > On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard <markmi at dsl-only.net> wrote:
> >>
> >> On 2017-Jun-12, at 8:39 AM, Warner Losh <imp at bsdimp.com> 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 <andrew at fubar.geek.nz> 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 at freebsd.org
More information about the freebsd-arm
mailing list