Phy issues

Forums Devices OSD335x C-SiP Phy issues

Viewing 2 reply threads
  • Author
    Posts
    • #13582
      JeffJeff
      Participant

      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>;
      };
      

      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

       

       

       

    • #13654

      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

    • #13583
      Aedan Cullen
      Participant

      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.

Viewing 2 reply threads
  • You must be logged in to reply to this topic.
chatsimple