Date: Sat, 24 Sep 2016 17:12:24 -0700 From: Mark Millard <markmi@dsl-only.net> To: Warner Losh <imp@bsdimp.com> 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: <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net> In-Reply-To: <CANCZdfqM17qzZg2SqwJRTWO67KCnAC%2BHYKatcb8CBHF3TM7kFg@mail.gmail.com> References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net> <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net> <CANCZdfqM17qzZg2SqwJRTWO67KCnAC%2BHYKatcb8CBHF3TM7kFg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Sep-24, at 2:11 PM, Warner Losh <imp@bsdimp.com> wrote: > 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.] >>=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2>