Re: Future of armv7

On Fri, Nov 14, 2025 at 6:09 PM John Baldwin <jhb@freebsd.org> wrote:
>
> Two and a half years ago when we first began talking about deprecating
> 32-bit architectures in 15.0, we decided to keep armv7 for at least
> the stable/15 branch but did not commit to anything beyond that.  Now
> that 15.0 is close to shipping and we are turning our development
> focus to 16.0, we should figure out what we want to say about armv7
> for 16.x in the 15.0 release notes so that users have suitable notice.
>
> In particular, do we want to deprecate armv7 in 16.0 (similar to the
> state of 32-bit powerpc in 15.0), or do we want to keep it?
>
> My initial suggestion is that we announce that we plan to deprecate it
> in 16.0.  In that case, I would also suggest that we follow a similar
> process of keeping armv7 for most of the lifetime of 16.0 so that we
> can reneg if need be during the 16.0 cycle.
>
> What do other folks think?
>
> --
> John Baldwin

Short answer: I would keep older ARM code (do not delete) even if
"unsupported" so people can use it, but energy and focus should go to
modern CPU/SBC support.

Long answer:

If there are no developers available to maintain armv7 then it can be
marked as "no support" or "tier 3" or something like that. But I would
not delete any code so people interested may still build, fix and make
things work!! I still have whole bunch of the older boards and if I
ever want to run anything on them that would be NuttX or FreeBSD. I
also understand focus on modern SBC which I support because these
computers are more available very cheap and amazing computing power vs
energy use, details below :-)

I recently bought rPI-Zero-2W, rRPI 4B (1,2,8GB) and rPI 5 8GB for my
distributed NuttX build and runtime test farm that runs on FreeBSD
(can run on other OS too), all details will be presented in open
access paper that I am processing with the publisher right now, below
simple time-energy-cost comparison:

CPU | cores | Build time Single/Multi core | Power consumption Idle/Peak | Price
rPI-0-2W | 4 | 1187 / 412 s | 1.5 / 5 W | 25EUR
rPI-4B | 4 | 294 / 153 s | 2 / 5 W  | 85EUR
rPI-5 | 4 | 97 / 44 s | 2.3 / 7W | 90EUR
AMD FX8320 | 8 | 198 / 45 s | 175 / 280 W | 250EUR
iUltra9-285K | 24 | 101 / 12 s | 100 / 255 W | 2000EUR
Apple M2Pro | 12 | 90 / 22 s | 9 / 53 W | 3000EUR

This clearly shows that rPI-5 already compares to older PC in build
time at 40x lower power consumption and over 2x lower price. Compared
to modern PC it is only 2x slower with over 50x smaller energy
consumption and over 22x smaller price. Compared to MacStudio it is 2x
slower and over 7x more energy efficient at 33x smaller price. Also
worth noting that rPI-5 which is almost the same price as rPI-4B can
have NVME disk attached (needs some additional adapter I dont yet
have) that should dramatically improve IO times over SD card storage
and probably get even better result of build time vs cost. Another
thing to notice is the idle power consumption ~1..2W for the SBC and
peak energy is only 5..7W (in theory 5V*3A~15W) so it can be powered
with energy harvesting!!

I know rPI uses BCM chips which are undocumented. For now we port
NuttX to rPI-4B. We contacted rPI CTO and got confirmation the
documentation available is the only documentation ever created. So the
source of knowledge to write drivers is the rPiOS/Linux source code
(GPL). Most people agree we do not need to copy-paste the code that
would propagate GPL taint but it is okay to use that code as a
reference point for drivers with other licensing model whether it is
BSD, Apache, MIT.

Have a good day folks :-)
Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info