Debian on NSA310S?

I don't think it's the switch. I have a manageable HP ProCurve switch, JohnnyUSA something completely different. Never had problems with mine and both connect just fine when booting to Zyxel OS.
Can you have a look at the LEDs on your LAN port?
After coldboot I have the GREEN LED blinking and after the first successful connect (in Zyxel OS) it changes to the AMBER LED.
If I do a coldboot into Debian the GREEN LED is still on and no network.
Does yours change to AMBER after network init in Debian?

Here is a snippet from my Debian boot log after coldboot (static IP, link not working)

[    0.140103] cpuidle: using governor ladder
[    0.170103] cpuidle: using governor menu
[    0.170582] Feroceon L2: Enabling L2
[    0.170626] Feroceon L2: Cache support initialised.
[    0.171059] [Firmware Info]: /ocp@f1000000/ethernet-controller@72000/ethernet0-port@0: local-mac-address is not set
[    0.177108] No ATAGs?
[    0.211724] vgaarb: loaded
.
.
[    1.875103] Creating 2 MTD partitions on "orion_nand":
[    1.880219] 0x000000000000-0x000000100000 : "uboot"
[    1.886291] 0x000000100000-0x000000180000 : "uboot_env"
[    1.893724] libphy: Fixed MDIO Bus: probed
[    1.898154] libphy: orion_mdio_bus: probed
[    1.908494] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[    1.994487] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 5c:f4:ab:2f:fe:28
[    2.003474] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.010034] ehci-pci: EHCI PCI platform driver
.
.
[....] Setting kernel variables ...[?25l[?1c7[ ok 8[?25h[?0cdone.
[   15.823932] NET: Registered protocol family 10
[   15.829342] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[....] Configuring network interfaces...[?25l[?1c7[ ok 8[?25h[?0cdone.
[....] Starting rpcbind daemon...[?25l[?1c7[ ok 8[?25h[?0c.
[....] Starting NFS common utilities: statd idmapd[?25l[?1c7[ ok 8[?25h[?0c.
[....] Cleaning up temporary files...[?25l[?1c7[ ok 8[?25h[?0c.

cold boot (U-Boot)
no LED but 1000 baset-FD connection
when booting into ZyxelOS, the amber LED turns on.
after power down, the amber LED is off and the green LED turns on
this doesn't change when booting into U-Boot (no pinging possible --> 10 baseT-HD connection

when booting into debian .. the green LED is still on .. after a while it goes of and the amber LED turns on.
now the lan connection is back on 1000 baseT-FD and fully working.

pengu Wrote:
-------------------------------------------------------
> when booting into debian .. the green LED is still
> on .. after a while it goes of and the amber LED
> turns on.
> now the lan connection is back on 1000 baseT-FD
> and fully working.

Yeah. That's the difference. Somehow your phy is correctly initialized on boot and ours are not...

@JohnnyUSA: can you verify this GREEN / AMBER mess?

Hi,

since I am testing at the moment for a new devicetree description to
let the nsa3xx-hwmon kernel module recognize the nsa320 mcu I have here two
nsa320 boxes, where I can provoke exactly the same situation with phy not powered
which you are experiencing at the moment here with the nsa310s,

the first nsa320 box has vendor uboot,
the other bodhi's newest uboot,
both with debian and bodhi's kernels,..

if I set on the first box with vendor uboot with the script below power_resume.sh 0

- which means it sets power resume behaviour of -

and make a shutdown -P -h now and make a cold boot aftwards,
the phy under debian is not powered, and network is gone, and it remains like that whatever you do,

only with a serial console you get network back by setting power_resume.sh 1, making again
shutdown -P -h now, pull the the powerplug at the back for a couple of seconds, put the plug back in
and the nsa320 must autoboot immediately, than the network is back, the phy is powered

on the box with bodhi's uboot it is different, I never used the power_resume.sh script after I changed
the uboot, this nsa320 box is not set to power_resume, but I have the phy powered and it stays powered
under debian and survives reboots, halt, etc.

so I think as you have the nas310s sources, please have a look in the nsa310-setup.c how the mpp-gpio
mapping ist done, on the nsa320 it is

        MPP47_GPIO,     /* power resume data  */
        MPP48_GPIO,     /* power off          */
        MPP49_GPIO,     /* power resume clock */

than change the gpio ids accordingly and try, if zyxel used the same design principle on the nsa310s,

best wishes pbg4

#!/bin/bash
# power_resume.sh [0/1]
# 0 to disable, 1 to enable.
# enable/disable resume from power loss.

# export both gpios
echo 47 > /sys/class/gpio/export
echo 49 > /sys/class/gpio/export

# 49 out, value 1
echo "out" > /sys/class/gpio/gpio49/direction
echo 1 > /sys/class/gpio/gpio49/value
# 47 out, value 1
echo "out" > /sys/class/gpio/gpio47/direction
echo $1 > /sys/class/gpio/gpio47/value
# set 49 value 0
echo 0 > /sys/class/gpio/gpio49/value

Sorry guys can't test this weekend, i'm away from my NAS.

I think the problem as pbg4 described above is the most likely solution. Hence I suggested above to look at shutdown sequence differences, see if we can keep the PHY alive. The Power resume GPIO is not in the 320S DTS, but perhaps it can be found in the 310S GPL. Let's see if we can find all the GPIO definition in it :)

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

If I am right, it looks like an oversight in Zyxel 310S build:

root@tldDebian:/usr/src/nsa310s-gpl/trunk/linux-2.6.31.8# grep CONFIG_ZYXEL_POWER_RESUME *.config
NSA310_Kernel.config:# CONFIG_ZYXEL_POWER_RESUME is not set
NSA310OBM_Kernel.config:# CONFIG_ZYXEL_POWER_RESUME is not set
NSA320_Kernel.config:CONFIG_ZYXEL_POWER_RESUME=y
NSA325_Kernel.config:CONFIG_ZYXEL_POWER_RESUME=y
SGW_Kernel.config:# CONFIG_ZYXEL_POWER_RESUME is not set
STG222_Kernel.config:# CONFIG_ZYXEL_POWER_RESUME is not set
STG315_Kernel.config:# CONFIG_ZYXEL_POWER_RESUME is not set
STG326_Kernel.config:# CONFIG_ZYXEL_POWER_RESUME is not set
YOUSEE_Kernel.config:# CONFIG_ZYXEL_POWER_RESUME is not set

And also afaict from the search, GPIO 47 and 49 are common to all NSA3xx boxes!

So the NSA325 DTS contains a wrong name for GPIO 47. I think this was where I got sidetracked, and started to look for other causes. This should have been called power_resume_data, and to be used with the clock pull GPIO 49. This is used to cause all power to turn on, not just SATA1.

pmx_pwr_sata1: pmx-pwr-sata1 {
                                marvell,pins = "mpp47";
                                marvell,function = "gpio";
                        };

Please try what pbg4 has posted above (put the script invocation in rc.local, or paste the commands into it)

#!/bin/bash
# power_resume.sh [0/1]
# 0 to disable, 1 to enable.
# enable/disable resume from power loss.

# export both gpios
echo 47 > /sys/class/gpio/export
echo 49 > /sys/class/gpio/export

# 49 out, value 1
echo "out" > /sys/class/gpio/gpio49/direction
echo 1 > /sys/class/gpio/gpio49/value
# 47 out, value 1
echo "out" > /sys/class/gpio/gpio47/direction
echo $1 > /sys/class/gpio/gpio47/value
# set 49 value 0
echo 0 > /sys/class/gpio/gpio49/value

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



Edited 1 time(s). Last edit at 07/17/2015 07:17PM by bodhi.

done, now the device is shown as still up (1000 baseT-FD)
this doesn't change when U-Boot is up and running.
pinging is now possible.

when powering up, the green LED flashes shortly and goes of
booting into debian makes the amber LED flashing when the driver is loading



Edited 3 time(s). Last edit at 07/18/2015 02:30AM by pengu.

pengu Wrote:
-------------------------------------------------------
> done, now the device is shown as still up (1000
> baseT-FD)
> this doesn't change when U-Boot is up and
> running.
> pinging is now possible.
>
> when powering up, the green LED flashes shortly
> and goes of
> booting into debian makes the amber LED flashing
> when the driver is loading

Awesome!

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

Not working here.
I put a call to the script in rc.local and it's executed at startup:

root@debian:~# ls /sys/class/gpio/
.  ..  export  gpio47  gpio49  gpiochip0  gpiochip32  unexport
root@debian:~# cat /sys/class/gpio/gpio47/direction 
out
root@debian:~# cat /sys/class/gpio/gpio47/value     
1
root@debian:~# cat /sys/class/gpio/gpio49/direction 
out
root@debian:~# cat /sys/class/gpio/gpio49/value     
0

But same as before: link only on reboots after first booting into Zyxel OS.
No link at coldboot or after poweroff from Debian.

Also if I pull the powerplug for a few seconds and connect it again the device will not power up automtically.

It seems as though you guys have different versions of the NSA310S :) Furthermore, I'm thinking even though GPIO 47 and 49 are common for NSA3xx, they might not be used in the 310S that is not working (I am still digging in GPL code, and we don't know if this GPL reflects the latest FW). Wish I have my NSA325 at home to double check this too.

I've attached the GPIO tool binary in this post (thanks pbg4). Perhaps we can find out with these 3 tests:

1. In Zyxel OS after boot when network is working.
2. In Debian after boot when network is working.
3. In Debian after boot when network is not working.

Execute the binary and it will display all 50 pins

./kw-gpio

Output will looks like (this was from the iConnect box):

pagesize is 0x1000
regs mapped at 0xb6fcc000
MPP mapped at 0xb6fcc000
GPIO mapped at 0xb6fcc100
pin=00, mode=1, dir=1, dout=0, act=0, din=0
pin=01, mode=1, dir=1, dout=0, act=0, din=0
....
pin=49, mode=0, dir=1, dout=0, act=0, din=0

Hopefully, we will see which GPIOs are different.

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



Edited 1 time(s). Last edit at 07/18/2015 06:32AM by bodhi.

I agree that we may have a differnet hardware version.

I'm currently also looking into the GPL sources.
What I found so far (maybe totally useless/wrong - doing this for the first time):

The "NSA-310S" is internally names "STG315" and I assume it's mapped to a #define "CONFIG_MitraStar_STG315" (didn't find out where this is done so far).

As you also found there is:

STG315_Kernel.config:# CONFIG_ZYXEL_POWER_RESUME is not set

and that's because in trunk/linux-2.6.31.8/arch/arm/mach-feroceon-kw/gpio_ctrl.c, line 196:

#if defined CONFIG_ZYXEL_NSA325 || defined CONFIG_MitraStar_STG315 || defined CONFIG_MitraStar_STG326
	#define POWER_RESUME_DATA_GPIO_REG_OFFSET	GPIO_UNDEFINE_PIN
	#define POWER_RESUME_CLK_GPIO_REG_OFFSET	GPIO_UNDEFINE_PIN
#endif

So: no gpio's for power control on the 310S!
Looks like they do the eth-phy init with some register poking on boot.
That's here: trunk/sysapps/common_file/STG315/basicfs/etc/init.d/rcS2, line 28:

${ECHO} "Start rcS2 of ZyXEL style"

## for LED settings
phypoke 1 16 3
phypoke 1 10 1017
phypoke 1 11 4408

#The MCU set the phy to 10-Mb mode as low-power status.
#We have to set it back when booting up.
${ECHO} "Set the phy back to auto-negotiation mode"
phypoke 1 16 0
phypoke 1 4 1e1 
phypoke 1 9 300
## Downshift enable for network testing
phypoke 1 10 3860
phypoke 1 0 9140

Next thing I want to try is to copy /sbin/phypeek and /sbin/phypoke to Debian and see if this register woodoo will help.
I'll keep you updated...

superelchi,

> The "NSA-310S" is internally names "STG315" and I
> assume it's mapped to a #define
> "CONFIG_MitraStar_STG315" (didn't find out where
> this is done so far).
>
> As you also found there is:
>

> STG315_Kernel.config:# CONFIG_ZYXEL_POWER_RESUME
> is not set
> 

and that's because in
> trunk/linux-2.6.31.8/arch/arm/mach-feroceon-kw/gpi
> o_ctrl.c, line 196:
>

> #if defined CONFIG_ZYXEL_NSA325 || defined
> CONFIG_MitraStar_STG315 || defined
> CONFIG_MitraStar_STG326
> 	#define
> POWER_RESUME_DATA_GPIO_REG_OFFSET	GPIO_UNDEFINE_PI
> N
> 	#define
> POWER_RESUME_CLK_GPIO_REG_OFFSET	GPIO_UNDEFINE_PIN
> 
> #endif
>

I agree. I've found and have the same thought. That's why I thought it's Zyxel oversight.

Also, these values above were in in the 320S DTS (and I've copied them into the 310S DTS), it should have worked the same way as far as Debian is concerned.

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



Edited 2 time(s). Last edit at 07/18/2015 07:09AM by bodhi.

Success!

What I have done:

Copied /sbin/phypoke from ZyXel OS to Debin /sbin.

Created nsa310s-init.sh

#!/bin/sh

## for LED settings
/sbin/phypoke 1 16 3
/sbin/phypoke 1 10 1017
/sbin/phypoke 1 11 4408

#The MCU set the phy to 10-Mb mode as low-power status.
#We have to set it back when booting up.
/sbin/phypoke 1 16 0
/sbin/phypoke 1 4 1e1
/sbin/phypoke 1 9 300
## Downshift enable for network testing
/sbin/phypoke 1 10 3860
/sbin/phypoke 1 0 9140

Called it from rc.local.

Now link comes up on coldboot, reboot and after poweroff. :)

It will only work with static IP because the phy init is executet too late in the boot process for dhcp.
I know this is no solution to be put in the standard kernel but now we know where the problem lies.
Hope it helps a little...

Yay! Glad i was able to help on this matter even with insignifiant contribution (my extraterestrial download speed on zyxel sorces) :))

Cool :)

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

Now since it's working with the work around. I'd suggest the next step is to look at the DTS.

In the DTS, these register values were specified already in eth PHY. What would be the difference that caused Debian to ignore these values? I am suspecting that the "compatible" field was the culprit. So I've added both chips to the list. However, we don't know for sure that the Marvell driver did or did not regcognize 88e1318 (it seems that on the other boxes it did). The 320 DST has 88e1510, and that is OK running on that box.

&mdio {
	status = "okay";
	ethphy0: ethernet-phy@1 {
		compatible = "marvell,88e1318", "marvell,88e1510";
		reg = <1>;
                marvell,reg-init = <0x1 0x16 0x0 0x3>,
                                   <0x1 0x10 0x0 0x1017>,
                                   <0x1 0x11 0x0 0x4408>,
                                   <0x1 0x16 0x0 0x0>,
                                   <0x1 0x4 0x0 0x1e1>,
                                   <0x1 0x9 0x0 0x300>,
                                   <0x1 0x10 0x0 0x3860>,
                                   <0x1 0x0 0x0 0x9140>;
	};
};

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

@Johnny & superelchi,

Do you have a picture of the LAN chip in your box?

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

@bodhi,
I have one on my phone, i can send it to you. Just PM me your e-mail.
Phone is the only thing i have with me since i'm away.

bodhi Wrote:
-------------------------------------------------------
> Now since it's working with the work around. I'd
> suggest the next step is to look at the DTS.
>
> In the DTS, these register values were specified
> already in eth PHY. What would be the difference
> that caused Debian to ignore these values?

Good that I hadn't seen this DTS before - else maybe I hadn't tried my hack. ;)

> I am suspecting that the "compatible" field was the
> culprit. So I've added both chips to the list.
> However, we don't know for sure that the Marvell
> driver did or did not regcognize 88e1318 (it seems
> that on the other boxes it did). The 320 DST has
> 88e1510, and that is OK running on that box.

Can we persuade the driver somehow to tell us which chip it detected?

bodhi Wrote:
-------------------------------------------------------
Do you have a picture of the LAN chip in your box?

My LAN chip is exactly the same as the one on the picture pengu posted some pages ago. Exactly the same markings, down to the "1323 AOP" (what I suspect is the date code?).

Hi
I have ported nsa310s to wheezy's 3.2 kernel some time ago. My 2 cents for current support are:
HT1382 patch has issue with setting time
For simplicity and compatibility with zyxel's firmware we should use 24h mode so to set time we shoud use

regs.hour = bin2bcd(tm->tm_hour) | HT1328_24H_BIT;

in ht1382_rtc_set_time
not regs.hour = bin2bcd(tm->tm_hour);

I have alse "link not ready" fixed with this patch

nsa310s_phy_fixup(struct phy_device *phydev)
+{
+       int err;
+       int temp;
+       /* go to page 3 */
+       err = phy_write(phydev, 22, 3);
+       if (err < 0)
+           return err;
+       /* read page 3, register 17 */
+       temp = phy_read(phydev, 17);
+       /* clear bit 4, set bit 5 */
+       temp &= ~(1<<4);
+       temp |= (1<<5);
+       /* write page 3, register 17 */
+       err = phy_write(phydev, 17, temp);
+       if (err < 0)
+           return err;
+       /* go to page 0 */
+       err = phy_write(phydev, 22, 0);
+       if (err < 0)
+           return err;
+
+       return 0;
+}

I will check and compare my gpio mapping later

osa,

> nsa310s_phy_fixup(struct phy_device *phydev)
> +{
> +       int err;
> +       int temp;
> +       /* go to page 3 */
> +       err = phy_write(phydev, 22, 3);
> +       if (err < 0)
> +           return err;
> +       /* read page 3, register 17 */
> +       temp = phy_read(phydev, 17);
> +       /* clear bit 4, set bit 5 */
> +       temp &= ~(1<<4);
> +       temp |= (1<<5);
> +       /* write page 3, register 17 */
> +       err = phy_write(phydev, 17, temp);
> +       if (err < 0)
> +           return err;
> +       /* go to page 0 */
> +       err = phy_write(phydev, 22, 0);
> +       if (err < 0)
> +           return err;
> +
> +       return 0;
> +}

Thanks! nice patch :)

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

@superelchi,

> Can we persuade the driver somehow to tell us
> which chip it detected?

I looked at Marvell latest driver in Linux 4.1. Looks like it does not have the exact 88e1318 in the list of chips that needs special care (using reg-init). We'll have to use the 88e1510 for it to detect the chip model! otherwise, it falls back to the Marvell default handling.

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

bodhi Wrote:
-------------------------------------------------------
> @superelchi,
>
> > Can we persuade the driver somehow to tell us
> > which chip it detected?
>
> I looked at Marvell latest driver in Linux 4.1.
> Looks like it does not have the exact 88e1318 in
> the list of chips that needs special care (using
> reg-init). We'll have to use the 88e1510 for it to
> detect the chip model! otherwise, it falls back to
> the Marvell default handling.

Good work! One more puzzle-piece in place!
What I still do not understand: why is it working for Pengu and not for Johnny and me - hardware looks exactly the same. On Pengu's box the register woodoo seems to work as on bootup the phy is initialized...

Can't wait to test what you come up with!

Quote
osa
I have alse "link not ready" fixed with this patch
nsa310s_phy_fixup(struct phy_device *phydev)
+{
+ int err;
+ int temp;
+ /* go to page 3 */
+ err = phy_write(phydev, 22, 3);
+ if (err < 0)
+ return err;
+ /* read page 3, register 17 */
+ temp = phy_read(phydev, 17);
+ /* clear bit 4, set bit 5 */
+ temp &= ~(1<<4);
+ temp |= (1<<5);
+ /* write page 3, register 17 */
+ err = phy_write(phydev, 17, temp);
+ if (err < 0)
+ return err;
+ /* go to page 0 */
+ err = phy_write(phydev, 22, 0);
+ if (err < 0)
+ return err;
+
+ return 0;
+}

Can I somehow try this with phypeek and phypoke?
Tried with

phypoke 1 22 3

Gives error "illegal address"...

superelchi,

> What I still do not understand: why is it working
> for Pengu and not for Johnny and me - hardware
> looks exactly the same. On Pengu's box the
> register woodoo seems to work as on bootup the phy
> is initialized...

Yeah :) this has been a puzzle, as though pengu's box is a different 310S variation, or has different u-boot.

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

UPDATE: I've removed the binary that superelchi tried below. It was a wrong binary for this box :)

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



Edited 3 time(s). Last edit at 07/22/2015 02:16PM by bodhi.

Sorry. No luck at all.

Called it with:

$ kwboottool/kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.2014.07-tld-3.nsa310.uart.kwb

Stops after sending the image:

 .
 .
 92 % [......................................................................]
 94 % [......................................................................]
 96 % [......................................................................]
 99 % [....................................]
[Type Ctrl-\ + c to quit]

Cursor blinks in the next line. No further output.

superelchi,

Thanks for trying, I'll upload a different one in a few days!

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

Finally home and i've tried superelchi's solution with phypoke and fixed ip, works like a charm. So, until you guys work out something better, i'm happy with what we have at the moment ;)

Cheers!

PS: It seems my box doesn't want to resume after power loss and i wonder what can i do to solve this.



Edited 1 time(s). Last edit at 07/22/2015 03:48PM by JohnnyUSA.

JohnnyUSA Wrote:
-------------------------------------------------------
> Finally home and i've tried superelchi's solution
> with phypoke and fixed ip, works like a charm. So,
> until you guys work out something better, i'm
> happy with what we have at the moment ;)
>
> Cheers!
>
> PS: It seems my box doesn't want to resume after
> power loss and i wonder what can i do to solve
> this.

Perhaps rootfs was corrupted. Create a new rootfs on USB stick and boot with it. Run fsck on the existing rootfs after booted into Debian.

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