From owner-freebsd-arm@freebsd.org Mon Jun 12 21:07:46 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 C8CDFC785F2 for ; Mon, 12 Jun 2017 21:07:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 8A1087F6BE for ; Mon, 12 Jun 2017 21:07:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id m47so27053858iti.0 for ; Mon, 12 Jun 2017 14:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+qtZmbh60SM8vpdkGKMy5IpCFdBSXLAvybRaCkCnWtI=; b=EVy5ses4+hgTqMJX3PONF/jVwmRWedKsgGpt1BYjXbjNGau3e4KrBxXtCKbCg7dTgG Ib6ilGmlZPAfTxonwmFZko8EQcawqOFJgdv47aLxmat/c2GJr8gpw7E4IjumvkW2U56d nWjfecxGmb/CyxKQNMRU0DssB3AanyHjt37V92mdHxtt1rXGIJzXx5fJWCXTwjecLH5m 2czqXXrMY5wIZTIFsOoj5C5U8T+Q2JloGpTuAKhO+RgDRI6CprcUP/kxX8vNEHcf2INc 4cND+n5mI4ABnUfVX968ckKl8JKgNJpJMSKZV/vWC7gaB/H/boj1MWSG6y+ZfLuo+Tz9 I/hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+qtZmbh60SM8vpdkGKMy5IpCFdBSXLAvybRaCkCnWtI=; b=HQCbFP42NH1raooO0Iesml7oq6zTLmtI+KDqmaWx2FUs6Tm8AZWhM50hRei4QQ4OGs D4DU16NIdVXiT117t07CPjCEVpVo1Z/7SJ0pGKw+TxDu/wI1EII0ktGql+puMheYnnJA +ot3YOZzpmLxn3acDxOZShWFpqC0sshlVDBLZMC6+BergYVEm2/gU9nWwyWY5kLfFiJs uGHAysgxK/j4FJcBsSMIaIjF9GVZwu/eG0Nb3s/D7cEjRXDxveXup7aa1VEhm/cnxmkw k2m8FXQtg2HYvSYxfZR9p2TM9m1FPtYA1+PK7gWlLZhPY29S9YnpA7QKm7D0Ze/HuGbY p6Wg== X-Gm-Message-State: AODbwcAb9L2aT61TqWpUM3stJ9vVrwe0Oo3L57m+jwhViR8hYZWQpVpD DJw402JlM6C3yQIMUlJooC5DWH1ohMZE X-Received: by 10.36.83.145 with SMTP id n139mr14078921itb.0.1497301665813; Mon, 12 Jun 2017 14:07:45 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Mon, 12 Jun 2017 14:07:45 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:29a3:1710:671c:c6a7] In-Reply-To: <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> References: <20170612152808.6094931.74364.27128@gmail.com> <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> From: Warner Losh Date: Mon, 12 Jun 2017 15:07:45 -0600 X-Google-Sender-Auth: 58F9S5mxVfW6rPqb4DZ8mcPykps Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Mark Millard Cc: Russell Haley , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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 21:07:46 -0000 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 > 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