Add QNAP model Q703

[Kevin Read]

Hi all,

not sure if this is still relevant since kirkwood no longer seems
supported OOTB, but I wanted to let you know that I installed debian
buster Kirkwood on a Fujitsu Celvin Q703. It is fully supported by
using the DTB for TS-221, so this patch adds support for this device:

--- flash-debian 2023-08-09 15:19:18.337483643 +0200
+++ flash-debian~ 2022-09-07 00:57:03.000000000 +0200
@@ -30,7 +30,7 @@
"HS-210"* | "Q600" | "Q700" | "TS-110"* | "TS-112"* | "TS-119"* |
"TS-210"* | "TS-212"* | "TS-219"*)
qnap="TS-11x/TS-21x"
;;
- "TS-120"* | "TS-121"* | "TS-220"* | "TS-221"* | "Q703")
+ "TS-120"* | "TS-121"* | "TS-220"* | "TS-221"*)
qnap="TS-11x/TS-21x"
;;
"TS-410"* | "TS-412"* | "TS-419"*)


Thanks and best,
Kevin

PS: is there any way I can help with debugging the 1GB RAM issue? I
applied the mem limit to 768MB in uboot as a workaround but if I can
help in any way with debugging this issue I'm happy to.

[Martin Michlmayr]

Post by Kevin Read
PS: is there any way I can help with debugging the 1GB RAM issue? I
applied the mem limit to 768MB in uboot as a workaround but if I can
help in any way with debugging this issue I'm happy to.

I fear that issue will never get resolved. Andrew Lunn, who was the
most active Kirkwood kernel maintainer at that time, looked into it
and couldn't figure out what was going on. In theory, we could check
what he wrote about it at that time (or ask what he remembers) and
report it upstream with the hope that someone will investigate but I'm
not sure who that someone would be.

(Maybe Arnd Bergmann but I suspect his plate is full already.)

It's particularly annoying because this is a regression and the Linux
people care a lot about fixing regressions, but I think at this point
there aren't many Kirkwood users left anyway...

[Arnd Bergmann]

Post by Martin Michlmayr

Post by Kevin Read
PS: is there any way I can help with debugging the 1GB RAM issue? I
applied the mem limit to 768MB in uboot as a workaround but if I can
help in any way with debugging this issue I'm happy to.

I fear that issue will never get resolved. Andrew Lunn, who was the
most active Kirkwood kernel maintainer at that time, looked into it
and couldn't figure out what was going on. In theory, we could check
what he wrote about it at that time (or ask what he remembers) and
report it upstream with the hope that someone will investigate but I'm
not sure who that someone would be.
(Maybe Arnd Bergmann but I suspect his plate is full already.)
It's particularly annoying because this is a regression and the Linux
people care a lot about fixing regressions, but I think at this point
there aren't many Kirkwood users left anyway...

I forgot what the problem was, but it sounds like the difference
between CONFIG_VMSPLIT_3G and CONFIG_VMSPLIT_3G_OPT in the kernel.

Ideally you'd want to use CONFIG_VMSPLIT_3G_OPT in a kernel for
a system with 1GB of contiguous RAM, but I don't know if the
problem here was caused by picking this or not picking this.

Regardless, you could try picking whichever is the other one.

Arnd

[Timo Jyrinki]

Post by Arnd Bergmann

Post by Kevin Read
PS: is there any way I can help with debugging the 1GB RAM issue? I
applied the mem limit to 768MB in uboot as a workaround but if I can
help in any way with debugging this issue I'm happy to.

I forgot what the problem was, but it sounds like the difference
between CONFIG_VMSPLIT_3G and CONFIG_VMSPLIT_3G_OPT in the kernel.
Ideally you'd want to use CONFIG_VMSPLIT_3G_OPT in a kernel for
a system with 1GB of contiguous RAM, but I don't know if the
problem here was caused by picking this or not picking this.

I tried that around
https://lists.debian.org/debian-arm/2018/06/msg00007.html (still there
at https://people.debian.org/~timo/qnap/) and had 1GB in use but some
other problems with my build.

I have continued to run with 768MB which is enough for my use cases, and
with the Debian 11 (after the flash partition restructuring script and
dist-ugprade) the system has been rock solid.

Now of course I would be curious whether anyone has tried upgrading any
Kirkwood devices to Debian 12, but bullseye has luckily plenty of
support remaining.

-Timo

[Timo Jyrinki]

Post by Timo Jyrinki
I have continued to run with 768MB which is enough for my use cases, and
with the Debian 11 (after the flash partition restructuring script and
dist-ugprade) the system has been rock solid.
Now of course I would be curious whether anyone has tried upgrading any
Kirkwood devices to Debian 12, but bullseye has luckily plenty of
support remaining.

The answer was yes and now I'm in that group of Debian 12 users as well.

https://github.com/amouiche/qnap_mtd_resize_for_bullseye/issues/41

Long live kirkwood!

-Timo

[Martin Michlmayr]

PS: is there any way I can help with debugging the 1GB RAM issue? I applied
the mem limit to 768MB in uboot as a workaround but if I can help in any way
with debugging this issue I'm happy to.

There has been an unverified report that 1GB is working with the
kernel from bookworm:
https://github.com/amouiche/qnap_mtd_resize_for_bullseye/issues/45

If you have a serial console, can you try booting without the mem=768M
flag?