Debian on Zyxel NAS326

musv,

Data point: I've tested a 1GB file xfer with NFS on 4.12.x, and it did not cause me any problem.

I've not yet tried 4.13.2, which I have planned to release.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I tried kernel 4.13.7 today. To get sure the problem is not related to my config, I took the config of 4.10.10 (the last fully working kernel) and used also the dts file from April.

The problem occurred again:

Okt 18 21:34:23 nas kernel: rpc-srv/tcp: nfsd: sent only 56968 when sending 65644 bytes - shutting down socket

Hence, I can eliminate every config changes. It must be the network driver in the kernel.

bodhi Wrote:
-------------------------------------------------------
> Data point: I've tested a 1GB file xfer with NFS on 4.12.x, and it did not cause me any problem.

It's not caused by a single file. For me the most likely way to reproduce it, is to send files not with full speed over a longer period of time - half an hour up to an hour. That's why I wrote explicitly: listen to music files, that are stored on the nfs device.

So far I downgraded to 4.10.10.

musv Wrote:
-------------------------------------------------------
> I tried kernel 4.13.7 today. To get sure the
> problem is not related to my config, I took the
> config of 4.10.10 (the last fully working kernel)
> and used also the dts file from April.
>
> The problem occurred again:
>

Okt 18 21:34:23 nas kernel: rpc-srv/tcp:
> nfsd: sent only 56968 when sending 65644 bytes -
> shutting down socket

>
> Hence, I can eliminate every config changes. It
> must be the network driver in the kernel.
>
> bodhi Wrote:
> -------------------------------------------------------
> > Data point: I've tested a 1GB file xfer with NFS
> on 4.12.x, and it did not cause me any problem.
>
> It's not caused by a single file. For me the most
> likely way to reproduce it, is to send files not
> with full speed over a longer period of time -
> half an hour up to an hour. That's why I wrote
> explicitly: listen to music files, that are stored
> on the nfs device.
>
> So far I downgraded to 4.10.10.

Yes, it sounds like the ethernet driver TCP buffer xmit problem.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I'm currently in contact with the mvneta developer from free-electrons.com. With their help I'm testing around.

The first step was to take the mvneta driver directory (kernel/driver/net/ethernet/mvneta) from 4.10.10 and replace the driver from 4.13.7. I had to modify a few lines but I got the 4.10.10 driver running in 4.13.7 and it works perfectly without any issues.

In the whole driver update list, they have marked 3 patches as potentially suspicious. So I'll revert those patches and see, which one is the critical one.

musv,

> In the whole driver update list, they have marked
> 3 patches as potentially suspicious. So I'll
> revert those patches and see, which one is the
> critical one.

There is one TCP buffer related patch I think the most suspicious.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I am still at 4.9.5-tld-8 and am planning to upgrade to the latest available kernel soon.
Do I gather correctly from the recent posts that it's better to wait with the upgrade until the mvneta issue is sorted out?

kralan Wrote:
-------------------------------------------------------
> I am still at 4.9.5-tld-8 and am planning to
> upgrade to the latest available kernel soon.
> Do I gather correctly from the recent posts that
> it's better to wait with the upgrade until the
> mvneta issue is sorted out?

It's really up to you. If your use case is similar to musv then I'd say don't upgrade. OTOH, I am not sure when this will be sorted out. If there is no activity upstream for a while, then I would have to repeat musv test and try patching the mvneta driver myself.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Here's the discussion about the issue:

https://www.spinics.net/lists/netdev/msg461420.html

kralan:
You can upgrade to at least to Kernel 4.10.x without issues. At least according to my tests to problematic patch is:

https://github.com/torvalds/linux/commit/2a90f7e1d5d04e4f1060268e0b55a2c702bbd67a#diff-851bfc43b3ca32355b4c07d29dbba7f0

If you just revert this patch before compiling the kernel, you won't suffer any nfs-server issues. If you don't use nfs or samba as a server on the Zyxel, you'll probably not notice any regressions.

Thanks musv! I'll take a look and incorporate in the next release.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Just to give some feedback. The problem has been resolved.

If you build the next kernel image, just check if this patch has been applied:
https://www.spinics.net/lists/netdev/msg466892.html

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 64a04975bcf8..bc93b69cfd1e 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -816,11 +816,14 @@ static void mvneta_txq_pend_desc_add(struct mvneta_port *pp,
 {
 	u32 val;
 
-	/* Only 255 descriptors can be added at once ; Assume caller
-	 * process TX desriptors in quanta less than 256
-	 */
-	val = pend_desc + txq->pending;
-	mvreg_write(pp, MVNETA_TXQ_UPDATE_REG(txq->id), val);
+	pend_desc += txq->pending;
+
+	/* Only 255 Tx descriptors can be added at once */
+	do {
+		val = min(pend_desc, 255);
+		mvreg_write(pp, MVNETA_TXQ_UPDATE_REG(txq->id), val);
+		pend_desc -= val;
+	} while (pend_desc > 0);
 	txq->pending = 0;
 }

Thanks musv!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I'm currently compiling kernel 4.16.3. There's a new setting:

CPU Power Management -> CPU frequency scaling -> Armada 37xx CPUFreq support

Quote

This adds the CPUFreq driver support for Marvell Armada 37xx SoCs.
The Armada 37xx PMU supports 4 frequency and VDD levels.

Depends on: CPU_FREQ [=y] && (ARM [=y] || ARM64) && ARCH_MVEBU [=y] && CPUFREQ_DT [=y]

Is this working for our Armada 380 too?

Btw. the patch from 4.14 doesn't apply on 4.16 anymore. I had to remove some printk messages from marvell.c file.

musv,

We are on 4.16.7 already:

https://forum.doozan.com/read.php?2,32146

> CPU Power Management -> CPU frequency scaling ->
> Armada 37xx CPUFreq support
> Is this working for our Armada 380 too?

It is not applicable to A38x.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi Bodhi,

I need some help with kernel-4.18.x. I don't get the mtdparts running. I tried to follow your hints. But the kernel still crashes.

[    0.933092] WARNING: CPU: 0 PID: 1 at drivers/mtd/nand/raw/nand_base.c:2773 nand_subop_get_data_len+0x50/0x94
[    0.943051] Modules linked in:
[    0.946126] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.9-gentoo #2
[    0.952674] Hardware name: Marvell Armada 380/385 (Device Tree)
[    0.958625] [<c01115a0>] (unwind_backtrace) from [<c010cea4>] (show_stack+0x10/0x14)
[    0.966399] [<c010cea4>] (show_stack) from [<c07bbaf8>] (dump_stack+0x88/0x9c)
[    0.973651] [<c07bbaf8>] (dump_stack) from [<c01299e8>] (__warn.part.3+0xbc/0xd8)
[    0.981163] [<c01299e8>] (__warn.part.3) from [<c0129ad4>] (warn_slowpath_null+0x44/0x4c)
[    0.989371] [<c0129ad4>] (warn_slowpath_null) from [<c05b95e0>] (nand_subop_get_data_len+0x50/0x94)
[    0.998452] [<c05b95e0>] (nand_subop_get_data_len) from [<c05c0138>] (marvell_nfc_parse_instructions+0x58/0x238)
[    1.008664] [<c05c0138>] (marvell_nfc_parse_instructions) from [<c05c2774>] (marvell_nfc_naked_access_exec+0x28/0x1ac)
[    1.019397] [<c05c2774>] (marvell_nfc_naked_access_exec) from [<c05b93c4>] (nand_op_parser_exec_op+0x200/0x278)
[    1.029521] [<c05b93c4>] (nand_op_parser_exec_op) from [<c05b6d70>] (nand_reset_op+0x10c/0x15c)
[    1.038250] [<c05b6d70>] (nand_reset_op) from [<c05b9674>] (nand_reset+0x50/0xa8)
[    1.045760] [<c05b9674>] (nand_reset) from [<c05ba8c4>] (nand_scan_ident+0x228/0x1218)
[    1.053706] [<c05ba8c4>] (nand_scan_ident) from [<c05c0ce4>] (marvell_nand_chip_init+0x1a4/0x864)
[    1.062610] [<c05c0ce4>] (marvell_nand_chip_init) from [<c05c1680>] (marvell_nfc_probe+0x2dc/0x458)
[    1.071690] [<c05c1680>] (marvell_nfc_probe) from [<c05438ac>] (platform_drv_probe+0x48/0x98)
[    1.080246] [<c05438ac>] (platform_drv_probe) from [<c0542588>] (driver_probe_device+0x228/0x31c)
[    1.089149] [<c0542588>] (driver_probe_device) from [<c0542758>] (__driver_attach+0xdc/0xe0)
[    1.097617] [<c0542758>] (__driver_attach) from [<c054089c>] (bus_for_each_dev+0x74/0xb4)
[    1.105822] [<c054089c>] (bus_for_each_dev) from [<c05412a0>] (bus_add_driver+0x1c0/0x204)
[    1.114115] [<c05412a0>] (bus_add_driver) from [<c0542ebc>] (driver_register+0x74/0x108)
[    1.122234] [<c0542ebc>] (driver_register) from [<c0102cf8>] (do_one_initcall+0x54/0x208)
[    1.130443] [<c0102cf8>] (do_one_initcall) from [<c0a010cc>] (kernel_init_freeable+0x254/0x2e4)
[    1.139176] [<c0a010cc>] (kernel_init_freeable) from [<c07cfbbc>] (kernel_init+0x8/0x110)
[    1.147384] [<c07cfbbc>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
[    1.154977] Exception stack(0xdf499fb0 to 0xdf499ff8)
[    1.160044] 9fa0:                                     00000000 00000000 00000000 00000000
[    1.168249] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    1.176455] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    1.183111] ---[ end trace 21eeae4e2d71e798 ]---
[    1.187752] ------------[ cut here ]------------
[    1.192388] WARNING: CPU: 0 PID: 1 at drivers/mtd/nand/raw/nand_base.c:2773 nand_subop_get_data_len+0x50/0x94

I compared the my kernel config in the nand-section with your provided one. But there weren't any noticeable differences. I even activated CONFIG_MTD_AR7_PARTS (didn't find any documentation about this thing) and CONFIG_MTD_CMDLINE_PARTS.

My Uboot-Config:

mtdparts=mtdparts=pxa3xx_nand-0:2m(u-boot),2m(env),2m(config),15m(kernel1),110m(rootfs1),15m(kernel2),-(rootfs2)

What did I miss? 4.16.13 (last update) works fine.

Hi musv,

> I need some help with kernel-4.18.x. I don't get
> the mtdparts running.

> What did I miss? 4.16.13 (last update) works fine.

The kernel config did not change. It always has CONFIG_MTD_CMDLINE_PARTS.

The crash happened because you have the DTB appended to uImage. You are not booting with the separate DTB (also not with separate uInitrd, but uInitrd is not the problem). So the bootargs does not have the cmdline mtdparts.

Marvell>> boot

NAND read: device 0 whole chip
Attempt to read outside the flash area
 0 bytes read: ERROR
Booting Gentoo from sda1
AHCI init for unit0
Target spinup took 0 ms.
Target spinup took 0 ms.

Error: SCSI Controller(s) 1B4B:9215 1B4B:9235 not found
scanning bus for devices...
...
  Device 1: (1:0) Vendor: ATA Prod.: ST9500325AS Rev: 0001
            Type: Hard Disk
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
Found 2 device(s).

4787801 bytes read in 125 ms (36.5 MiB/s)
*  kernel: cmdline image address = 0x02000000

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.18.9-gentoo (root@nas) (gcc version 8.2.0 (Gentoo 8.2.0-r2 p1.2)) #2 SMP Wed Sep 26 14:01:03 CEST 2018
[    0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: Zyxel NAS326
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] random: get_random_bytes called from start_kernel+0x8c/0x464 with crng_init=0
[    0.000000] percpu: Embedded 16 pages/cpu @(ptrval) s36812 r8192 d20532 u65536
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 129920
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/sda2 init=/lib/systemd/systemd

I understood you want to make it simple. But I would recommend setting up booting with separate DTB and with uInitrd. The logistics is too cumbersome when you always need to remember to append the DTB. And the ability to boot with appended DTB will be removed from the mainline kernel eventually.

Please let me know if that was indeed the problem or if it was something else (systemd has some problem lately).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Ah, I see. You are running gentoo.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

where does one connect the usb to serial adapter? Is this like a 4 pin on the motherboard?

thistleknot Wrote:
-------------------------------------------------------
> where does one connect the usb to serial adapter?
> Is this like a 4 pin on the motherboard?

Yes. On motherboard. All Zyxel NAS serial header looks like in this post:

https://forum.doozan.com/read.php?3,51739,51919#msg-51919

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

sorry to be a bother

Where is the pin out location on nas326?

does it require soldering?

thistleknot,

> Where is the pin out location on nas326?

Open the box case. It is on the right side (when you are facing the box). Look at somewhere in near midle lower side of the board.

> does it require soldering?

No. The header is factory installed. So it is very easy to find. When you found it. Look at the pin arrangement pattern. There is an empty hole left of GND.

+----+----+           
          |    |    |
+----+----+----+----+----+
|3.3V| TX | RX |    | GND|
+----+----+----+    +----+

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 11/12/2018 11:44PM by bodhi.

you know, I am quite satisfied with this device. I wish it had dm-cache enabled in the kernel... idk if I can compile the kernel outside of the box and ssh in a .so file and insmod it, but that might be ideal considering my use case. I am just trying to enable a read cache. I would use lvm, but...dm-cache isn't enabled. If I could download a basic toolset (any busy box built cache might do) I might be able to build a cache using a compiled program or something. Any ideas. Otherwise I was going to go down this route to setup a zfs read cache (but no write cache, I'll let the os handle that) from a usb 3.0 either flash (~120MBs read) or a usb 3.0 ssd (~500MBs read)

thistleknot,

> I wish it had dm-cache enabled in the kernel...

I'm buiding new kernel to test the IO coherency for Armada 370 and 380. I could configure dm-cache module for you to try. This should be in the kernel, but nobody has requested it!

Are you running my latest released kernel 4.19.1-mvebu-tld-1?

https://forum.doozan.com/read.php?2,32146

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Do I need usb/serial to apply the alternative kernel? That's why I was leaning towards trying to build the .so file using default latest fw kernel.

Oh yeah, my use case is I'm using iscsi in proxmox using zfs and boy let me tell you, I am getting amazing performance. Although I thought I could do a little better by setting up nas side caching that was larger than my node size caching. Then i'd have a constant buffer on my nas side to make most use of the throughput making up cache hits on a slower disk medium (slower medium's = larger caches).



Edited 1 time(s). Last edit at 11/13/2018 11:23PM by thistleknot.

thistleknot,

> Do I need usb/serial to apply the alternative
> kernel? That's why I was leaning towards trying
> to build the .so file using default latest fw
> kernel.

Ah. So you are booting with stock FW.

In that case I can't help you. The module that will be in the kernel 4.19+ most likely will not run in stock FW.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

okay. I will look on finding my usb to serial :)

thistleknot,

If you plan to install new kernel, it is best that you have USB to serial converter (to go slow and test your installation before commit the change to u-boot envs).

But it is not absolutely necessary. You can also install from stock OS command line.

https://forum.doozan.com/read.php?2,32146

Quote

Zyxel NAS326 Installation

Updated 25 Mar 2017 (added Section C - Installation for SATA rootfs, no serial console)
Updated 18 Feb 2017 (added Section B - Installation for USB rootfs, no serial console)
Updated 05 Feb 2017 (Section A - Installation for USB rootfs, with serial console)


Installation for NAS326 box can be done with serial console connected (section A), or inside stock OS and without serial console (section B for USB rootfs, section C for SATA rootfs). Note: for section A and B, the USB rootfs must be inserted to the front USB port (USB 2.0).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

If I could get either the newer lvm2 with cache support, or zfs, or dm-cache working with that kernel. I'd go for it. Now that I know it's possible. I'm half tempted to just say f it and go for it. If it breaks, I can always serial it afterwards.

omg. I see I can rollback!

"To reverse the setup, and boot back to stock NAND kernel permanently, execute the following instructions at the Debian command line: "



Edited 1 time(s). Last edit at 11/17/2018 06:10AM by thistleknot.

Hi Bodhi,

I am owner of 325v1 and 326 boxes.
No issues with 325v1 - WOL works well.
Nowadays I am not sure about nowadays state of WOL of NAS326 box.
326:
- I have succesfully configured USB boot using method B. BTW: Big thanks for Your effort to tune these devices and for documentation and forum replies You made.
- I have connected to serial terminal to check boot process
- using USB rootfs and Your kernel version 4.20 - I think (I am writing now from office without access to NAS326 box)
- succesfully configured esekeyd daemon to enable buttons on box header (configuration example/s posted in this forum are not fully correct) + update of /etc/init.d/esekeyd initscript is needed to make buttons working

How to configure esekeyd on NAS326

1. install esekeyd

   apt-get -y install esekeyd

2. enable esekeyd autostart in /etc/default/esekeyd
   

   # Defaults for esekeyd initscript

   # Start esekeyd on boot (set it to "true" to enable)

   START_ESEKEYD=true

   # Daemon options, at last config location must be present

   DAEMON_OPTS=/etc/esekeyd.conf

3. configure esekeyd in /etc/esekeyd.conf
   

   # ESE Key Deamon 1.2.7 config file

   #

   #POWER BUTTON

   KEY_116(release):/sbin/shutdown -h now

   #COPY BUTTON

   KEY_133(release):/usr/bin/logger -s -i "test message"

4. tune initscript - update line DAEMON_OPTS=" " in file /etc/init.d/esekeyd to
   

   DAEMON_OPTS=" /dev/input/event0"

comments:

• my environment: NAS326, kernel 4.20.6-mvebu-tld-1 on USB (method B), lvm2, 2 disks
• button nicknames (like KEY_133) were recognized with utility

    /usr/bin/keytest

  , dont affraid to execute it, it will help You

Biggest issue was to find out well working config because default config was not working to me.
Combination of

man esekeyd + googling + keytest

helped...


- biggest problem of the NAS326 - is not working WOL (working well for my NSA325v1)

- Bodhi, are You please able to summarize Your statements relating to WOL on 326? Maybe I made some error/missed something to configure. Issues with WOL are not discussed lately, it can mean that it works for others...

Update:

1. I am going to use stock firmware to test WOL functionality in original firmware

Thanks

Jave



Edited 4 time(s). Last edit at 03/25/2019 12:35PM by jave.

jave,

> KEY_133:shutdown -h now 
> KEY_116:<what You need or wish>

Thanks for the info about the key. It seems esekeyd has some problem and need to be updated to properly recognize standard Linux keys.

> - biggest problem of the NAS326 - is not
> working WOL (working well for my NSA325v1)
> - Bodhi, are You please able to summarize Your
> statements relating to WOL on 326? Maybe I made
> some error/missed something to configure. Issues
> with WOL are not discussed lately, it can mean
> that it works for others...

WOL does not work on NAS326 at this moment. It was still a work in progress and I did not have time to continue the investigation. In theory, it should work. But I think there is some settings that we have not figured out. When we shutdown the NAS326 with poweroff GPIO, the ethernet port was also powered down, but it should not.

If you look at the NSA325 ethernet port during shutdown, it basically goes into a low power saving state and the LED is amber color. That's the proper behavior.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi there everyone, seems like this thread has been going a long while! I've been trying to work out the NAS326 for a few months now (you can see my progress and where I got stuck here https://github.com/alexhorner/ZyXEL-NAS326)

The main issue I encountered was that things stored on the flash filesystem would get erased each boot, so I couldn't really install anything easily, and I wasn't really sure where to start with services running in the background. I'm so used to the tools-o-plenty of Ubuntu so...

I'd really like to get Ubuntu or Debian running on this box with PHP, Apache, latest OwnCloud etc but I am not sure where to start. I don't have enough knowledge of lower level linux or UBoot.

I have a USB Serial adapter and was successful in getting a busybox shell like is available over SSH, and after a couple of attempts (hindered by the boot refusal whilst serial connected issue) I was successful in getting into UBoot.

I'd also like to learn how I can use the firmware available on ZyXEL's support page (5.21) can be restored if things go real bad

Anyone able to help a noob with this lower level stuff? I don't have enough knowledge to properly understand all the posts on this topic and I can't pull it together into a set of instructions myself as I don't even know where to start

Many thanks!