From owner-freebsd-arm@freebsd.org Mon Jun 12 23:10:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27F3CD861BA for ; Mon, 12 Jun 2017 23:10:06 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8471A83867 for ; Mon, 12 Jun 2017 23:10:05 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id p189so59239322lfe.2 for ; Mon, 12 Jun 2017 16:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GryNigS81pQC9DneEUpBiIDE4u8Z8xVSiawX2UQFAN8=; b=Z7mqkhAUcgMBeROjzAmuZzJ6V3s7mYTMF6C94xIOHYvHpuWheTXucZzNoZJBbg9PSa mKyetB3iqvs+vAN7b6GNGg4ZXmh1bQ1n7ErHnzilYSnHibSmM/eLpu367EAZJkWTpM/Y YgHf2jmKr/i13UPz2XEZf8crZsVyddkAgSZo3oTHc5RVHknxURRFggqPRnUx7AjjM5G6 6ubp35eja2FzeuBpqcKsUQpa3mGvZOwdVDB2y7zRcKvF2zWY6Z5z1fsj3MFe4MKYqLmY 2ucsgNUfV0mnE2TiDKdXOGbPLQn/MEYTl+4oUSxuhmhcdIPjFyXMD0wVKsxLBq6RyJPo l8ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GryNigS81pQC9DneEUpBiIDE4u8Z8xVSiawX2UQFAN8=; b=Q+/ejNf5SzlgNZGBQVrcoHKxHzhXLfqjXW4Z4UaPdaYfiTfn0hoiZzabuz1J2FdhCq i3zYBmQachzyGw7SMnonJDA8PNrARSq5GlriX1s59Xf1xhfGiD+i5KmjAXhzyZnPmp3d Xyjbuc6KK9HTOC8gHmH9iFBnn6YxTKw37KddkXON4VY5BjImKYGM+goazzRby0B0aeke +ZKddoVjeBE5OD0rAqYUxf27GnskPqHe1dsIWa1ShSwiy6buq2MugkCttoAc9oBWK5RK lr3PLN0o8R4LsyfpdHH+bbKeIHMvdJLj7wmubpj7WCS1unqUARgvuQAvVGHYUSuR9EUM g+Ww== X-Gm-Message-State: AKS2vOxjEkJ4iI34kn5INFzfxG33vdSbOXXiVW7zUlGCAc0DgancZ0cu W52p7dWnkYh2GMp718NCO2+oRtB11g== X-Received: by 10.46.69.133 with SMTP id s127mr3606044lja.13.1497309003604; Mon, 12 Jun 2017 16:10:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.82.196 with HTTP; Mon, 12 Jun 2017 16:10:02 -0700 (PDT) In-Reply-To: References: <20170612152808.6094931.74364.27128@gmail.com> <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> From: Russell Haley Date: Mon, 12 Jun 2017 16:10:02 -0700 Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Warner Losh Cc: Mark Millard , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 23:10:06 -0000 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. - Cortex A-53 can support armv8 (AArch64) and armv7 (AArch32) instructions - The current proposal is to split the armv6 and armv7 into their own "architectures" 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). 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? 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. Thanks for letting me ask questions! Russ On Mon, Jun 12, 2017 at 2:07 PM, Warner Losh wrote: > > > On Mon, Jun 12, 2017 at 2:35 PM, Mark Millard wrote: >> >> >> On 2017-Jun-12, at 1:00 PM, Mark Millard wrote: >> >> > On Mon, Jun 12, 2017 at 1:00 PM, Mark Millard >> > wrote: >> >> On 2017-Jun-12, at 12:16 PM, Russell Haley >> >> wrote: >> >> >> >>> On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard > >>> dsl-only.net> wrote: >> >>>> >> >>>> On 2017-Jun-12, at 8:39 AM, Warner Losh 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 >> >>>> 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 > > >