Thank you for your quick answer !
The mtd is not stock, I've installed the last uboot made by bodhi
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).
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.
Note that you have to follow guidelines in https://openwrt.org/submitting-patches 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 https://openwrt.org/docs/guide-developer/build-system/use-patches-with-buildsystem 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.
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) https://github.com/torvalds/linux/blob/910470e03f343c48500a5619bb14bb8df51c3a72/drivers/hwmon/Kconfig#L1259
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.
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.
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!