Date: Mon, 12 Jun 2017 16:53:42 -0700 From: Russell Haley <russ.haley@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Mark Millard <markmi@dsl-only.net>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Creating armv7 MACHINE_ARCH Message-ID: <CABx9NuQ-077L_sV=u_n5n5Xanz-1vmAG2sGNQcH%2BkqaPxj7_Vw@mail.gmail.com> In-Reply-To: <CANCZdfrWmPJU48TfUEQMQoWJ5Vvo_47VNG8xAPdd3Cso6kqXKw@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> <CANCZdfrWmPJU48TfUEQMQoWJ5Vvo_47VNG8xAPdd3Cso6kqXKw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 12, 2017 at 4:20 PM, Warner Losh <imp@bsdimp.com> wrote: > > > 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. 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@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?CABx9NuQ-077L_sV=u_n5n5Xanz-1vmAG2sGNQcH%2BkqaPxj7_Vw>