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.



<div id="geary-body" dir="auto"><div>Hi all,</div><div><br></div><div>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 devi

* Kevin Read <me@kevin-read.com> [2023-08-09 15:20]:

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...

--
Martin Michlmayr
https://www.cyrius.com/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Aug 9, 2023, at 16:08, Martin Michlmayr wrote:

* Kevin Read <me@kevin-read.com> [2023-08-09 15:20]:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Arnd Bergmann kirjoitti 11.8.2023 klo 11.01:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Kevin Read <me@kevin-read.com> [2023-08-09 15:20]:

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?

--
Martin Michlmayr
https://www.cyrius.com/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Timo Jyrinki kirjoitti 24.8.2023 klo 17.09:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)