Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Qnap TS-219P+ Kernel 5.9.0-1-marvell

48 views
Skip to first unread message

basti

unread,
Nov 3, 2020, 8:20:03 AM11/3/20
to
Hello, I have try to update my Kernel.

Not enough space for kernel in MTD 'Kernel' (need 2316696 but is
actually 2097152).

It seems that Debian ("Bullseye") no longer will run with that.

basti

unread,
Nov 3, 2020, 5:00:02 PM11/3/20
to


Am 03.11.20 um 21:33 schrieb Uwe Kleine-König:
> Hello basti,
>
> On 11/3/20 1:20 PM, basti wrote:
>> Not enough space for kernel in MTD 'Kernel' (need 2316696 but is
>> actually 2097152).
>>
>> It seems that Debian ("Bullseye") no longer will run with that.
> For now it is not even certain that bullseye will include support for
> armhf at all. See
>
> https://release.debian.org/bullseye/arch_qualify.html
>
> (Disclaimer: I don't know how recent this table is and if there are
> efforts to change that, but TTBOMK this is the current official state.)
>
> Best regards
> Uwe
Qnap TS-219P+ is armel

Philippe Clérié

unread,
Nov 3, 2020, 5:30:02 PM11/3/20
to
Things may have changed but last I heard was that buster would be the
last release that include armel. And that was during development.

I have a 212P and a HS210. Plus a few more I maintain for customers.
Loosing armel is unpleasant, but probably inevitable. Fortunately,
buster will still be around for a few more years.

:-)

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>

Timo Jyrinki

unread,
Nov 5, 2020, 3:40:03 AM11/5/20
to
ti 3. marrask. 2020 klo 22.44 Uwe Kleine-König (u...@kleine-koenig.org)
kirjoitti:
> For now it is not even certain that bullseye will include support for
> armhf at all. See

Just noting that I love how many times these discussions occur along
the lines of "armhf starts to be quite old and with problems, not sure
how long it is going to be supported" and then the opportunity to
delightfully answer "well... it's armel" :)

Some bits of history, these QNAP devices are not ancient as such, they
were announced in 2013. But they happened to use a Marvell Kirkwood
chipset which is only ARMv5, using an ARM core that was announced in
2001 (with some Wikipedia checking). ARMv7 ie armhf cores would have
been available since 2007.

A bit similarly my Openmoko GTA02 in 2008 had ARMv4 (the Debian armel
baseline) compatible CPU, which had an ARM core announced in 1998.
Sometimes new things are a bit slow to trickle.

With Debian 10 LTS support until 2024 the lifetime of these QNAP
devices would be max 11 years if bought on the release year, which is
a bit short for a solid piece of hardware. I'll need to investigate
options latest by 2024, like maintaining the couple of externally
visible network services myself in case of security updates.

Anyway, I'm extremely happy with Martin Michlmayr's original work on
the official Debian support for these old QNAP Orion/Kirkwood based
devices, and the problem solving we've all done together. They have
brought me many good Debian NAS years.

-Timo

Arnd Bergmann

unread,
Nov 5, 2020, 6:00:04 AM11/5/20
to
On Thu, Nov 5, 2020 at 9:29 AM Timo Jyrinki <timo.j...@gmail.com> wrote:
>
> ti 3. marrask. 2020 klo 22.44 Uwe Kleine-König (u...@kleine-koenig.org)
> kirjoitti:
> > For now it is not even certain that bullseye will include support for
> > armhf at all. See
>
> Just noting that I love how many times these discussions occur along
> the lines of "armhf starts to be quite old and with problems, not sure
> how long it is going to be supported" and then the opportunity to
> delightfully answer "well... it's armel" :)
>
> Some bits of history, these QNAP devices are not ancient as such, they
> were announced in 2013. But they happened to use a Marvell Kirkwood
> chipset which is only ARMv5, using an ARM core that was announced in
> 2001 (with some Wikipedia checking). ARMv7 ie armhf cores would have
> been available since 2007.

The core itself is not that old either: the dual-issue ARMv5 cores from
Marvell in the Kirkwood SoC only arrived on the market around 2009
and were competitive with Cortex-A8 on integer workloads but
they lacked the ARMv7 and VFP/NEON instructions.
Marvell added support for that two years later in the PJ4 core that
evolved from this pipeline design.

Later ARMv5 processors were indeed based on the old ARM926 core
from 2001, and these are still getting put into new SoCs and SiPs such
as Microchip SAM9x60 or Allwinner F1C200s. These are not going away
any time soon, but they are at the absolute bottom price for Linux
systems.

I was hoping to see two more Debian armel releases to run on that
class of ARM926 hardware, but something has to be done about the
build infrastructure as the Marvell based machines are at the end of
their useful life and the newer low-end machines cannot replace them
either.

> A bit similarly my Openmoko GTA02 in 2008 had ARMv4 (the Debian armel
> baseline) compatible CPU, which had an ARM core announced in 1998.
> Sometimes new things are a bit slow to trickle.

I would compare it more to Cortex-A17 based chips that came out in 2014,
two years after ARMv8 was introduced. This was the peak for ARMv7
and any later designs were either 64-bit or based on the low-end Cortex-A5
and Cortex-A7 cores.

Arnd

Paul Wise

unread,
Nov 5, 2020, 9:10:03 AM11/5/20
to
On Thu, Nov 5, 2020 at 10:54 AM Arnd Bergmann wrote:

> I was hoping to see two more Debian armel releases to run on that
> class of ARM926 hardware, but something has to be done about the
> build infrastructure as the Marvell based machines are at the end of
> their useful life and the newer low-end machines cannot replace them
> either.

We are building both armhf and armel on the Ampere arm64 machines now,
but there are some annoying lockups that are being worked on by zumbi
and the Ampere folks. Both arches are thus equivalent from a buildd
hardware perspective, the only differentiating factor would be the
number of porters, the release team recently sent their porter roll
call for Debian bullseye, so you might want to respond to that:

https://lists.debian.org/msgid-search/CAM8zJQvyaL0quk57Tyzqb4ji...@mail.gmail.com/firsthit

--
bye,
pabs

https://wiki.debian.org/PaulWise

Paul Gevers

unread,
Nov 13, 2020, 3:00:03 PM11/13/20
to
Hi,

On Thu, Nov 5, 2020 at 10:54 AM Arnd Bergmann wrote:

> I was hoping to see two more Debian armel releases to run on that
> class of ARM926 hardware, but something has to be done about the
> build infrastructure as the Marvell based machines are at the end of
> their useful life and the newer low-end machines cannot replace them
> either.

I think for these QNAPs specifically, that kernel image size issue at
the start of this thread is really the killing thing. I recall that I
happened to catch the changelog in the linux package [1]. I don't assume
that has changed.

Paul
PS: I'm not subscribed to this list

[1]
https://tracker.debian.org/news/1052781/accepted-linux-527-1-all-source-into-unstable-unstable/

* [armel/marvell] Increase maximum image size (fixes FTBFS):
- This removes support for QNAP TS-109, TS-119, TS-209, TS-219, TS-409,

signature.asc

Martin Michlmayr

unread,
Nov 18, 2020, 10:00:02 PM11/18/20
to
* basti <maili...@unix-solution.de> [2020-11-03 13:20]:
FWIW, I've added a clear notice about this to my QNAP pages now.

--
Martin Michlmayr
https://www.cyrius.com/
0 new messages