On 2016-Sep-24, at 2:11 PM, Warner Losh <[email protected]> wrote: > On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard <[email protected]> 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 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. >> >> "does not provide official releases or pre-built packages"? >> >>> # 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 >> >>> # 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 for >> RPI2? >> >> 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. > > 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 : >> >>> 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. >> >> Will 11.0-RELEASE make arm64/aarch64 Tier 1? >> >> [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.] > > 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. === Mark Millard markmi at dsl-only.net _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
