Creating armv7 MACHINE_ARCH

[Russell Haley]

On Mon, Jun 12, 2017 at 4:20 PM, Warner Losh <imp at bsdimp.com> wrote:
>
>
> On Mon, Jun 12, 2017 at 5:10 PM, Russell Haley <russ.haley at gmail.com> wrote:
>>
>> Okay, feel free to ignore me, I'm not going to get the time drill into
>> the source code for my own questions so I don't expect anyone else
>> too. However, I'll ask anyway. I'm too confused to try and inline
>> these questions. Lets see if I understand:
>>
>> - armv7 does not support 64 bit instructions (according to Wikipedia?
>> I claim no expertise.)
>> - FreeBSD has an armv6 "architecture" that is supports armv6 and armv7
>> on Pre-Cortex-A-53 processors that is not supported on A-53 through
>> the emulated AArch32.
>
>
> There may be a tiny number of kernel or bootloader issues precluding that
> support, but yes. I've been told of people claiming to run a newer rpi2
> (v1.2 or newer) in 32-bit mode, but I've not been able to confirm the people
> who are making the claims. It should be possible to do this, since we know
> Linux does it, so it's only a matter of someone showing up with patches
> and/or instructions on how to do this.
>
>>
>> - Cortex A-53 can support armv8 (AArch64) and armv7 (AArch32) instructions
>
>
> Yes, as well as many others that have similar situations.
>
>>
>> - The current proposal is to split the armv6 and armv7 into their own
>> "architectures"
>
>
> Kinda, yes. This is to build two different sub-architectures where we
> currently do just one.
>
>>
>> FreeBSD has an Arm 64 bit kernel build. I don't see what the
>> TARGET_ARCH settings in the wiki and know little about it, but will
>> conjecture that it doesn't have a TARGET_ARCH=armv8 (please correct me
>> if I'm wrong).
>
>
> It's callled aarch64, per industry norms. Arm doesn't want people calling it
> arm64 or armv8 when referencing the architecture, so nobody that's running
> in this space sets their architecture name to anything bug aarch64.

So supported arm architectures would use a TARGET_ARCH of: armv5,
armv6, armv7 and then AArch64? Would there be an AArch32 for 32 bit
armv8? Just asking out loud: would it be better to call armv7 Aarch32?

Russ

>>
>> What I was trying to ask was: is the kernel development moving in a
>> direction that clearly indicates the differences in the instructions
>> vs the architectures (or have I grossly simplified the problem)? Will
>> it be possible to target a Cortex-A53 and build for 32 or 64 bit
>> support? Or is this just to fix RPi?
>
>
> It already has that difference in an MI way. The MD code to do that hasn't
> caught up yet (to run 32-bit binaries on a 64-bit kernel). It's just that
> the rpi is the first device people have wanted to boot either in 32-bit mode
> or in 64-bit mode, so that's exposing that our code is a bit green in that
> area.
>
>>
>> In terms of Raspbian, I had assumed they were just supporting Aarch32
>> across both processor models. Many of the drivers would be the same
>> source if they share components so I would think it would be "simple".
>> I didn't see anything in my brief look at it today to indicate
>> otherwise.
>
>
> We already share considerable code between the armv7 and aarch64 kernels to
> support raspberry pi devices since they are substantially similar between
> them.
>
>>
>> Thanks for letting me ask questions!
>>
>> Russ
>>
>> On Mon, Jun 12, 2017 at 2:07 PM, Warner Losh <imp at bsdimp.com> wrote:
>> >
>> >
>> > 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
>> >
>> >
>> >
>
>