Creating armv7 MACHINE_ARCH

[Warner Losh]

On Mon, Jun 12, 2017 at 2:35 PM, Mark Millard <markmi at dsl-only.net> wrote:

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

Correct.


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

Not a hugely difficult issue to fix, but one nobody had fixed...


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

Executing a 32-bit /bin/cat on aarch64 level support exists outside the
tree, according to the hallway track at BSDcan, so it will only be a matter
of time before compat32 exists there I think.

There's a further complication is that the aarch32 unit of aarch64
processors is optional. Not all of them have it, so that can be a
problem... IIRC, the early aarch64 targets didn't have this feature...


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

Yes. They all require somebody to be interested in doing the work.

Warner