Ethernet on custom 7030 board not working

[lancec]

We've put together a custom zynq 7030 board with Marvell 88E1512 chip and are having problems getting the ethernet to work. We can see the chip from u-boot and write to the registers but autonegotiation fails every time. Obviously we've checked the electrical connections out to the network several times and they always come back okay. Also once booted into Linux we can set an ip address on eth0 but ping comes back with Network unreachable.

Our u-boot debug output:

zynq-uboot> dhcp
Trying Gem.e000b000
Default phy address 0 is valid
zynq_gem_miiphyread 0x0, 0x2, 0x141
zynq_gem_miiphyread 0x0, 0x3, 0xdd1
zynq_gem_miiphyread 0x0, 0x0, 0x1140
zynq_gem_miiphy_write 0x0, 0x0, 0x9140
zynq_gem_miiphyread 0x0, 0x0, 0x1140
Gem.e000b000 connected to Marvell 88E1518
zynq_gem_miiphy_write 0x0, 0x0, 0x8000
zynq_gem_miiphyread 0x0, 0x0, 0x0
zynq_gem_miiphyread 0x0, 0x4, 0x1e1
zynq_gem_miiphy_write 0x0, 0x4, 0xde1
zynq_gem_miiphyread 0x0, 0x9, 0x300
zynq_gem_miiphyread 0x0, 0x0, 0x0
zynq_gem_miiphy_write 0x0, 0x0, 0x1200
zynq_gem_miiphyread 0x0, 0x0, 0x1000
zynq_gem_miiphy_write 0x0, 0x0, 0x9000
zynq_gem_miiphyread 0x0, 0x0, 0x1000
zynq_gem_miiphyread 0x0, 0x1, 0x7949
Gem.e000b000 Waiting for PHY auto negotiation to complete.zynq_gem_miiphyread 0x0, 0x1, 0x7949
zynq_gem_miiphyread 0x0, 0x1, 0x7949
zynq_gem_miiphyread 0x0, 0x1, 0x7949

...
zynq_gem_miiphyread 0x0, 0x1, 0x7949
zynq_gem_miiphyread 0x0, 0x1, 0x7949
zynq_gem_miiphyread 0x0, 0x1, 0x7949
user interrupt!
zynq_gem_miiphyread 0x0, 0x11, 0x8040
Gem.e000b000: No link.
FAIL 

Any thoughts?

[linnj]

Hi,

What PHY interface are u using (GMII, RGMII, etc...)?

Did you build u-boot and Linux with the Marvell PHY drivers?

Thanks
John

[lancec]

We are using RGMII and we have built u-boot and linux with the Marvel drivers.

[linnj]

Here's an idea as I've seen this issue lately.

The PHY may need to be setup a bit differently with respect to the Rx and Tx delays of the data relative to the clock. The PHY data sheet should show the registers that you can adjust for this.  

You can try to capture some data by printing out received data in the PS EMAC driver or by capturing data with wireshark coming out (but it may not be valid enough for a PC NIC to receive it).  This would just show you the data is wrong ideally to prove you have data but it's shifted from the clock incorrectly.  I'm assuming that you have PHY LEDs on the board and it shows that your are transmitting and receiving.

Fro Linux, the phy-mode property below in the device tree of the PS ethernet controls that delay to some extent.

phy-mode = "rgmii-id";

This is the value for Rx and Tx delay if I remember right.

That string value is used by of_get_phy_mode() in  https://github.com/Xilinx/linux-xlnx/blob/master/drivers/of/of_net.c

to get an index into a table defined in https://github.com/Xilinx/linux-xlnx/blob/master/include/linux/phy.h

ultimately leading to one of these constants.

PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_RGMII_ID,
PHY_INTERFACE_MODE_RGMII_RXID,
PHY_INTERFACE_MODE_RGMII_TXID,

The RGMII value is no delay, the ID is both delayed and the others are for Rx or Tx only delays I believe.

The marvell phy drivers in Linux typically allow register initialization via the device tree with something like this below (not exactly, just an example).

phy1: phy@1 {
compatible = "marvell,88E1510";
device_type = "ethernet-phy";
reg = <0x1>;
marvell,reg-init =
<0 0x16 0 0x1>; /* Reg 0,22 <- 0x1 */
};

Thanks

John

[lancec]

We tried poking the Rx and Tx registers and had no success from that. We have been using a devicetree setup as you suggested.

[linnj]

I would try to look at the data then and see what it looks like.

[lancec]

We found that we were double crossing wires with out test cable. Fixed that and now eth0 comes up and works just fine. Our second phy still has some problems. We are unable to read the phy_id, and as such it always uses the generic drivers as opposed to the Marvell drivers. We've swapped out phy chips and still have the same problem. We've read several forums that point to the devicetree and we tried their suggestions without success.

Here is our output from the kernel:

# ifconfig eth0 192.168.60.100 up
[   72.824968] xemacps e000b000.ethernet: open
[   72.829492] xemacps e000b000.ethernet: RX ring 2048 bytes at 0x3f042000 mapped 7f042000
[   72.846856] xemacps e000b000.ethernet: TX ring 2048 bytes at 0x3f043000 mapped 7f043000
[   72.854821] xemacps e000b000.ethernet: lp->tx_bd 7f043000 lp->tx_bd_dma 3f043000 lp->tx_skb 7c146000
[   72.863968] xemacps e000b000.ethernet: lp->rx_bd 7f042000 lp->rx_bd_dma 3f042000 lp->rx_skb 7d446000
[   72.873061] xemacps e000b000.ethernet: MAC 0x00350a00, 0x00002201, 00:0a:35:00:01:22
[   72.883227] xemacps e000b000.ethernet: GEM: phydev 7d330c00, phydev->phy_id 0x1410dd1, phydev->addr 0x0
[   72.892578] xemacps e000b000.ethernet: phy_addr 0x0, phy_id 0x01410dd1
[   72.899049] xemacps e000b000.ethernet: attach [Marvell 88E1510] phy driver
# [   77.880275] xemacps e000b000.ethernet: Set clk to 124999999 Hz
[   77.886033] xemacps e000b000.ethernet: link up (1000/FULL)
# ifconfig eth1 192.168.60.101 up
[   83.354812] xemacps e000c000.ethernet: open
[   83.359274] xemacps e000c000.ethernet: RX ring 2048 bytes at 0x3f044000 mapped 7f044000
[   83.376756] xemacps e000c000.ethernet: TX ring 2048 bytes at 0x3f045000 mapped 7f045000
[   83.384764] xemacps e000c000.ethernet: lp->tx_bd 7f045000 lp->tx_bd_dma 3f045000 lp->tx_skb 7c113000
[   83.393844] xemacps e000c000.ethernet: lp->rx_bd 7f044000 lp->rx_bd_dma 3f044000 lp->rx_skb 7c114000
[   83.403464] xemacps e000c000.ethernet: MAC 0x00350a00, 0x00002301, 00:0a:35:00:01:23
[   83.489858] xemacps e000c000.ethernet: GEM: phydev 7d327c00, phydev->phy_id 0x0, phydev->addr 0x1
[   83.498650] xemacps e000c000.ethernet: phy_addr 0x1, phy_id 0x00000000
[   83.505190] xemacps e000c000.ethernet: attach [Generic PHY] phy driver
# [  233.903844] random: nonblocking pool is initialized

Here is our devicetree fro gem0 and gem1:

&gem0 {
	local-mac-address = [00 0a 35 00 00 00];
	phy-mode = "rgmii-id";
	status = "okay";
    phy-handle = <&phy0>;
	xlnx,enet-reset = <0xffffffff>;
	xlnx,eth-mode = <0x1>;
	xlnx,has-mdio = <0x1>;
	xlnx,ptp-enet-clock = <0x69f6bcb>;
	ps7_ethernet_0_mdio: mdio {
		#address-cells = <1>;
		#size-cells = <0>;
		phy0: phy@0 {
		    compatible = "marvell,88e1510";
		    device_type = "ethernet-phy";
		    reg = <0>;
		};
	};
};
&gem1 {
	local-mac-address = [00 0a 35 00 00 01];
	phy-mode = "rgmii-id";
	status = "okay";
    phy-handle = <&phy1>;
	xlnx,enet-reset = <0xffffffff>;
	xlnx,eth-mode = <0x1>;
	xlnx,has-mdio = <0x0>;
	xlnx,ptp-enet-clock = <0x69f6bcb>;
	ps7_ethernet_1_mdio: mdio {
		#address-cells = <1>;
		#size-cells = <0>;
		phy1: phy@1 {
		    compatible = "marvell,88e1510";
		    device_type = "ethernet-phy";
		    reg = <1>;
		};
	};
};

[lancec · Accepted solution]

Solved the issue the other day. Turns out we were missing a trace to one of the pins on the second ethernet. Added a jumper and both eth0 and eth1 work now.