From owner-freebsd-arch@freebsd.org Sat Sep 9 05:10:26 2017 Return-Path: Delivered-To: freebsd-arch@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 F0629E031CE for ; Sat, 9 Sep 2017 05:10:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C870D7F8D9 for ; Sat, 9 Sep 2017 05:10:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id C4F3BE031CC; Sat, 9 Sep 2017 05:10:26 +0000 (UTC) Delivered-To: arch@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 C4982E031CB for ; Sat, 9 Sep 2017 05:10:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 8F05E7F8D8 for ; Sat, 9 Sep 2017 05:10:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id j141so9339755ioj.4 for ; Fri, 08 Sep 2017 22:10:26 -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=XQZzCgIdGYWaBoa53PuqGKoN/rbGJcnYOYnyxTLmfAk=; b=tqlpEGEtZMeq3uyZBc+5guN8AyTpynfTNDzAHQ7cvsaY9fW19asOYH1ZmBpufsYXJo yHJWU9H44MNGsk/33E3UbYRdMBa0dJY9ZVqt2xMy534WA8acvkrKhv7QQpt536QgQeg0 8CRAl6thCC2tPYSQ/5Mjhwpyi+HMSyYmbmsbTtjvT9cRED0YVwTC8lRjhNOvPUSA5k6h Ob+XS+Nd+8H+O2TNrcl34end+5nFoTmthC04EkPv9V9CO2N6h5QV+6piVjdVhqqGBsRU Jk1uVOcLRCpD4SCvmU0xzAqtyMkmBdEs29IWBewmlqMIMLIOajRJrASNSItOVS+FpFow GrUA== 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=XQZzCgIdGYWaBoa53PuqGKoN/rbGJcnYOYnyxTLmfAk=; b=gv7gfvOISpvT1uJxQtqCUHnjY6rdWN1GIZN39Lg1qtKYK6Lv3Mo2+CM/C0KUi8Vijh K6w2JFSWjB1V2GIoJmYv5iPb6XCcdikdjErpX0CeDuhFTeirRWqGZxywFI8S+lJtNOpA n5Hv5VQUyvmjQBh7dvEdkfLhWSwwinkH0o0VUQqRoi5StxznFOxI7owOty0n4ZXHDRYT sCIo2t7PGwfnxD2m0iHGXI8MHPQfKaCWL1ZGzCJ4M7iRNrO6KZbqksF/OplYFVquQXFU wP+SrWwzSSZnIXF6MoJq+sQjgrDD4ie94X9gkq5kh8N3z6lDJTFLXXoCeUhouwbFAU2K 8oEA== X-Gm-Message-State: AHPjjUinoxnbhYk4mbtQXfIJmpaQZnMrtiduKoqESMFDMpLAg//t0LiH donBqmvLplnin6kU4h7zF+oxV3UmDo4H X-Google-Smtp-Source: AOwi7QBsL9THXylGfAKBUMm/IStLJMfynR5zDROaMRTOZSWPeaJM4aYXOjSCdbNZNinE8tgylFg42q6NQ8+U8aFKtrU= X-Received: by 10.107.185.7 with SMTP id j7mr4475431iof.221.1504933825673; Fri, 08 Sep 2017 22:10:25 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Fri, 8 Sep 2017 22:10:25 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:d5ae:f1f3:42c8:b0f7] In-Reply-To: References: From: Warner Losh Date: Fri, 8 Sep 2017 23:10:25 -0600 X-Google-Sender-Auth: 7qz0nEKSezR6f3L6Dvt341iKQns Message-ID: Subject: Re: FCP-100: armv7 plan To: Russell Haley Cc: "freebsd-arm@freebsd.org" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 05:10:27 -0000 On Fri, Sep 8, 2017 at 7:52 PM, Russell Haley wrote: > On Fri, Sep 8, 2017 at 4:11 PM, Warner Losh wrote: > > Greetings, > > > > This will serve as 'Last Call' for any objections to the plan to create > an > > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > > > > Please see https://github.com/freebsd/fcp/blob/master/fcp-0100.md for > all > > the details. This has been discussed in the mailing lists, on IRC, etc > and > > I believe that I've captured the consensus from those discussions. > > > > I'm interested in any last minute comments, but as far as I can tell I > have > > consensus on this issue. Absent any comments to the contrary, I'll > proceed > > to having core@ vote that this document represents consensus. Now is the > > time to speak up if I've gotten anything wrong. > > > > Once the core vote is done, I plan on committing the code reviews I have > > open on this: > > https://reviews.freebsd.org/D12027 > > and > > https://reviews.freebsd.org/D12010 > > (again, I welcome any commits / criticisms in phabricator on the specific > > issues in this code) > > > > Thanks for any comments... > > > > Warner > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > Hi Warner, > > Thanks for your work on this. General thoughts in and around this subject. > > 1) I like how you split the commit into generic build system changes > vs BSP changes. It was helpful in aiding visibility in the code > changes. > Thanks. > 2) Are these statements true? > > - We will not be differentiating hard/soft float. It is assumed > armv6/7 are hard float (no letter suffixes) > Yes. We switched to only hard float on armv6 prior to the switch. While one can still build a softfloat system, it's not really supported (we don't test it, we don't build packages for it, etc). That support exists in the tree for the transition libraries only and may be removed in the future. > - armv4/5 has no changes > Correct. > - armv6 is split into armv6, armv7 > Yes. > - armv8 is aarch64 > armv8 has no (current) meaning to FreeBSD. > - We will not be supporting aarch64 32 bit extensions for running > armv6/7 binaries > That's an orthogonal problem that a aarch64 kernel will solve, but is unrelated to the build system. > - There is no way to run aarch64 on armv7 > Nope. > 3) Can I ask if there will be other armv[0-9+] architectures created > or do you think everything new will transition to 64 bit? If so, will > we (FreeBSD) be able to differentiate those architectures in the > future (aarch64v2)? I guess what I'm asking is "in your expert > opinion, have we taken enough steps to ensure clean > code/names/you-get-my-point for future changes?" What else could we > do? It seems that there is a lot of changes in arm compared to other > architectures. The rapid development of different things by the Arm > group and other vendors seems to cause a lot of churn. Do you think > our naming conventions do enough to take this into consideration? > Modern hardware manufacturing seem much different then what I am > reading about in Unix history. Have our naming patterns kept up? > Those are all good questions. While it's hard to say for sure they won't be any new armvX architectures that implement 32-bit ABIs, there's been a strongly telegraphed signal that all new ARM innovation will be in the 64-bit area. They've also claimed that new revisions of aarch64 will be more orderly and less chaotic than things have been in the 32-bit arm world. It's unclear still if that will actually be the case, but given we have little basis for guessing the proper names in the future, it's hard to future-proof here. > 4) Also, if my supposition about arm 32/64 compatibility is correct, > do we have plans in place for future boards may have 32/64 bit > compatibility like the RPi3? Or, is it just two different builds and > downloads? (which I'm cool with, but would like to know) > The notion is that for those AARCH64 SoCs that have the ability to run 32-bit, we'll have two builds. One will be aarch64 based and the other armv7 based. We'll likely roll that into armv7 GENERIC so we can get away from having so many distributions (move to more of a base image + flavoring step), but that work isn't complete enough to talk much about. Work to make RPI3 work with a 32-bit kernel appears to be reaching completion. There should be something there soon (if it hasn't already been announced...) Warner