freebsd stable - Sep 2016 - 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants?

On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard <markmi at 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
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 at
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.
> 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.

Warner

On 2016-Sep-24, at 2:11 PM, Warner Losh <imp at bsdimp.com> wrote:
> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard <markmi at
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 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 at
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