Re: Status of Debian on QNAP
I totally agree with Arnd. We have a bizillion boards based on iMX28,
iMX27 and S3c24xx and S3x64xx out there. And actually they are running
Please do not drop their support!
On 11/20/20 2:20 PM, Arnd Bergmann wrote:
On Fri, Nov 20, 2020 at 6:36 AM Martin Michlmayr <firstname.lastname@example.org> wrote:
QNAP support won't be in Debian 11 (and probably the whole armel port
will be dropped). Support in the Debian kernel package was disabled
in August 2019 due to size issues.
While I still get emails about Debian on QNAP, the amount of email
has definitely decreased over the years, so I think by the time
Debian 10 reaches its end of life most people will be okay with
decommissioning the hardware (or running an unsupported OS).
I would hope that the armel port can be kept as an official release
for longer. While I do not use it myself, I would point out that even the
move from ARMv4T to ARMv5 in Buster caused some alarm since it
removed the upgrade path for older embedded systems that ship with
a Debian user space and that are still in service.
I agree that the Marvell embedded platforms are reaching the
end of their life as a target (including the ones that still fit the image)
but there are still enough hardware platforms with a longer service
life than kirkwood but a CPU core that is too old to run the armhf
- BCM2835 (Raspberry Pi zero) will ship until 2026, four
years longer than the ARMv7 BCM2836 model
- Microchip sam9 introduced a new sam9x60 SoC last year,
which will be supported for a long time along with the older
- Allwinner F1C200s and similar chips are the cheapest option
today for building a Linux system, and so far keep getting
updated hardware revisions
- NXP i.mx23/i.mx28 and lpc32xx have a large installed hardware
base, some of which have long service lives.
- Hisilicon sd5203 kernel support was added recently.
- there are many ARMv5/ARMv6 SoCs with kernel support that
are a similar vintage to kirkwood, and together have enough
of a user base that someone is going to need them, even if
no single one of them would stick out:
asm9260, cns3xxx, davinci, i.mx3, iop32x, ixp4xx, mmp,
omap1, omap2, oxnas, pxa, s3c24xx, and s3c64xx.
The main question for what would happen with the armel port
I think is what kernel to ship. When the marvell kernel gets
retired, the only kernel package left would be the raspberrypi
variant, and that is a bit silly given that it has its own raspbian
armhf port that is much more suitable for that specific
I think a better alternative might be to enable the kernel from
the armhf port to be built as a package for armel, with
the minimum CPU level set to ARMv6K to allow it to be
used on BCM2835 along with all the ARMv7 and ARMv8
platforms that armhf supports. The key here is minimizing the
maintenance and testing effort. Anyone using the armel
port on actual ARMv5 hardware likely wants to build their
own kernel anyway.
Eurek s.r.l. |
Electronic Engineering | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212