Date: Mon, 12 Jun 2017 17:20:13 -0600 From: Warner Losh <imp@bsdimp.com> To: Russell Haley <russ.haley@gmail.com> Cc: Mark Millard <markmi@dsl-only.net>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Creating armv7 MACHINE_ARCH Message-ID: <CANCZdfrWmPJU48TfUEQMQoWJ5Vvo_47VNG8xAPdd3Cso6kqXKw@mail.gmail.com> In-Reply-To: <CABx9NuRJLgc0cSsykrSbJi=fVq-jfOi7ZEiZ5LRHG5tqibZ_2Q@mail.gmail.com> References: <CANCZdfpUjPBRpxpmjtwK-wpiK=%2BwHscS4UmVeatrE7vrm260tw@mail.gmail.com> <20170612152808.6094931.74364.27128@gmail.com> <CANCZdfrxTo8vLsnjU_VerO%2B3%2BU=06cok7%2BuKba3FM8_nXFozhQ@mail.gmail.com> <B19EDB95-2A23-4F8F-8414-3F4E0E65AC4B@dsl-only.net> <CABx9NuQTOkf6HK=RacUCBR=W_WDfgZwbVHYwsRdx0YJd=zr51w@mail.gmail.com> <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> <CANCZdfp6cnXdHxSQGTXHq4Md4Jh6=u4Af_rDM3k_RgoN%2BFrXWA@mail.gmail.com> <CABx9NuRJLgc0cSsykrSbJi=fVq-jfOi7ZEiZ5LRHG5tqibZ_2Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 12, 2017 at 5:10 PM, Russell Haley <russ.haley@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. > 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@bsdimp.com> wrote: > > > > > > On Mon, Jun 12, 2017 at 2:35 PM, Mark Millard <markmi@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 > > > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrWmPJU48TfUEQMQoWJ5Vvo_47VNG8xAPdd3Cso6kqXKw>