Linux/AM5726: MDIO probe failed with DP83867

Hi,

This might be a solution for you.  Below is a post describing an issue very close to what you are reporting.

Link to e2e post about missing resistor on PHY reset line.

Good job BTW on using fixed phy settings to isolate the PHY. Did you do that in your DTS file?

Best Regards,

Schuyler

Hi Schuyler,

Thank you for the suggestion! (yes I isolated the problem using fixed phy by changing the dts file on emac.) However after further debugging, I'm convinced that our issue is different than the reset issue. Although our RESET_N is only controlled by POR but not by a GPIO, I think the POR should be sufficient. During kernel boot, when I probed the MDC and MDIO lines, there were activities.

Ch1 is MDC and Ch2 is MDIO. My questions:

(1) Why the MDC = 125K? On kernel log it says bus freq 1M. Did I miss anything in the dts file?

[    3.191524] davinci_mdio 48485000.mdio: davinci mdio revision 1.6, bus freq 1000000

(2) The MDIO line looks like a voltage level not going to ground, is this a hw problem? Perhaps this is the reason the mdio probe failed?

Thanks again!

Jan

Hi Schuyler,

After realizing my phy address is 0, I fixed my dts file and got mdio probe working:

[    3.199264] libphy: 48485000.mdio: probed
[    3.215875] davinci_mdio 48485000.mdio: phy[0]: device 48485000.mdio:00, driver TI DP83867
[    3.225374] cpsw 48484000.ethernet: Detected MACID = c4:f3:12:03:72:68
[    3.232025] cpsw 48484000.ethernet: initialized cpsw ale version 1.4

However eth0 init still failed:

[    9.971988] net eth0: initializing cpsw version 1.15 (0)
[   10.007637] net eth0: phy "/ocp/ethernet@48484000/mdio@48485000/ethernet-phy@0" not found on slave 0
[   10.090256] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

Not sure what else I'm missing. Here is my dts related to eth0:

&davinci_mdio {
 phy0: ethernet-phy@0 {
  reg = <0>;
 };
};

&cpsw_emac0 {
 phy-handle = <&phy0>;
 phy-mode = "rgmii";
 dual_emac_res_vlan = <1>;

};

Thanks,

Jan

Hi Jan,

A mid level voltage from the DP83867 is characteristic of improper strapping on GPIO_0.  If GPIO_0 is placed into mode 2 or mode 4, MDIO will become unresponsive and pull to mid rail.

If you have this GPIO connected to your processor, the processor may drive a voltage, or have an internal pull resistor that is causing this improper strapping.

Please try isolating GPIO_0, or pulling it down strongly to ground to go into mode 1.

Best Regards,

Thank you Bob for the suggestion!

After double checking the schematic, we realized that MDIO line was pulled up only to 1V rather than the I/O supply 1.8V. Now we fixed the pull up to 1.8V and the MDIO signal looks much better. However the eth0 init still fails.

[   10.302100] net eth0: initializing cpsw version 1.15 (0)
[   10.353590] net eth0: phy "/ocp/ethernet@48484000/mdio@48485000/ethernet-phy@0" not found on slave 0

The GPIO_0 is connected to the gate of a mosfet to drive an LED. We probed it and it was at 0 at RESET. I see MDIO read response on scope, but not sure why the init still fails. Could I be missing something in the software configuration or device tree?

Hi Schuyler,

After I copied some settings from another file (for a different target board) that uses rgmii-id mode, then function dp83867_of_init() returns success and fixed the error.

&davinci_mdio {
 phy0: ethernet-phy@0 {
  reg = <0>;
  ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
  ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
  ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
  ti,min-output-impedance;
  ti,dp83867-rxctrl-strap-quirk;
 };
};

&mac {
 status = "okay";
 dual_emac;
};

&cpsw_emac0 {
 phy-handle = <&phy0>;
 phy-mode = "rgmii-id";
 dual_emac_res_vlan = <1>;
 }; */

};

My original plain simple rgmii version just cannot get past the "dp83867_of_init" function successfully.

&davinci_mdio {
 phy0: ethernet-phy@0 {
  reg = <0>;
 };
};

&cpsw_emac0 {
 phy-handle = <&phy0>;
 phy-mode = "rgmii";
 dual_emac_res_vlan = <1>;

};

Why is that?

I didn't plan to use the rgmii-id mode because we used strap pins and took care of the tx delay = 0 and rx delay = 2ns, which is why my fix-phy was working fine. Now it seems that I have no choice but to set the delays in dts, then are the settings in dts in effect or the hw strap pins?

Thanks,

Jan