Phy issues

[Jeff]

Hello,

I have a design with an Marvell 88E1512 Phy connected to the RGMII interface of the OSD3358. My device tree is like so:

 

&davinci_mdio { pinctrl-names = "default", "sleep"; pinctrl-0 = <&davinci_mdio_default>; pinctrl-1 = <&davinci_mdio_sleep>; status = "okay"; /* The expander comes up long after mdio probe */ reset-gpios = <&tca6424 3 GPIO_ACTIVE_LOW>; reset-delay-us = <100>; }; &cpsw_emac0 { status = "disabled"; phy_id = <&davinci_mdio>, <0>; phy-mode = "rgmii"; }; /*1788 connected to port 1 (RGMII2)*/ &cpsw_emac1 { status = "okay"; phy_id = <&davinci_mdio>, <1>; phy-mode = "rgmii"; }; &mac { status = "okay"; pinctrl-names = "default", "sleep"; pinctrl-0 = <&rgmii_switch_pins_default>; pinctrl-1 = <&rgmii_switch_pins_sleep>; };

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

&davinci_mdio { pinctrl-names = "default", "sleep"; pinctrl-0 = <&davinci_mdio_default>; pinctrl-1 = <&davinci_mdio_sleep>; status = "okay"; /*  The expander comes up long after mdio probe */ reset-gpios = <&tca6424 3 GPIO_ACTIVE_LOW>; reset-delay-us = <100>; };   &cpsw_emac0 { status = "disabled"; phy_id = <&davinci_mdio>, <0>; phy-mode = "rgmii"; };   /*1788 connected to port 1 (RGMII2)*/ &cpsw_emac1 { status = "okay"; phy_id = <&davinci_mdio>, <1>; phy-mode = "rgmii"; };   &mac { status = "okay"; pinctrl-names = "default", "sleep"; pinctrl-0 = <&rgmii_switch_pins_default>; pinctrl-1 = <&rgmii_switch_pins_sleep>; };

When I load the network drivers as follows:

modprove davinci_cpdma

modprobe davinci_mdio

modprobe ti_cpsw

I get the following output:

 

[    1.175924] mdio_bus fixed-0: GPIO lookup for consumer reset

[    1.175941] mdio_bus fixed-0: using lookup tables for GPIO lookup

[    1.176019] mdio_bus fixed-0: lookup for GPIO reset failed

[    8.444341] davinci_mdio 4a101000.mdio: GPIO lookup for consumer reset

[    8.444381] davinci_mdio 4a101000.mdio: using device tree for GPIO lookup

[    8.444428] of_get_named_gpiod_flags: parsed ‘reset-gpios’ property of node ‘/ocp/ethernet@4a100000/mdio@4a101000[0]’ – status (0)

[    8.460639] mdio_bus 4a101000.mdio: GPIO lookup for consumer reset

[    8.460653] mdio_bus 4a101000.mdio: using lookup tables for GPIO lookup

[    8.460668] mdio_bus 4a101000.mdio: lookup for GPIO reset failed

[    8.517517] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6, bus freq 1000000

[    8.525534] davinci_mdio 4a101000.mdio: detected phy mask fffffffd

[    8.550565] libphy: 4a101000.mdio: probed

[    8.561775] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, driver Marvell 88E1510

That looks to me like it found the device and everything is good, however once I try using IP to bring the link up I get odd results:

 

[  124.823299] net eth0: initializing cpsw version 1.12 (0)

[  124.829076] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4

[  124.835715] cpsw 4a100000.ethernet: ALE Table size 1024

[  124.939318] Marvell 88E1510 4a101000.mdio:01: attached PHY driver [Marvell 88E1510] (mii_bus:phy_addr=4a101000.mdio:01, irq=POLL)

[  124.952145] libphy: PHY  not found

[  124.955719] net eth0: phy “” not found on slave 1, err -19

[root@BBG-1300- ~]$ [  129.210632] cpsw 4a100000.ethernet eth0: Link is Up – 1Gbps/Full – flow control rx/tx

 

Not quite sure the state of things but last couple messages seem odd, am I missing somthing in my DTS?

 

Thanks,

 

Jeff

 

 

 

[Neeraj Dantu]

Jeff,

Apologies for the late reply.

It looks like there is an issue with reset-gpio you defined in the mdio node. Please check whether the reset GPIO is working and is in the desired state when the Ethernet PHY is being probed.

Best,

Neeraj

[Aedan Cullen]

I haven’t yet gathered a complete understanding of this, but an initial search suggests that you’d want to check the reset and such: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/692995/linux-am3358-ethernet-phy-error 

Reset seems even more of a potential culprit given your device tree – could you explain the comment about the TCA6424 on your board coming up later? You could probe the reset signal to take a look at it relative to other signals to the PHY, and first maybe see if you can rule out reset as the cause of the issue.

[Author]

Posts