Support for Zyxel NSA320

Hello bobafetthotmail, I own a Zyxel NSA320.
Do you think it's possible to port openwrt on this device ?

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 000c0000 00020000 "uboot"
mtd1: 00080000 00020000 "uboot_env"
mtd2: 07ec0000 00020000 "ubi"

cat /proc/cpuinfo
processor       : 0
model name      : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1196.85
Features        : swp half fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Marvell Kirkwood (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000

cat /proc/partitions
major minor  #blocks  name

  31        0        768 mtdblock0
  31        1        512 mtdblock1
  31        2     129792 mtdblock2

Yeah, it's basically a NSA310 with more RAM, and an additional driver for the fan/temperature, this is its entry in kernel config.

ZyXEL NSA320 and compatible fan speed and temperature sensors (SENSORS_NSA320) [N/m/?] (NEW)

This is interesting:

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 000c0000 00020000 "uboot"
mtd1: 00080000 00020000 "uboot_env"
mtd2: 07ec0000 00020000 "ubi"

Is this obtained by stock firmware? Can the stock uboot read from ubi partitions now? It would be pretty cool.

This is what it looked like (and what all NSA3xx line of devices firmware partitions) look like

I can't port OpenWrt myself for a while as I have real-life things using up a lot of time. I can help you or give some directions if you want to do it yourself though.

Thank you for your quick answer !
The mtd is not stock, I've installed the last uboot made by bodhi :wink:

A few month ago, I booted from usb with the NSA325 or NSA310 initramfs, it was working.
Real life is keeping me busy too at the moment but I would appreciate your help and those directions you're talking about.
I could use them during my holidays in a couple weeks.

I'm going to assume that you know the basics of development already (like how patch files and git and linux commandline work) for brevity, if you don't understand something ask and I'll talk more about that (within what I know).

First thing is you need a Linux system to compile stuff. Can be in a VM (Virtualbox or VMware) too.
Then read this (and the other three articles linked at the bottom) to setup and how to use the build system. and this to have a general idea of what is what

It's not particularly hard, but you will need a decent CPU as it will compile a lot of stuff the first time (it compiles the whole toolchain from source), and a flat internet commection (it will download GBs of stuff the first time).

Then find the thread about kwboot in bodhi's forum and prepare it too, as it allows you to recover your device in case you erase uboot, or to test new uboots without the need to actually write them to flash storage. This of course needs serial access to the device, so if you don't have that please look up the serial/TTL pinout of the nsa320 and buy a USB-TTL dongle for a few bucks, DO NOT connect the 3.3v or 5v pin as the dongle is powered from USB, you risk frying things.

Use as a blueprint my commit to add support for nsa310
most thing should be self-explanatory enough, especially because the NSA320 is basically the same thing as a nsa310 with more ram.

Note that you have to follow guidelines in guidelines or they will complain and not merge your contribution.
That page also contains basic info about setting up git as required, and how to fix mistakes or do common things they may ask.
Your PR will remain open for months, so be patient. They will merge it only in the OpenWrt master (the "snapshot" builds are based on this), and will end in the next stable release, but NOT in 18.06.

As you saw, you will need to have instructions for installation that work from stock too, you can't require people to install bodhi's custom uboot, OpenWrt people won't accept it.
(the install instructions for uboot in my commit are missing a nand erase 0x00000 0x100000 before the nand write and this is very important)

The first things you see in my commit are a bunch of scripts for setting up and controlling leds, and for setting up network, this should be self-explanatory if you search the same names in the page to see from what other file they come from.

You don't need the "nsa310_fancontrol", you might need a dedicated fancontrol script for the nsa320 though, I don't know.

In the file target/linux/kirkwood/image/Makefile you probably don't need the kmod-r8169 kmod-hwmon-lm85 packages as afaik the NSA320 uses the Marvell ethernet controller (drivers for that are integrated in the kernel for all kirkwood devices already), and afaik the NSA320 does not have a LM85 sensor/fancontroller but has one that requires its own driver (will talk more about this new driver below).

From here on, when I talk of patches you may find them in patches-4.9 or patches-4.14 folders instead of patches-4.4 as the kernel was updated, they are mostly the same.

The patch target/linux/kirkwood/patches-4.4/190-zyxel-nsa3xx-common-nand-partitions.patch defines the mtd partitions for all nsa3xx devices, nsa320 included.
That patch edits a file called kirkwood-nsa3x0-common.dtsi you will have to state that you are relying on this file in your dts file with a #include "kirkwood-nsa3x0-common.dtsi" (as you can see in the patch below it)

the patch target/linux/kirkwood/patches-4.4/191-nsa310b.patch contains the dts file, that describes the hardware available onboard the nsa310. It also patches another file containing the list of available dts files.
I looked at the dts file for the nsa310 from bodhi's kernel patch for his debian kernel, and cleaned them up.

Bodhi's patch I used does not seem to use other files in the kernel so he is duplicating a ton of text in the dts. The dts files you find in my commit for nsa310 are short because they are "including" other files from the kernel source that contain most of the boilerplate hardware definition, like this
(from upstream kernel source)

that is again "including" other two files

So, you will need to actually clean up his dts by removing all the boilerplate that is already defined in the files above), and use the #include "kirkwood-nsa3x0-common.dtsi" to state that you rely on this stuff already in the kernel as I said above.

I deleted any linux,default-trigger = xxxxxx in the led section of the dts, as that would set led triggers by default. It's just a default but OpenWrt controls leds with the script files you see at the beginning of my commit.

To make patches editing multiple files and also coherent with the other patches in the kirkwood folder, you should have read as the build system helps you do that, you will need to install "quilt" in your linux distro as that's the tool that does the leg work.
For the dts file, you are "adding a kernel patch" as dts files are shipped with the kernel sources so follow that part of the tutorial.

As mentioned above, you will need to add the nsa320-specific driver for fan/temperature, and since it's used only by your device it's better to have it as a module.

See this commit about adding a new hardware monitor module

Instead of CONFIG_SENSORS_ADCXX you should write SENSORS_NSA320 and in the FILES:=$(LINUX_DIR)/drivers/hwmon/adcxx.ko you should find out how that file is called and write its name there, as that line tells the packaging system what is the file to load in the package.
Then change all names and description of course.
This is the description of the nsa320 driver in the Linux kernel (this is upstream source, not from OpenWrt)
It says that the module should be called nsa320-hwmon, so you should probably write
FILES:=$(LINUX_DIR)/drivers/hwmon/nsa320-hwmon.ko above.
I can't tell you with 100% certainty, you need to try. You can also check where that file is in your Debian system.
Also the description claims this might work on nsa310 or nsa325, this is not the case. Nsa310 has different control system over i2c that I operate with that fancontrol script, NSA325 has no control at all.

Then you will need to add this module in the list of modules added by default in your device, in the file target/linux/kirkwood/image/Makefile in your device definition add the name of this new kmod module in the DEVICE_PACKAGES := list.

As you see, actually porting OpenWrt on a NSA320 is more tedious than complex.

The main issue here is that if you want to boot OpenWrt with a uboot that can also boot debian/arch/whatever you have to contribute a OpenWrt u-boot too.

Having a custom uboot actually allows to skip a bunch of kernel hacks for hardware issues, as the uboot will deal with it on its own before starting OpenWrt (or Debian), which is another reason why bodhi made his custom uboot, and why I prefer to use that instead of adding patches with kernel hacks.

This is the commit about adding a new uboot for nsa310

In this case the overwhelming majority of the code comes directly from bodhi's uboot sources

I just changed the following part (which is the default boot commands and mtd partition settings)

+ * Default environment variables
+ */
+	"ubi part ubi; " \
+	"ubi read 0x800000 kernel; " \
+	"bootm 0x800000"
+	"mtdparts=orion_nand:" \
+	"0x0c0000(uboot)," \
+	"0x80000(uboot_env)," \
+	"0x7ec0000(ubi)\0"
+	"console=console=ttyS0,115200\0"	\
+	"mtdids=nand0=orion_nand\0"		\
+	"mtdparts="CONFIG_MTDPARTS		\
+	"bootargs_root=\0"

Since all NSA3xx devices use the same flash size and partitions, you can copy this in your uboot without modification.

I encourage you to add the same "recovery" feature I added in the uboot for pogoplug v4
which is basically just use this bootcommand instead of the one above.

+	"usb reset ; " \
+	"fatload usb 0:1 0x2000000 initramfs.bin ; "\
+	"bootm 0x2000000 ; " \
+	"ubi part ubi; " \
+	"ubi read 0x800000 kernel; " \
+	"bootm 0x800000"

The main annoyance about the uboot contribution is that the kirkwood uboot in OpenWrt has been updated to the latest version, so you will need to adapt a bit the files from bodhi's uboot or they won't even build.

You should look at the changes done to the uboot I committed that p.wassi made in the following two commits (for the two updates)
in this commit
and this commit

Thank you very much for all theses helpful informations !
I'll look into it and try my best :slight_smile:

Hi, I'm looking for an upgrade to my stock firmware on NSA320.
Did you have any luck with porting?

Hi. Can you compile image with this patch and test it on your device?

diff --git a/package/boot/uboot-envtools/files/kirkwood b/package/boot/uboot-envtools/files/kirkwood
index b5f7ddccb7..0b61f39126 100644
--- a/package/boot/uboot-envtools/files/kirkwood
+++ b/package/boot/uboot-envtools/files/kirkwood
@@ -20,6 +20,7 @@ linksys,viper|\
	ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x20000" "0x20000"
diff --git a/package/kernel/linux/modules/ b/package/kernel/linux/modules/
index bf2860881e..f78dc4b7f7 100644
--- a/package/kernel/linux/modules/
+++ b/package/kernel/linux/modules/
@@ -257,6 +257,21 @@ endef
$(eval $(call KernelPackage,hwmon-ltc4151))

+define KernelPackage/hwmon-nsa320
+  TITLE:=NSA320 monitoring support
+  FILES:=$(LINUX_DIR)/drivers/hwmon/nsa320-hwmmon.ko
+  AUTOLOAD:=$(call AutoProbe,nsa320-hwmon)
+  $(call AddDepends/hwmon,)
+define KernelPackage/hwmon-nsa320/description
+ Kernel module for temperature and fan cintrol MCU installed in NSA320
+$(eval $(call KernelPackage,hwmon-ltc4151))
define KernelPackage/hwmon-nct6775
  TITLE:=NCT6106D/6775F/6776F/6779D/6791D/6792D/6793D and compatibles monitoring support
diff --git a/target/linux/kirkwood/base-files/etc/board.d/01_leds b/target/linux/kirkwood/base-files/etc/board.d/01_leds
index 5cfc4cf309..1af00df765 100755
--- a/target/linux/kirkwood/base-files/etc/board.d/01_leds
+++ b/target/linux/kirkwood/base-files/etc/board.d/01_leds
@@ -43,6 +43,12 @@ case "$board" in
	ucidef_set_led_ataport "hdd" "HDD" "nsa310:green:hdd" "1"
	ucidef_set_led_ataport "esata" "eSata" "nsa310:green:esata" "2"
+	ucidef_set_led_default "health" "health" "nsa320:green:sys" "1"
+	ucidef_set_led_usbhost "usb" "USB" "nsa320:green:usb"
+	ucidef_set_led_ataport "hdd" "HDD" "nsa320:green:hdd" "1"
+	ucidef_set_led_ataport "esata" "eSata" "nsa320:green:esata" "2"
+	;;
	ucidef_set_led_default "health" "health" "nsa325:green:sys" "1"
	ucidef_set_led_usbhost "usb" "USB" "nsa325:green:usb"
diff --git a/target/linux/kirkwood/base-files/etc/board.d/02_network b/target/linux/kirkwood/base-files/etc/board.d/02_network
index 15e51d88f2..890879b4c3 100755
--- a/target/linux/kirkwood/base-files/etc/board.d/02_network
+++ b/target/linux/kirkwood/base-files/etc/board.d/02_network
@@ -30,6 +30,7 @@ case "$board" in
		"0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "5@eth0" "6@eth1"
	ucidef_set_interface_lan "eth0" "dhcp"
	ucidef_set_interface_macaddr "lan" $( mtd_get_mac_ascii uboot_env ethaddr )
diff --git a/target/linux/kirkwood/image/Makefile b/target/linux/kirkwood/image/Makefile
index 0672ba0374..270621b62f 100644
--- a/target/linux/kirkwood/image/Makefile
+++ b/target/linux/kirkwood/image/Makefile
@@ -144,6 +144,14 @@ define Device/zyxel_nsa310b
TARGET_DEVICES += zyxel_nsa310b

+define Device/zyxel_nsa320
+  DEVICE_DTS := kirkwood-nsa320
+  DEVICE_PACKAGES := kmod-gpio-button-hotplug kmod-hwmon-nsa320
+  BOARD_NAME := nsa320
+TARGET_DEVICES += zyxel_nsa320
define Device/zyxel_nsa325
  DEVICE_TITLE := ZyXEL NSA325 (v1 and v2)
  DEVICE_DTS := kirkwood-nsa325

Probably you need to install this u-boot.
Check if image boot corectly, leds, fan and temperature sensor.

I never took the time to look into it :fearful:

So, I've finally got my zyxel out again (I've got time during the lockdown when kids are asleep).
Good news, openwrt 19.07.2 is installed on the nand of my NSA320 and it is working great !

So, basically, I've just followed this amazing tutorial:,86219
I tried different uImage and the only one with the working network is the nsa235 one (I never tried to compile a new image following olek210 instructions)
Don't forget to upgrade the uboot first, using this:,12381

Now, I need to figure out what packages are required in openwrt to have a functionnal NAS.

@kblayout Any news? Could you post what is working / not working?

Hi @kblayout , thanks for thinking that my tutorial over at the doozan forum is amazing... Indeed, I never tried it on the Zyxels, but now I can actually use them again (I bought some for work way back when), So I wanted to try my luck on an NSA320 with OpenWrt only to find that they are not officially supported. So, all the better to hear you had success following my tutorial - so I will try the same (and probably amend the tutorial afterwards, because I think the mtdparts definition should probably be left alone, much like bodhi does in his uBoot tutorial ). So, after I helped you, you are now helping me and the circle is closing!