Date: Sat, 24 Sep 2016 15:11:15 -0600 From: Warner Losh <imp@bsdimp.com> To: Mark Millard <markmi@dsl-only.net> Cc: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants? Message-ID: <CANCZdfqM17qzZg2SqwJRTWO67KCnAC%2BHYKatcb8CBHF3TM7kFg@mail.gmail.com> In-Reply-To: <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net> References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net> <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard <markmi@dsl-only.net> wrote: > [A resend since I forget to list free-arm in the To: the first time.] > > From https://www.freebsd.org/platforms/arm.html : > >> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD project d= oes not provide official releases or pre-built packages for this platform d= ue to it primarily targeting the embedded arena. However, FreeBSD/ARM is be= ing actively developed and maintained, is well supported, and provides an e= xcellent framework for building ARM-based systems. FreeBSD/arm supports ARM= v4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 processors,= including SMP on the latter. > > "does not provide official releases or pre-built packages"? > >> # uname -apKU >> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: Sun Au= g 28 03:17:54 PDT 2016 markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/s= rc/sys/RPI2-NODBG arm armv6 1100502 1100502 > >> # pkg search '.*' | wc >> 21349 155540 1596736 > > 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 fo= r RPI2? > > Even if all the officially built arm-armv6 variants stay tier 2, the word= ing on the web page likely needs to be changed because so much is built and= available that the above quote claims is not available. 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. > Also from https://www.freebsd.org/platforms/arm.html : > >> 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 hard= ware from multiple vendors. As a result, FreeBSD will provide official rele= ases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 is on = the path to becoming a Tier 1 architecture. > > Will 11.0-RELEASE make arm64/aarch64 Tier 1? > > [I will note that, while there are no official builds for the Pine64 fami= ly (A64 based) that are under the Allwinner arm activity, the SOC's involve= d 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.] 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. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqM17qzZg2SqwJRTWO67KCnAC%2BHYKatcb8CBHF3TM7kFg>