Creating armv7 MACHINE_ARCH

[Mark Millard]

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).

> 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.

===
Mark Millard
markmi at dsl-only.net