Hi
On Sat, Sep 09, 2023 at 11:13:56AM +0200, Paul Gevers wrote:
> If we're now reaching the final limit and if it was foreseeable that we
> would reach that limit, then yes it would have made sense to drop armel
> *before* the bookworm release, but alas. If the kernel team can't support
> the kernel on armel, than armel shouldn't be a release architecture for
> trixie. If it's only some devices, than we "just" need to communicate that
> clearly.
We have two armel kernel currently:
- "marvell", for some CPU from Marvell, and
- "rpi", for Raspberry Pi 1 and related devices.
The first one is the one with included size limitations, because those
load the kernel from a pre-defined flash partition, whose size can't be
easily changed by the user. This one is now overflowing for the second
to last documented one in the kernel package config.
The second one is for the original Raspberry Pi 1 type. There we don't
have any size limits, as the kernel is loaded from a file system.
However those systems contain a ARMv6 CPU. So our armel port is only
partially usable anyway, as is is built for ARMv4. There exists with
Raspbian a better suited forked distribution with ARMv6 as target.
So yes there is a small number of devices we can still support with the
armel port, but where we are a bad choice.
Everything newer is ARMv7, supported by the armhf port, or ARMv8,
supported by the arm64 port.
Latest popcon for stable is:
linux-image-marvell: 31
linux-image-rpi: 7
Debian itself does not have any armel hardware. Everything is done on
armhf or arm64. Sadly the armhf supporting systems are already in the
progress of drying up. Even some ARMv8 vendors do not longer include
32bit support.
Bastian
--
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
stardate 4842.6
