From owner-freebsd-stable@freebsd.org Sun Sep 25 00:12:34 2016 Return-Path: Delivered-To: freebsd-stable@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 04A1FBDE19A for ; Sun, 25 Sep 2016 00:12:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-72.reflexion.net [208.70.210.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEAF2687 for ; Sun, 25 Sep 2016 00:12:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20031 invoked from network); 25 Sep 2016 00:12:17 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Sep 2016 00:12:17 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.00.0) with SMTP; Sat, 24 Sep 2016 20:12:32 -0400 (EDT) Received: (qmail 28171 invoked from network); 25 Sep 2016 00:12:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Sep 2016 00:12:31 -0000 Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net [70.189.131.151]) by iron2.pdx.net (Postfix) with ESMTPSA id 4D64FEC8FEB; Sat, 24 Sep 2016 17:12:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants? From: Mark Millard In-Reply-To: Date: Sat, 24 Sep 2016 17:12:24 -0700 Cc: FreeBSD-STABLE Mailing List , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net> References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net> <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2016 00:12:34 -0000 On 2016-Sep-24, at 2:11 PM, Warner Losh wrote: > On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard = wrote: >> [A resend since I forget to list free-arm in the To: the first time.] >>=20 >> =46rom https://www.freebsd.org/platforms/arm.html : >>=20 >>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD = project does not provide official releases or pre-built packages for = this platform due to it primarily targeting the embedded arena. However, = FreeBSD/ARM is being actively developed and maintained, is well = supported, and provides an excellent framework for building ARM-based = systems. FreeBSD/arm supports ARMv4 and ARMv5 processors. FreeBSD/armv6 = supports ARMv6 and ARMv7 processors, including SMP on the latter. >>=20 >> "does not provide official releases or pre-built packages"? >>=20 >>> # uname -apKU >>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: = Sun Aug 28 03:17:54 PDT 2016 = markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = armv6 1100502 1100502 >>=20 >>> # pkg search '.*' | wc >>> 21349 155540 1596736 >>=20 >> Will 11.0-RELEASE change the tier level for any of the specific = arm-armv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files = built, such as for RPI2? >>=20 >> Even if all the officially built arm-armv6 variants stay tier 2, the = wording on the web page likely needs to be changed because so much is = built and available that the above quote claims is not available. >=20 > armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or > amd64 due to the fragmented nature of the arm world. On the platforms > we run on and create releases for, however, it's my opinion that it is > Tier 1: it has been running in production a while, things people > expect from a FreeBSD system are present, you can get decent support > if you ask questions, there's no known major gotchas in deploying this > hardware. The only remaining annoying issue is the 'u-boot' problem > where we have to have a different u-boot image for every board and no > standardized way to convert a 'generic' image into one that's specific > for specific boards. For x86 this is all done with the installer since > that boot environment is more standardized. Does this last issue keep > arm from being Tier 1? That's a judgement call, but I think the > project should promote w/o this last issue. Interesting and good to know. Thanks. I might have guessed that going along with the u-boot issue would be the = fanout in: 11.0/sys/arm/ . . . allwinner/a10/ allwinner/a20/ allwinner/a31/ allwinner/a83t/ allwinner/h3/ . . . broadcom/bcm2835/ . . . (Full list not shown.) I was thinking that this might make the tier level specific to the = status of each such directory's content so that it was the combination = of that and the sysutils/u-boot-*/ status that made the difference for = assigning the level. I'd guess that lack of a usable directory in = either place would not be tier 2 even. Similarly until the required = sys/arm/*/* and sysutils/u-boot-*/ directory-tree content have reached a = sufficiently complete status. I'd expect that there will always be a lag for what exists in the world = vs. what has these materials worked out in FreeBSD. >> Also from https://www.freebsd.org/platforms/arm.html : >>=20 >>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms = follow a set of standard conventions, and a single FreeBSD build will = work on hardware from multiple vendors. As a result, FreeBSD will = provide official releases for FreeBSD/arm64 and packages will be = available. FreeBSD/arm64 is on the path to becoming a Tier 1 = architecture. >>=20 >> Will 11.0-RELEASE make arm64/aarch64 Tier 1? >>=20 >> [I will note that, while there are no official builds for the Pine64 = family (A64 based) that are under the Allwinner arm activity, the SOC's = involved are Cortex-A53 64-bit arm based. They likely do not fit in the = "standard conventions" or arm64/aarch64 would be where they would have = been supported. Some rewording might be appropriate for the above quote = as well.] >=20 > No. aarch64 isn't Tier 1 yet. There's many small bits that are > missing. It is quite solidly Tier 2, but we don't have a linker, we > don't have widespread hardware availability, we don't have production > experience with the platform. Most things work, but there's still some > gotchas. There's still the 'u-boot' problem with many arm64 systems > because for systems that use u-boot to bootstrap UEFI, you need a > different image for each board (some closely related board families > can get by with one to be pedantic). All these issues are still > significant barriers to production use. It's not been officially > promoted yet and I don't think the time is quite right yet. Intersting as well. I'd guess that conceptually this probably would = apply to both: sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/ (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ ) and. . . sys/arm64/cavium/ sys/arm64/cloudabi64/ So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a = difference yet for tier level. > Warner Thanks again for the notes. =3D=3D=3D Mark Millard markmi at dsl-only.net