It feels kind of backward to ask this now while it should probably have been a defining point and should be written clearly on the README. Let's discuss it then.
It is understood that:
- Core platform/target is the Raspberry Pi.
- BSF is using Pi4 only for this project. Other non-Pi hardware wont be updated.
- We don't want to support any generic computer (as does IIAB).
- Kiwix hotspot has been working on all standard Pi models (Zero, 1, 2, 3, 4, 400).
Raspberry Pi has gotten quite diverse over the years. Here's a matrix of Pi models that are of interest to us (so no Pico nor Compute Module).
Given the service we provide, two characteristics are of interest to be discussed:
- CPU architecture
- WiFi capability
WiFi capability
- Do we want to support models without integrated Wireless?
- If so, to what extent ? Do we want to provide a list of WiFi chipsets (or makers) we'd support?
It is understood that we want, at some point, to clearly state the performance capabilities of the solution (“supports users on a Pi 4”) which would not be possible with those.
We could still support other chipset in a “best effort” manner: try it and let us know if that works. That's kind of the current state as we do include (specifically we don't remove) a number of WiFi chipsets and should those support AP mode and the options we use (very limited at the moment offspot/offspot-config#2), it should work.
Impact: we currently don't support no WiFi so we'd need to at least introduce a graceful fallback.
CPU architecture
Pi models can be split over three different architectures:
armv6
, also called armel
is 32b for Pi Zero
and Pi 1
. Those were released in 2012-2014 and feature at most 512MB RAM
armv7
also called armhf
is 32b for Pi 2
only, released in 2015 with 1GB RAM.
armv8
also called aarch64
or arm64
is 64b and powers all the other (newer) models.
Important note
armhf
means armv7
in Debian lingo but armhf
means armv6+vfp2
in raspbian one (All armv6 Pi have a VFPv2).
- A Debian system running an
armv7l
Kernel with armhf
dpkg architecture is thus different from a Raspbian (or base-image) running an armv6l
kernel on an armhf
dpkg-architecture.
- Debian supports
armv6
but calls it armel
in dpkg.
- ⚠️ adding debian source list must be done carefully, forcing the architecture.
https://eloydegen.com/blog/posts/arm-linux-distribtions/
RaspiOS support
Obviously, raspiOS supports all three platforms. Its armhf
image includes four kernels (armv6-32, armv7-32, armv8-32 and armv8-64) but the binaries are all armv6-compatible.
RaspiOS also offers a second image named arm64
with binaries for armv8.
We currently offer similar choice.
If RaspiOS does it and we're based off raspiOS, why are we even discussing this?
Drawbacks of keeping armv6
and armv7
armv6
and armv7
have very different statuses and support and the latter is a lot more common but regarding our table above, keeping it would be only to support Pi2 which was release in 2015 without integrated WiFi.
Docker
- Docker works on
armv6
via raspbian and/or debian package but included version is close to 2yo. Not much of a problem now but sill limiting.
- Docker has a repository with latest version that is the recommended way to install but this works only for
armhf
(debian) so it doesn't work on armv6.
- Docker has static builds for armv6 but those are broken and doesn't work.
- It's almost impossible to test armv6 image as docker uses qemu for that and we don't control exactly how it's called.
- Docker image for
library/debian
(base image for most language-specific images) doesn't even provide an arm/v6
variant but an arm/v5
variant. Not sure how the (undocumented) behavior is when requesting v6.
$ docker run --platform linux/arm/v5 -it debian bash -c 'uname -m && dpkg --print-architecture && file /lib/arm-linux-gnueabi/ld-2.31.so
armv7l
armel
/lib/arm-linux-gnueabi/ld-2.31.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=261b75978776d17373d9f528db8cd5d50ecf528f, stripped
$ docker run --platform linux/arm/v6 -it debian bash -c 'uname -m && dpkg --print-architecture && file /lib/arm-linux-gnueabi/ld-2.31.so
armv7l
armel
/lib/arm-linux-gnueabi/ld-2.31.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=261b75978776d17373d9f528db8cd5d50ecf528f, stripped
$ docker run --platform linux/arm/v7 -it debian bash -c 'uname -m && dpkg --print-architecture && file /lib/arm-linux-gnueabi/ld-2.31.so
armv7l
armel
/lib/arm-linux-gnueabi/ld-2.31.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=261b75978776d17373d9f528db8cd5d50ecf528f, stripped
Node
Python
- Most python libraries are pure-python and don't matter the architecture (python works on all of them)
- A few important ones do matter (like Pillow which is ultra-dominant for image processing)
- Important projects do provide binary packages (wheels) but those are specific to a platform (interpreter, system, architecture)
- Architecture is taken from kernel so in-docker (or docker buildx to be more specific), it's either seen as aarch64 or armv7l. This happens both when finding package and when building package. Given not many people care about arm 32b, it may lead either to improper package or not finding the package.
- Not found package means building from source which is very very long in qemu-arm and requires compilation tools, and libraries and all (if it's working)
In conclusion, armv6
support has lost most interest for people and has thus became exotic. armv7
has better support but is still 32b and supporting it wouldn't make much sense.
I suggest we agree on dropping support for armv6
and armv7
and thus only publish an arm64
image that will work on all the newer Pi which are all ARMv8 (including the Pi Zero 2 W).
This will keep us (for now) in a hack-free, up-to-date platform that we can safely build-upon. Images will be easier to build and maintain as well.