socfpga/sockit ethernet problems

socfpga/sockit ethernet problems

[Pavel Machek]

Hi!

It seems we have some problems with Ethernet on socfpga boards.

Like, "stmmac: Energy-Efficient Ethernet initialized" repeated way too
often. Or machine failing to boot because NFS server can not be
accessed. (And then working on next try). Or link going up and down
and up and down. Or link taking 3 seconds, 10 seconds to estabilish.

It also seems to be picky about hubs it wants to talk to.

This time it mounted root; on last boot it just hung.

Mounts root 31.394855 Waiting 5 sec before mounting root device...
Mounts root 33.331379 stmmaceth ff702000.ethernet eth0: Link is Up -
100Mbps/Full - flow control rx/tx
Mounts root 36.418308 VFS: Mounted root (nfs filesystem) on device
0:12.
### Milestone reached:  Mounts root
Userland boots 51.455751 nfs: server 192.168.1.1 not responding, still
trying
Userland boots 52.552075 nfs: server 192.168.1.1 OK
Userland boots 52.555110 devtmpfs: mounted
Userland boots 52.566032 Freeing unused kernel memory: 264K (80597000
- 805d9000)
Userland boots 61.395175 nfs: server 192.168.1.1 not responding, still
trying
Userland boots 61.401301 nfs: server 192.168.1.1 OK

U-boot seems to configure phy timing:

u-boot talk 12.033741 Configuring PHY skew timing for Micrel ksz9021

is there something similar that needs to be done at Linux layer.

Any ideas? Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: socfpga/sockit ethernet problems

[Dinh Nguyen]

On 05/07/2014 05:45 AM, Pavel Machek wrote:
> Hi!
>
> It seems we have some problems with Ethernet on socfpga boards.
>
> Like, "stmmac: Energy-Efficient Ethernet initialized" repeated way too
> often. Or machine failing to boot because NFS server can not be

There's a patch that already mainlined that fixes this:

83bf79b6bb stmmac: disable at run-time the EEE if not supported


> accessed. (And then working on next try). Or link going up and down
> and up and down. Or link taking 3 seconds, 10 seconds to estabilish.
>
> It also seems to be picky about hubs it wants to talk to.
>
> This time it mounted root; on last boot it just hung.
>
> Mounts root 31.394855 Waiting 5 sec before mounting root device...
> Mounts root 33.331379 stmmaceth ff702000.ethernet eth0: Link is Up -
> 100Mbps/Full - flow control rx/tx
> Mounts root 36.418308 VFS: Mounted root (nfs filesystem) on device
> 0:12.
> ### Milestone reached:  Mounts root
> Userland boots 51.455751 nfs: server 192.168.1.1 not responding, still
> trying
> Userland boots 52.552075 nfs: server 192.168.1.1 OK
> Userland boots 52.555110 devtmpfs: mounted
> Userland boots 52.566032 Freeing unused kernel memory: 264K (80597000
> - 805d9000)
> Userland boots 61.395175 nfs: server 192.168.1.1 not responding, still
> trying
> Userland boots 61.401301 nfs: server 192.168.1.1 OK
>
> U-boot seems to configure phy timing:
>
> u-boot talk 12.033741 Configuring PHY skew timing for Micrel ksz9021
>
> is there something similar that needs to be done at Linux layer.

I haven't tested in the sockit, but I have been testing on the devkit, 
and I am able to NFS mount just fine everytime.

I have a branch at:

git://git.rocketboards.org/linux-socfpga-next.git  for-next

that you can test.

Dinh
>
> Any ideas? Thanks,
> 									Pavel
>

Re: socfpga/sockit ethernet problems

[Pavel Machek]

Hi!

> 
> It seems we have some problems with Ethernet on socfpga boards.
> 
> Like, "stmmac: Energy-Efficient Ethernet initialized" repeated way too
> often. Or machine failing to boot because NFS server can not be
> accessed. (And then working on next try). Or link going up and down
> and up and down. Or link taking 3 seconds, 10 seconds to estabilish.
> 
> It also seems to be picky about hubs it wants to talk to.
> 
> This time it mounted root; on last boot it just hung.
...
> u-boot talk 12.033741 Configuring PHY skew timing for Micrel ksz9021
> 
> is there something similar that needs to be done at Linux layer.

It seems there is. There is patch at
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/184335.html
, but it does not match the code we have in u-boot (and that seems to
work).

I made this, but ethernet problems I currently see are not frequent
enough to allow easy debugging. If link takes long to  estabilish for
you, could you test the patch below?

Thanks,
								Pavel

Signed-off-by: Pavel Machek <pavel@denx.de>

diff --git a/arch/arm/mach-at91/board-dt-sama5.c b/arch/arm/mach-at91/board-dt-sama5.c
index 075ec05..6a2d5f7 100644
--- a/arch/arm/mach-at91/board-dt-sama5.c
+++ b/arch/arm/mach-at91/board-dt-sama5.c
@@ -51,11 +51,11 @@ static int ksz9021rn_phy_fixup(struct phy_device *phy)
 	int value;
 
 	/* Set delay values */
-	value = MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW | 0x8000;
+	value = MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW | 0x8000;
 	phy_write(phy, MICREL_KSZ9021_EXTREG_CTRL, value);
 	value = 0xF2F4;
 	phy_write(phy, MICREL_KSZ9021_EXTREG_DATA_WRITE, value);
-	value = MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW | 0x8000;
+	value = MICREL_KSZ9021_RGMII_RX_DATA_PAD_SKEW | 0x8000;
 	phy_write(phy, MICREL_KSZ9021_EXTREG_CTRL, value);
 	value = 0x2222;
 	phy_write(phy, MICREL_KSZ9021_EXTREG_DATA_WRITE, value);
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index e60456d..8a0ba06 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -45,15 +45,15 @@ static int ksz9021rn_phy_fixup(struct phy_device *phydev)
 	if (IS_BUILTIN(CONFIG_PHYLIB)) {
 		/* min rx data delay */
 		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
-			0x8000 | MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW);
+			0x8000 | MICREL_KSZ9021_RGMII_RX_DATA_PAD_SKEW);
 		phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
 
 		/* max rx/tx clock delay, min rx/tx control delay */
 		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
-			0x8000 | MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW);
+			0x8000 | MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW);
 		phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0xf0f0);
 		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
-			MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW);
+			MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW);
 	}
 
 	return 0;
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index adbf383..4a953c0 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -19,6 +19,8 @@
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/reboot.h>
+#include <linux/phy.h>
+#include <linux/micrel_phy.h>
 
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>
@@ -85,6 +87,44 @@ static void __init socfpga_init_irq(void)
 	socfpga_sysmgr_init();
 }
 
+static int ksz9021rn_phy_fixup(struct phy_device *phydev)
+{
+        if (IS_BUILTIN(CONFIG_PHYLIB)) {
+		printk("------------- running phy fixup\n");
+
+                /* min rx data delay */
+                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
+			  0x8000 | MICREL_KSZ9021_RGMII_RX_DATA_PAD_SKEW);
+                phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
+
+                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
+			  0x8000 | MICREL_KSZ9021_RGMII_TX_DATA_PAD_SKEW);
+                phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
+
+                /* max rx/tx clock delay, min rx/tx control delay */
+                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
+			  0x8000 | MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW);
+                phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0xf0f0);
+                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
+			  MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW);
+        }
+
+        return 0;
+}
+
+static void __init socfpga_init_machine(void)
+{
+	early_printk("socfpga_init_machine\n");
+        if (IS_BUILTIN(CONFIG_PHYLIB)) {
+		printk("---------- registering phy fixup\n");
+                phy_register_fixup_for_uid(PHY_ID_KSZ9021, MICREL_PHY_ID_MASK,
+					   ksz9021rn_phy_fixup);
+        }
+	early_printk("socfpga_init_machine done\n");
+
+}
+
+
 static void socfpga_cyclone5_restart(enum reboot_mode mode, const char *cmd)
 {
 	u32 temp;
@@ -109,6 +149,7 @@ DT_MACHINE_START(SOCFPGA, "Altera SOCFPGA")
 	.smp		= smp_ops(socfpga_smp_ops),
 	.map_io		= socfpga_map_io,
 	.init_irq	= socfpga_init_irq,
+	.init_late   = socfpga_init_machine,
 	.restart	= socfpga_cyclone5_restart,
 	.dt_compat	= altera_dt_match,
 MACHINE_END
diff --git a/include/linux/micrel_phy.h b/include/linux/micrel_phy.h
index 2e5b194..de40c89 100644
--- a/include/linux/micrel_phy.h
+++ b/include/linux/micrel_phy.h
@@ -40,7 +40,8 @@
 
 #define MICREL_KSZ9021_EXTREG_CTRL	0xB
 #define MICREL_KSZ9021_EXTREG_DATA_WRITE	0xC
-#define MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW	0x104
-#define MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW	0x105
+#define MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW	0x104
+#define MICREL_KSZ9021_RGMII_RX_DATA_PAD_SKEW	0x105
+#define MICREL_KSZ9021_RGMII_TX_DATA_PAD_SKEW	0x106
 
 #endif /* _MICREL_PHY_H */


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: socfpga/sockit ethernet problems

[Dinh Nguyen]

Hi Pavel,

On Thu, 2014-07-03 at 11:35 +0200, ZY - pavel wrote:
> Hi!
> 
> > 
> > It seems we have some problems with Ethernet on socfpga boards.
> > 
> > Like, "stmmac: Energy-Efficient Ethernet initialized" repeated way too
> > often. Or machine failing to boot because NFS server can not be
> > accessed. (And then working on next try). Or link going up and down
> > and up and down. Or link taking 3 seconds, 10 seconds to estabilish.
> > 

The "stmmac: Energy-Efficient Ethernet initialized" being repeated
should have been fixed with this commit:

138b1ceb2613 stmmac: disable at run-time the EEE if not supported

> > It also seems to be picky about hubs it wants to talk to.
> > 
> > This time it mounted root; on last boot it just hung.
> ...
> > u-boot talk 12.033741 Configuring PHY skew timing for Micrel ksz9021
> > 
> > is there something similar that needs to be done at Linux layer.
> 
> It seems there is. There is patch at
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/184335.html
> , but it does not match the code we have in u-boot (and that seems to
> work).
> 
> I made this, but ethernet problems I currently see are not frequent
> enough to allow easy debugging. If link takes long to  estabilish for
> you, could you test the patch below?
> 
> Thanks,
> 								Pavel
> 
> Signed-off-by: Pavel Machek <pavel@denx.de>
> 
> diff --git a/arch/arm/mach-at91/board-dt-sama5.c b/arch/arm/mach-at91/board-dt-sama5.c
> index 075ec05..6a2d5f7 100644
> --- a/arch/arm/mach-at91/board-dt-sama5.c
> +++ b/arch/arm/mach-at91/board-dt-sama5.c
> @@ -51,11 +51,11 @@ static int ksz9021rn_phy_fixup(struct phy_device *phy)
>  	int value;
>  
>  	/* Set delay values */
> -	value = MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW | 0x8000;
> +	value = MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW | 0x8000;
>  	phy_write(phy, MICREL_KSZ9021_EXTREG_CTRL, value);
>  	value = 0xF2F4;
>  	phy_write(phy, MICREL_KSZ9021_EXTREG_DATA_WRITE, value);
> -	value = MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW | 0x8000;
> +	value = MICREL_KSZ9021_RGMII_RX_DATA_PAD_SKEW | 0x8000;
>  	phy_write(phy, MICREL_KSZ9021_EXTREG_CTRL, value);
>  	value = 0x2222;
>  	phy_write(phy, MICREL_KSZ9021_EXTREG_DATA_WRITE, value);
> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> index e60456d..8a0ba06 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -45,15 +45,15 @@ static int ksz9021rn_phy_fixup(struct phy_device *phydev)
>  	if (IS_BUILTIN(CONFIG_PHYLIB)) {
>  		/* min rx data delay */
>  		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> -			0x8000 | MICREL_KSZ9021_RGMII_RX_DATA_PAD_SCEW);
> +			0x8000 | MICREL_KSZ9021_RGMII_RX_DATA_PAD_SKEW);
>  		phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
>  
>  		/* max rx/tx clock delay, min rx/tx control delay */
>  		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> -			0x8000 | MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW);
> +			0x8000 | MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW);
>  		phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0xf0f0);
>  		phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> -			MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SCEW);
> +			MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW);
>  	}
>  
>  	return 0;
> diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
> index adbf383..4a953c0 100644
> --- a/arch/arm/mach-socfpga/socfpga.c
> +++ b/arch/arm/mach-socfpga/socfpga.c
> @@ -19,6 +19,8 @@
>  #include <linux/of_irq.h>
>  #include <linux/of_platform.h>
>  #include <linux/reboot.h>
> +#include <linux/phy.h>
> +#include <linux/micrel_phy.h>
>  
>  #include <asm/hardware/cache-l2x0.h>
>  #include <asm/mach/arch.h>
> @@ -85,6 +87,44 @@ static void __init socfpga_init_irq(void)
>  	socfpga_sysmgr_init();
>  }
>  
> +static int ksz9021rn_phy_fixup(struct phy_device *phydev)
> +{
> +        if (IS_BUILTIN(CONFIG_PHYLIB)) {
> +		printk("------------- running phy fixup\n");
> +
> +                /* min rx data delay */
> +                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> +			  0x8000 | MICREL_KSZ9021_RGMII_RX_DATA_PAD_SKEW);
> +                phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
> +
> +                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> +			  0x8000 | MICREL_KSZ9021_RGMII_TX_DATA_PAD_SKEW);
> +                phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
> +
> +                /* max rx/tx clock delay, min rx/tx control delay */
> +                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> +			  0x8000 | MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW);
> +                phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0xf0f0);
> +                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> +			  MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW);
> +        }
> +
> +        return 0;
> +}
> +

All of this stuff is not needed as it's already taken care of by the
Micrel phy driver. The clock skew values are now represented in the DTS.
Please look at:

Documentation/devicetree/bindings/net/micrel-ksz90x1.txt

Dinh

Re: socfpga/sockit ethernet problems

[Pavel Machek]

Hi!

> > I made this, but ethernet problems I currently see are not frequent
> > enough to allow easy debugging. If link takes long to  estabilish for
> > you, could you test the patch below?

> > +static int ksz9021rn_phy_fixup(struct phy_device *phydev)
> > +{
> > +        if (IS_BUILTIN(CONFIG_PHYLIB)) {
> > +		printk("------------- running phy fixup\n");
> > +
> > +                /* min rx data delay */
> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> > +			  0x8000 | MICREL_KSZ9021_RGMII_RX_DATA_PAD_SKEW);
> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
> > +
> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> > +			  0x8000 | MICREL_KSZ9021_RGMII_TX_DATA_PAD_SKEW);
> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
> > +
> > +                /* max rx/tx clock delay, min rx/tx control delay */
> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> > +			  0x8000 | MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW);
> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0xf0f0);
> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
> > +			  MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW);
> > +        }
> > +
> > +        return 0;
> > +}
> > +
> 
> All of this stuff is not needed as it's already taken care of by the
> Micrel phy driver. The clock skew values are now represented in the DTS.
> Please look at:
> 
> Documentation/devicetree/bindings/net/micrel-ksz90x1.txt

Aah, thanks for the pointer. 

At least socfpga_cyclone5_socrates.dts is in the mainline, but it does
not have any skew configuration. That may explain why the board seems
to have problems with ethernet... (or not).

Are there suitable default values?

u-boot uses these defaults:

include/configs/socfpga_common.h:#define CONFIG_KSZ9021_CLK_SKEW_VAL
0xf0f0
include/configs/socfpga_common.h:#define CONFIG_KSZ9021_DATA_SKEW_VAL
0x0

...that should correspond to txc-skew-ps == rxc-skew-ps == 3000, all
other skew values == 0?

Could someone with socrates board and network problems test if this
makes any difference?

Signed-off-by: Pavel Machek <pavel@denx.de>

diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socrates.dts b/arch/arm/boot/dts/socfpga_cyclone5_socrates.dts
index a1814b4..eba8eea 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_socrates.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_socrates.dts
@@ -34,6 +34,16 @@
 
 &gmac1 {
 	status = "okay";
+	phy-mode = "rgmii";
+
+	rxd0-skew-ps = <0>;
+	rxd1-skew-ps = <0>;
+	rxd2-skew-ps = <0>;
+	rxd3-skew-ps = <0>;
+	txen-skew-ps = <0>;
+	txc-skew-ps = <3000>;
+	rxdv-skew-ps = <0>;
+	rxc-skew-ps = <3000>;
 };
 
 &i2c0 {



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: socfpga/sockit ethernet problems

[Steffen Trumtrar]

Hi!

Pavel Machek <pavel@denx.de> writes:
> Hi!
>
>> > I made this, but ethernet problems I currently see are not frequent
>> > enough to allow easy debugging. If link takes long to  estabilish for
>> > you, could you test the patch below?
>
>> > +static int ksz9021rn_phy_fixup(struct phy_device *phydev)
>> > +{
>> > +        if (IS_BUILTIN(CONFIG_PHYLIB)) {
>> > +		printk("------------- running phy fixup\n");
>> > +
>> > +                /* min rx data delay */
>> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
>> > +			  0x8000 | MICREL_KSZ9021_RGMII_RX_DATA_PAD_SKEW);
>> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
>> > +
>> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
>> > +			  0x8000 | MICREL_KSZ9021_RGMII_TX_DATA_PAD_SKEW);
>> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0x0000);
>> > +
>> > +                /* max rx/tx clock delay, min rx/tx control delay */
>> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
>> > +			  0x8000 | MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW);
>> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_DATA_WRITE, 0xf0f0);
>> > +                phy_write(phydev, MICREL_KSZ9021_EXTREG_CTRL,
>> > +			  MICREL_KSZ9021_RGMII_CLK_CTRL_PAD_SKEW);
>> > +        }
>> > +
>> > +        return 0;
>> > +}
>> > +
>> 
>> All of this stuff is not needed as it's already taken care of by the
>> Micrel phy driver. The clock skew values are now represented in the DTS.
>> Please look at:
>> 
>> Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
>
> Aah, thanks for the pointer. 
>
> At least socfpga_cyclone5_socrates.dts is in the mainline, but it does
> not have any skew configuration. That may explain why the board seems
> to have problems with ethernet... (or not).
>

The socrates does not have these values, because it does not have a
Micrel PHY...

> Are there suitable default values?
>
> u-boot uses these defaults:
>
> include/configs/socfpga_common.h:#define CONFIG_KSZ9021_CLK_SKEW_VAL
> 0xf0f0
> include/configs/socfpga_common.h:#define CONFIG_KSZ9021_DATA_SKEW_VAL
> 0x0
>
> ...that should correspond to txc-skew-ps == rxc-skew-ps == 3000, all
> other skew values == 0?
>
> Could someone with socrates board and network problems test if this
> makes any difference?
>

...so, would this even apply to the socrates then?

Regards,
Steffen

-- 
Pengutronix e.K.                           | Steffen Trumtrar            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: socfpga/sockit ethernet problems

[Stefan Roese]

Hi!

On 07.07.2014 23:43, Pavel Machek wrote:
>> All of this stuff is not needed as it's already taken care of by the
>> Micrel phy driver. The clock skew values are now represented in the DTS.
>> Please look at:
>>
>> Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
>
> Aah, thanks for the pointer.
>
> At least socfpga_cyclone5_socrates.dts is in the mainline, but it does
> not have any skew configuration. That may explain why the board seems
> to have problems with ethernet... (or not).
>
> Are there suitable default values?
>
> u-boot uses these defaults:
>
> include/configs/socfpga_common.h:#define CONFIG_KSZ9021_CLK_SKEW_VAL
> 0xf0f0
> include/configs/socfpga_common.h:#define CONFIG_KSZ9021_DATA_SKEW_VAL
> 0x0
>
> ...that should correspond to txc-skew-ps == rxc-skew-ps == 3000, all
> other skew values == 0?
>
> Could someone with socrates board and network problems test if this
> makes any difference?

SoCrates uses a different PHY, the Lantiq PEF7071 (PHY11G). So those dts 
additions have no effect on SoCrates.

Thanks,
Stefan

Re: socfpga/sockit ethernet problems

[Pavel Machek]

Hi!

> >Are there suitable default values?
> >
> >u-boot uses these defaults:
> >
> >include/configs/socfpga_common.h:#define CONFIG_KSZ9021_CLK_SKEW_VAL
> >0xf0f0
> >include/configs/socfpga_common.h:#define CONFIG_KSZ9021_DATA_SKEW_VAL
> >0x0
> >
> >...that should correspond to txc-skew-ps == rxc-skew-ps == 3000, all
> >other skew values == 0?
> >
> >Could someone with socrates board and network problems test if this
> >makes any difference?
> 
> SoCrates uses a different PHY, the Lantiq PEF7071 (PHY11G). So those
> dts additions have no effect on SoCrates.

Oops, I guess I was confused.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: socfpga/sockit ethernet problems

[Pavel Machek]

Hi!

> >> All of this stuff is not needed as it's already taken care of by the
> >> Micrel phy driver. The clock skew values are now represented in the DTS.
> >> Please look at:
> >> 
> >> Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> >
> > Aah, thanks for the pointer. 
> >
> > At least socfpga_cyclone5_socrates.dts is in the mainline, but it does
> > not have any skew configuration. That may explain why the board seems
> > to have problems with ethernet... (or not).
> 
> The socrates does not have these values, because it does not have a
> Micrel PHY...

Hmm, that is not it, then :-(. Is there any other setup that needs to
be done? Because from the experience with the socrates boards, they
are quite picky about cabling used.

Thanks and best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html