Re: FreeBSD 14: Poll armv6 deprecated or removed

From: Mark Millard via freebsd-arch <>
Date: Thu, 04 Nov 2021 18:53:18 UTC
On 2021-Nov-4, at 07:50, tech-lists <> wrote:

> On Wed, Nov 03, 2021 at 09:52:19AM -0700, Kevin Bowling wrote:
>> FreeBSD wants any audience to help support the features they demand. Since
>> this particular audience has not, what may cause it to in the future? Not a
>> rhetorical question nor a vote for removing, this is a perennial problem in
>> open source and I am curious how you think this works so I can incorporate
>> it into my opinion.
> Maybe the audience isn't demanding? It doesn't mean the audience isn't
> there. perl and python and shell scripting work fine on these boards. Issues with these things would I guess be taken up with those maintainers. The hardware is very stable. I'd expect that a lot more users might pipe up if their freebsd os needed updating for some newer python only to find it couldn't be updated anymore. The first of those to pipe up i'd guess be those with boards that have an internet-facing connection, as the pressure to keep fully updated is a lot less within a firewalled LAN.
> OpenBSD immediately after install has an email on the system giving a
> method to send in a dmesg. I don't know if it gives them a handle on the
> number of users and what their hardware is, but it's better than nothing
> at all, which is where FreeBSD is. Although there is a port called
> sysutils/hw-probe, one needs to know about it first. It's not in base.
> For armv6 in particular though, I've not heard of any reason justifying
> *why* getting rid of it. At least if it's in base we can compile ports
> for it ourselves. mips/mips64 stopped because the working group stopped
> working with it, fair enough. This isn't the case with armv6.

[This note is in part because a prior note oof mine did not make it to

Without one or more developers willing to keep ARM11 based RPi* FreeBSD
working as FreeBSD updates, the code will break. Other architectures
have been removed for such. Folks that do not want to work on such code
do not want to have to work on it to keep FreeBSD building and operating
for other architectures that have active developmers/maintainers.

If there were active FreeBSD developers for ARM11 RPi*'s, the removal
would have been unlikely to be proposed at all, even if the use was
minor. FreeBSD is driven by the developer context directly, not the
usage context directly. The usage context only drives things when the
that context pays for developers to support the usage. (Think companies
that use FreeBSD in a way that involves being sure supporting
development and/or maintenance is done for the variant(s) they use.)

[FreeBSD for aarch64 RPi*'s seems likely to suffer the same fate at
some point because RPi* specifics are involved: generic aarch64 code
is not sufficient. The aarch64 tier 1 status does not imply a
requirement to support aarch64 RPi*'s.]

> It might be helpful looking from another viewpoint - why is armv6 a
> tier1 architecture on NetBSD?

Something like, say, aarch64 being tier 1 on FreeBSD does not imply
support for all existing and future aarch64 systems. The same goes for
armv6. The same is true of NetBSD.

NetBSD supports a lot of systems that FreeBSD does not. That fact has
never justified having support for those systems in FreeBSD. FreeBSD
has previously removed support for things NetBSD still supports.
Different developers, different criteria.

NetBSD will always be likely to support far more systems than FreeBSD.

Mark Millard
marklmi at
( went
away in early 2018-Mar)