Debian on NSA325 V1/V2

Delighted I was able to help :)

I am very intrested in which pendrives are working and which one's not ...
...and what are the real reasons of that ...
... how to check pendrive "if will be applicable..." (before buying it)...

This is mysterious for my why some of them not works, and other work "sometimes"....

Marcin

Here is the working USB stick thread. Pretty long list of what usually work and what to avoid.
http://forum.doozan.com/read.php?2,1915

IMO, it's partly in the U-Boot version that you're running. Usually it handles typical USB thumb drives very well. But some thumb drives are of low quality (e.g. Patriot), and it will fail to boot.

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



Edited 1 time(s). Last edit at 03/27/2014 05:22PM by bodhi.

Had a bit time to play with my nsa325v2 again and realised, eth0 doesn't get initialized?
I tried kernels 3.12.0-tld-5 and 3.13.1-tld-2.
The only line in whole boot process that contains 'eth0' is apparently

root@Sheeva:~# dmesg | grep 'eth0'
[    3.915009] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:00:02:02

Also the nsa3xx hwmon driver complains about not being able to read MCU data in 3.13.1-2 dmesg.
Besides this, network *does* work in uboot and stock firmware.

Did I miss something here or why isn't this working?

Take a look at Buttzy's dmesg, perhaps you can spot where the problem. Looks like hwmon failed, and that was the last line in dmesg?
http://forum.doozan.com/read.php?2,14351,15284#msg-15284

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

Hi bodhi

Hm... Can't see much difference except Buttzy uses 3.13.2-nsa-325 kernel whereas I use 3.13.1-kirkwood-tld-2.
The only other real difference with ethernet I can see is that Buttzy is using gbit ethernet and his log has lines like

[   39.568368] NET: Registered protocol family 10
[   39.787229] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
[   39.793289] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   42.399547] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
[   42.409463] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   58.934049] tun: Universal TUN/TAP device driver, 1.6
[   58.939609] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>

where I use 100MBit instead and in my log it just says

[   18.377890] loop: module loaded
[   21.576454] NET: Registered protocol family 10

Nothing more from mv643xx_eth or eth0 apart from the single line I quoted above.

Also I don't got gbit hardware to see if this would work...

And yes, the 3 lines from nsa3xx-hwmon are the last lines in dmesg.

Hi NobuoT,

If you look back a few post, Buttzy started out with 3.13.1-kirkwood-tld-2. And later compiled his own kernel 3.13.2-nsa-325.

And perhaps you 100MBit Ethernet has something to do with the problem. I recalled some people has problem running 100Mbit network with some Kirkwood boxes (don't remember which one).

Are you connecting with serial console? it would be helpful to post the entire boot log.

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



Edited 1 time(s). Last edit at 04/03/2014 01:41AM by bodhi.

Found out a few things...

I attached 2 console logs.
1 is the "normal" boot log where eth0 doesn't show up
2 is a log where I accidentally kept the default bootargs with root=/dev/nfs

Setting root=/dev/nfs of course stopped debian from booting, but when it dropped me to busybox, eth0 magically appeared. So I guess the problem is somewhere in my initramfs / init scripts.
In case 2 /scripts/nfs is called which runs a function "configure_networking" in which ipconfig is invoked (guess that is where the ip-config lines in the 2nd log come from).
I didn't find anything like this in /scripts/local, which is run in case 1...
Also /sys/class/net/ now has lo and eth1, not eth0 in this case, but it's apparently still this mv643xx_eth_port.0 device. Still it doesn't show in ifconfig, of course.

I also didn't use your rootfs but took an image of a debian installation that ran on my plug computer and installed your kernel in this image (by chroot from stock firmware on nsa325v2), but didn't modify the init scripts or anything. Could anything go wrong there?
Hm, guess I'll have to look into this a bit more when I find the time...

NobuoT,

> I also didn't use your rootfs but took an image of
> a debian installation that ran on my plug computer
> and installed your kernel in this image (by chroot
> from stock firmware on nsa325v2), but didn't
> modify the init scripts or anything. Could
> anything go wrong there?

See if the persistent net rules is the problem (one of typical problems when reusing a rootfs from a different boxes):
http://forum.doozan.com/read.php?2,13053,13070#msg-13070

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

Wow, thanks bodhi!

That did it. Would have taken me ages to figure that out otherwise. x)

*Sigh*... Next problem:
Everything looked good so I removed the rs232, put the NAS back together and saved bootcmd to nand in uboot to automatically boot from sata disk. And... it didn't boot up. -__-
After uboot jumps into the kernel, it resets about 20sec into the boot process on different steps without any warning or hint to any problem on console or in any of the logs. Seems like this f**** stupid watchdog isn't reliably stopped.
When I interrupt the boot process in uboot and manually type in "boot" via console, the system boots up ok.
Increasing the boot delay from 2 to 10s didn't help.
Kernel 3.12.0-5 on the other hand boots up without problems from bootcmd whithout having to interfere in uboot.

My bootcmd looks like this:
bootcmd=ide reset; ext2load ide 0:1 $(loadaddr) /uImage-3.13.1-2; ext2load ide 0:1 0x01100000 /uInitrd-3.13.1-2; bootm $(loadaddr) 0x01100000
bootargs=console=ttyS0,115200 root=LABEL=rootfs


Another thing:
I tried to set up a script in rc.local that sets hdd 1 and 2 led triggers to default-on when a hdd is installed in the corresponding slot. But it looks like /dev/disk/by-path/ isn't correctly populated as it has just disk 0 (platform-sata_mv.0-scsi-0:0:0:0). /dev/sdb is there and the disk can be accessed, though. Any idea, how else I can check if a disk is installed in slot 0 or 1?

NobuoT,

> Kernel 3.12.0-5 on the other hand boots up without
> problems from bootcmd whithout having to interfere
> in uboot.

What is the difference between your rootf and this?

>
> My bootcmd looks like this:
> bootcmd=ide reset; ext2load ide 0:1 $(loadaddr)
> /uImage-3.13.1-2; ext2load ide 0:1 0x01100000
> /uInitrd-3.13.1-2; bootm $(loadaddr) 0x01100000
> bootargs=console=ttyS0,115200 root=LABEL=rootfs

Generally looks good to me, except that why there is no rootdelay in bootargs?

>
> Another thing:
> I tried to set up a script in rc.local that sets
> hdd 1 and 2 led triggers to default-on when a hdd
> is installed in the corresponding slot. But it
> looks like /dev/disk/by-path/ isn't correctly
> populated as it has just disk 0
> (platform-sata_mv.0-scsi-0:0:0:0). /dev/sdb is
> there and the disk can be accessed, though. Any
> idea, how else I can check if a disk is installed
> in slot 0 or 1?

If you're using my kernel build or rootfs, the ide triggers for the 2 disks looks like this:

[none] nand-disk timer oneshot ide-disk1 ide-disk2 heartbeat gpio default-on

So do this:

echo ide-disk1 > /sys/class/leds/status\:xxxxxx/trigger

and then to see if disk is in slot 0: ls some directory to trigger the LED.

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

Hi,
has someone tried booting directly from a Sata-drive?

I have a v1 nsa325 and was able to boot from the left sata drive but ended up booting via USB flash drive since I wanted the left and right drive setup as raid1. Just had to tweak uboot.

~sol

Hello,

firstly, my apologies if I'm asking trivial questions or something that's already been answered here since I'm not too experienced with embedded or build-it-yourself linux stuff and this thread is quite fragmented with all that technical stuff. However, I'm eager to learn so I'll gladly accept any advice :)

I got myself an NSA325v2 and (as expected) found its default software to be utter BS. By googling I also found out I basically have two options for custom Linux: Debian and Arch. Nearly all my Linux-experience is from Debian/Ubuntu-derivatives, so Debian would be the logical choice. Any arguments for and against?

I just received a USB to 3.3V TTL-level serial adapter and got the serial console working. Now I'm wondering what to do next: The internal NAND chip is way too small to flashed with any reasonable version of Debian, isn't it? I dislike the idea of a USB drive sticking out from the back of the NAS 24/7 - is it the only option? Is it possible to boot and run the OS from a SATA-disk and still have RAID1?

I'd like to hear about your experiences with the custom Linux setup and how feasible it is. Is the hardware well supported and configurable? I like to tinker with this kind of stuff and have a customizable system but I also expect to gain something on the efficiency, reliability, security and accessibility side of things. So, does power management work as expected and is it configurable on at least the same level as in default firmware? What about Wake on LAN?

Considering myself far from an expert with the things involved it's likely that something goes wrong at some point. Is possible to (easily) by accident brick the device beyond any help? How troublesome would it be to revert everything back to ZyXel defaults? I assume that "run to_stock" mentioned by marcint43 works in the serial console, right? Is that all or is there something else?

And btw, has anyone tried to suppress the stock fan or change it altogether? I find that pulsing hum quite annoying. An 80mm Noctua fan might be overkill but would be worth it if it helps. I guess the real question is, which is the main cause of the noise: bad stock fan, bad fan mounting or poor driver electronics? Also, the Marvell datasheet shows that the CPU should be capable of running @ 2 GHz max. Has anyone tried/succeeded in overclocking? I even have some small heatsinks to spare so I guess heat dissipation wouldn't be a problem but is the power supply robust enough?

Phew, what a long post. As said, any help or comments are appreciated. Also, please point out if there's a better place to ask these questions :)

Hi SPuntte,

I'll address some of your questions and leave the rest to others!

Quote

So Debian would be the logical choice. Any arguments for and against?

Really there is no for/against Debian or Arch. Which ever your preference is fine.

Quote

I dislike the idea of a USB drive sticking out from the back of the NAS 24/7

You can use the Sandisk Cruzer Fit. It has very minimum footprint (a few mm) and very reliable. All my plugs boot with this type of USB thumb, except for a few that use HDD or NFS rootfs for booting.

Quote

Is the hardware well supported and configurable?

Very well on both counts.

Quote

So, does power management work as expected and is it configurable on at least the same level as in default firmware? What about Wake on LAN?

Yes and yes.

Quote

I assume that "run to_stock" mentioned by marcint43 works in the serial console, right?

This could be set in Linux, too, assuming you follow the same settings for U-Boot environment variables that others currently use.

And you can use this Debian rootfs:
Debian-3.13.1-kirkwood-tld-2-rootfs-bodhi.tar.bz2 (07 Feb 2014)

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



Edited 1 time(s). Last edit at 04/08/2014 10:56PM by bodhi.

Iv been using a 32GB cruzer fit for a few months now with no problems. I take the drive out every so often to make a image of the drive just in case it fails. Works really well.

Quote

run to_stock

This can be simply executed, as is, from serial, yes. From Linux, you must us fw_setenv.

Quote

*fan*

It's the separate MCU that controls the fan, and its programming. A higher quality fan in the same power envelope should be feasible if you so choose.

Quote

overclock ... 2Ghz

Do not attempt. I have had several engineering samples that have cooked themselves after sustained high load at these levels. Literally cooked to the point of they are unstable after idling for a few minutes after boot.

Quote

supported

Yup. I did a fair amount of work to ensure everything was supported on the board, to the best of my ability. I do however, hate the bootup watchdog.

bodhi,

> > Kernel 3.12.0-5 on the other hand boots up
> > without
> > problems from bootcmd whithout having to
> > interfere
> > in uboot.
> What is the difference between your rootf and
> this?
I copied the rootfs from my SheevaPlug. It is a debian squeeze updated to wheezy with loads packets installed...

> >
> > My bootcmd looks like this:
> > bootcmd=ide reset; ext2load ide 0:1 $(loadaddr)
> > /uImage-3.13.1-2; ext2load ide 0:1 0x01100000
> > /uInitrd-3.13.1-2; bootm $(loadaddr) 0x01100000
> > bootargs=console=ttyS0,115200 root=LABEL=rootfs
>
> Generally looks good to me, except that why there
> is no rootdelay in bootargs?
Didn't think about this yet. Will try if it changes anything.

> > Another thing:
> > I tried to set up a script in rc.local that
> sets
> > hdd 1 and 2 led triggers to default-on when a
> hdd
> > is installed in the corresponding slot. But it
> > looks like /dev/disk/by-path/ isn't correctly
> > populated as it has just disk 0
> > (platform-sata_mv.0-scsi-0:0:0:0). /dev/sdb is
> > there and the disk can be accessed, though. Any
> > idea, how else I can check if a disk is
> installed
> > in slot 0 or 1?
>
> If you're using my kernel build or rootfs, the ide
> triggers for the 2 disks looks like this:
>

> [none] nand-disk timer oneshot ide-disk1 ide-disk2
> heartbeat gpio default-on
>

> So do this:
>

> echo ide-disk1 >
> /sys/class/leds/status\:xxxxxx/trigger
>

> and then to see if disk is in slot 0: ls some
> directory to trigger the LED.

Sorry, should have explained better. My current rc.local looks like this:

if [ -d /sys/class/leds/nsa325\:green\:sys ]; then
   echo default-on  > /sys/class/leds/nsa325\:green\:sys/trigger
   echo none        > /sys/class/leds/nsa325\:orange\:sys/trigger
   echo ide-disk1   > /sys/class/leds/nsa325\:red\:hdd1/trigger
   echo ide-disk2   > /sys/class/leds/nsa325\:red\:hdd2/trigger
# This works as intended:
   if [ -e /dev/disk/by-path/platform-sata_mv.0-scsi-0\:0\:0\:0 ]; then
   	echo default-on > /sys/class/leds/nsa325\:green\:hdd1/trigger
   fi
# This doesn't: path does not exist, although 2 sata disks installed
   if [ -e /dev/disk/by-path/platform-sata_mv.1-scsi-0\:0\:0\:0 ]; then
   	echo default-on > /sys/class/leds/nsa325\:green\:hdd2/trigger
   fi
fi

My problem isn't to trigger the leds on disk access, but to default-on the green hdd led for slot 0 or 1 if a disk is *present* in the associated slot as the stock firmware does AFAIK.

NobuoT,

This does not hurt to do regardless whether the HDD 1 or 2 is mounted or not

if [ -d /sys/class/leds/nsa325\:green\:sys ]; then
   echo default-on > /sys/class/leds/nsa325\:green\:hdd1/trigger
   echo default-on > /sys/class/leds/nsa325\:green\:hdd2/trigger
fi

And, the device-by-path is a known problem in Marvell SATA driver sata_mv (also could be the way we use it, I have not tried to fix it so don't know). You could use /dev/disk/by-uuid or /dev/disk/by-label instead.

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

@bodhi, SomeoneOnLine, WarheadsSE: a huge thank you for your comments! And to Buttzy for the instructions.

As you suggested, I ordered a pair of Cruzer Fits (another for a 1:1 backup, just in case) and got bodhi's Debian running in no time :)

Currently I have a mdadm RAID1 setup up and running so the next thing to dive into would be Samba configuration. You probably knew this already (I certainly didn't until now!), but if you ever wonder why freshly-formatted partitions are being constantly accessed (like once every second) with no obvious reason the cause might be ext4 lazy initialization.

So far I've encountered nothing fatal although there are a few minor issues:

1. My LED trigger script in /etc/rc.local isn't working at all. What am I doing wrong?

#!/bin/sh -e

# Indicator LEDs
if [ -d /sys/class/leds/nsa325\:orange\:sys ]; then
   echo none > /sys/class/leds/nsa325\:orange\:sys/trigger
if [ -d /sys/class/leds/nsa325\:green\:sys ]; then
   echo default-on  > /sys/class/leds/nsa325\:green\:sys/trigger
fi
if [ -d /sys/class/leds/nsa325\:green\:hdd1 ]; then
   echo ide-disk1  > /sys/class/leds/nsa325\:green\:hdd1/trigger
fi
if [ -d /sys/class/leds/nsa325\:green\:hdd2 ]; then
   echo ide-disk2  > /sys/class/leds/nsa325\:green\:hdd2/trigger
fi

exit 0

2. Related to the one above, issuing commands like

$ sudo echo none > /sys/class/leds/nsa325\:orange\:sys/trigger

signals "Permission denied" - why? The only way to execute such commands and get the LEDs working is to su root manually after every reboot. Is there something wrong with my sudo/sudoers configuration?

3. Again, related to LEDs, the trigger "ide-disk2" doesn't seem to work at all. "ide-disk1" works all fine and dandy, both on hdd1 and hdd2 LEDs. Could this have something to do with the fact that for some reason (why?) my SATA-disks are recognized as /dev/sda and /dev/sdc while the USB stick being /dev/sdb?



Edited 1 time(s). Last edit at 05/01/2014 09:03AM by SPuntte.

Hello! My NSA310S on this kernel doesn't power off completly, only HDD turned off but rest of device is still on. How fix it ?

I am pretty I told you exactly why on the ALARM forum there @karolp1993

SPuntte,

Must do this as root user:

echo none > /sys/class/leds/nsa325\:orange\:sys/trigger

So try to execute these at command line and see if it works. Please let me know if you still see ide-disk2 problem.

echo ide-disk1  > /sys/class/leds/nsa325\:green\:hdd1/trigger
echo ide-disk2  > /sys/class/leds/nsa325\:green\:hdd2/trigger

And it does not have anything to do with the disk dev assignment. These trigger are only relevant to the internal SATA port assignments.

Could this have something to do with the fact that for some reason (why?) my SATA-disks are recognized as /dev/sda and /dev/sdc while the USB stick being /dev/sdb?

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



Edited 1 time(s). Last edit at 05/01/2014 04:34PM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> Must do this as root user:
> [shell commands]

I'm curious to know why.


> So try to execute these at command line and see if
> it works. Please let me know if you still see
> ide-disk2 problem.
> [shell commands]

Well this is embarrassing... I clearly failed something epicly myself, because now that "ide-disk2" is working perfectly. More importantly, I also discovered an "fi" missing from the first conditional structure in the rc.local script found in my previous post. So there was nothing wrong but with my perception in the first place. Thanks anyway :)



Edited 1 time(s). Last edit at 05/02/2014 04:02AM by SPuntte.

Hi,

I'm using 3.14.0-kirkwood-tld-2 and rootfs from bodhi http://forum.doozan.com/read.php?2,12096,page=1
Sensors do not seem to be working:

root@debian:~# cat /sys/class/hwmon/hwmon0/device/temp1_input
[  396.131910] nsa3xx-hwmon nsa3xx-hwmon: Failed to read MCU data
0
root@debian:~# cat /sys/class/hwmon/hwmon0/device/fan1_input
[  401.391909] nsa3xx-hwmon nsa3xx-hwmon: Failed to read MCU data
0

Are they supposed to work ?
Thx

--
DavideDG
My NAS userspace configs
My Zyxel NSA325 mod
My D-Link DNS325 mod
My Lacie NS2MAX mod



Edited 1 time(s). Last edit at 05/11/2014 04:00PM by davidedg.

DavideDG,

I've included all LM sensors in the kernel as modules. You might check to see if the specific LM sensors for NSA325 V2 are loaded.

CONFIG_SENSORS_LM63=m
CONFIG_SENSORS_LM70=m
CONFIG_SENSORS_LM73=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
CONFIG_SENSORS_LM93=m
CONFIG_SENSORS_LM95234=m
CONFIG_SENSORS_LM95241=m
CONFIG_SENSORS_LM95245=m
CONFIG_SENSORS_NSA3XX=m

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



Edited 1 time(s). Last edit at 05/12/2014 01:19AM by bodhi.

IIRC either the 320, or the 325 was never actually intended to talk to the OS, and merely does its own thing.

WarheadsSE Wrote:
-------------------------------------------------------
> IIRC either the 320, or the 325 was never actually
> intended to talk to the OS, and merely does its
> own thing.

You mean that I can ignore those errors since the fan will be piloted from the driver and not from userspace?


Also, regarding the FDT kernel for NSA325, I am trying
https://github.com/pkirchhofer/nsa325-kernel

it seems to work correctly (no full test yet).
Do anybody know a good reason against this? Or why shouldn't it be ported to mainline?
I'm available for testings :D

Ty!

--
DavideDG
My NAS userspace configs
My Zyxel NSA325 mod
My D-Link DNS325 mod
My Lacie NS2MAX mod

ALARM is preparing to integrate as much of the kirkwood family as possible into a single linux-armv5 FDT kernel package, with update u-boots for each device. Glad to see someone has started this.

Thanks to your wonderful work, I got my new NSA325v2 working within 2 weeks!

I set up a repo on github to document the whole process, in case someone needs it :D

https://github.com/davidedg/NAS-NSA325-mod

Thank you again all.

--
DavideDG
My NAS userspace configs
My Zyxel NSA325 mod
My D-Link DNS325 mod
My Lacie NS2MAX mod