Creating armv7 MACHINE_ARCH

[Mark Millard]

On 2017-Jun-12, at 1:00 PM, Mark Millard <markmi at dsl-only.net> wrote:

> On Mon, Jun 12, 2017 at 1:00 PM, Mark Millard <markmi at dsl-only.net> wrote:
>> 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.
> 
> I thought all 64 bit Arm instructions are defined in armv8?

(I assume you are not trying to indicate armv8.1, armv8.2
and such. Cortex-A53 is older than those and so does not
have the newer things involved.)

That Cortex-A53 allows armv8 64-bit arm code is not in
dispute. But the operating system in involved in setting
up what will actually work based on how it configures
things and operates. Much of this is the kernel.

Cortex-A53 also supports AArch32, i.e., 32 bit instructions.
So that the 64-bit instructions all being there does not
of itself prevent using a 32-bit mode instead.

(The kernel likely has to deal with more specifics of
processor variations than user code does not. My notes
are really about the user process model, not the all
the kernel details.)

Raspian deals with armv7's that have no 64-bit support
and with Cortex-A53's that do. It presents a user-process
model that is 32-bit only, even on Cortex-A53's that allow
for 64-bit (but do not required user programs to be AArch64
code).

Ubuntu for ODroid-C2 does not deal with armv7's but does
allow both 64-bit (AArch64) and 32-bit (AArch32) user
processes as I remember, on its Cortex-A53's.

FreeBSD armv7 does not support Cortext-A53 or anything
that allows 64-bit (that allows AArch64). This is a kernel
level issue.

FreeBSD aarch64 does not support having AArch32 user
processes. Nor does its kernel support processors that
do not support aarch64 (so it does not support armv7).

These are simply examples of different choices about
what combinations of the technical possibilities to
put effort into supporting in the kernels (and
possibly elsewhere). None of the alternatives is
automatic. None are independent of software choices
that must be made by each operating system.


(I'm not one of the people working on the kernels.
If they tell you that I'm wrong abut something:
Believe them.)

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