i.MX8QXP RMII Ethernet Phy issues

[rob_mclean]

I'm trying to get an i.MX8QXP to communicate with an RMII Ethernet PHY, specifically a Microchip KSZ8061RNDW.  I can see the 50MHz reference clock coming out of the "ENET0_RGMII_TXC" pad.   When I do an "ifconfig eth0 up", I get this notification in Linux telling me the link is up so I know the MDIO is working.

[ 2543.250265] Micrel KSZ8061 5b040000.ethernet-1:01: attached PHY driver [Micrel KSZ8061] (mii_bus:phy_addr=5b040000.ethernet-1:01, irq=POLL)
[ 2546.342710] fec 5b040000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx

My device tree looks like this:

&fec1 {
    pinctrl-names = "default", "sleep";
    pinctrl-0 = <&pinctrl_fec1>;
    clocks = <&clk IMX8QXP_ENET0_IPG_CLK>,
             <&clk IMX8QXP_ENET0_AHB_CLK>,
             <&clk IMX8QXP_ENET0_REF_50MHZ_CLK>,
             <&clk IMX8QXP_ENET0_PTP_CLK>,
             <&clk IMX8QXP_ENET0_TX_CLK>;
    phy-mode = "rmii";
    phy-handle = <&ethphy1>;
    phy-supply = <&reg_3v3_eth0>;
    fsl,magic-packet;
    status = "okay";

    mdio {
        #address-cells = <1>;
        #size-cells = <0>;

        ethphy1: ethernet-phy@1 {
            compatible = "ethernet-phy-ieee802.3-c22";
            reg = <1>;
            phy-reset-gpios = <&gpio3 18 GPIO_ACTIVE_LOW>;
            reset-assert-us = <1000>;
            reset-deassert-us = <2000>;
            max-speed = <100>;
            };
      };
};

&iomuxc {
    pinctrl_fec1: fec1grp {
        fsl,pins = <
            SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB0_PAD 0x000014a0
            SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB1_PAD 0x000014a0
            SC_P_ENET0_MDC_CONN_ENET0_MDC                   0x00000060
            SC_P_ENET0_MDIO_CONN_ENET0_MDIO                 0x00000060
            SC_P_ENET0_RGMII_TXC_CONN_ENET0_RCLK50M_OUT     0x00000060
            SC_P_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD0     0x00000060
            SC_P_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD1     0x00000060
            SC_P_ENET0_RGMII_RXD2_CONN_ENET0_RMII_RX_ER     0x00000060
            SC_P_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL 0x00000060
            SC_P_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD0     0x00000060
            SC_P_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD1     0x00000060
            SC_P_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL 0x00000060
        >;
    };
};

When I added some debugging code to the FEC driver to tell me the speed of the reference clock, it indicated that the clock rate was 0Hz.  So I'm pretty sure that the 50MHz reference clock which is coming from the "ENET0_RGMII_TXC" pad is not getting properly plumbed back into the FEC. 

I did find this issue i.MXQXP RMII + 4.19.35 NXP Kernel Not Working which is similar enough to my problem to make me think the solution described there would also fix my problem.  That discussion suggested a kernel patch is needed to fix that reference clock problem, but I've not been able to find the patch, or create it on my own.

We are using a 4.14 kernel which is not unlike this one 4.14.98_2.3.0, and I'm not sure if we can move to a newer kernel yet.  So it would be ideal if we could find or create a patch that would fix the problem with the reference clock in the FEC.

Any help is greatly appreciated.

[rob_mclean · Accepted solution]

Turned out this problem didn't need a kernel patch after all.  It was only that the pins were improperly configured.  All the signals were muxed to the correct pads, but the TXC_CONN pad needed to be configured as an INOUT for the 50MHz clock to get routed both externally to the phy and internally to the FEC.  Without that pad being configured as an INOUT, the signal was only getting routed externally.  So the phy was getting properly clocked, but the FEC was not.  That allowed the phy to be responsive to MDIO and bring the link up and down, but the FEC would never transmit or receive data.

I ended up using this device tree entry for muxing the pads related to the phy:

&iomuxc {
    pinctrl_fec1: fec1grp {
        fsl,pins = <
            SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB0_PAD 0x000014a0
            SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB1_PAD 0x000014a0
            SC_P_ENET0_MDC_CONN_ENET0_MDC                   0x00000060
            SC_P_ENET0_MDIO_CONN_ENET0_MDIO                 0x00000060
            SC_P_ENET0_RGMII_TXC_CONN_ENET0_RCLK50M_OUT     0x06000060
            SC_P_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD0     0x00000060
            SC_P_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD1     0x00000060
            SC_P_ENET0_RGMII_RXD2_CONN_ENET0_RMII_RX_ER     0x00000060
            SC_P_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL 0x00000060
            SC_P_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD0     0x00000060
            SC_P_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD1     0x00000060
            SC_P_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL 0x00000060
        >;
    };
};

With that pin muxing change the problem went away, and the Ethernet started working.

I will want to use that same mux configuration in u-boot, but I expect that will get u-boot working as well.

[igorpadykov]

Hi Robert

>We are using a 4.14 kernel which is not unlike this one 4.14.98_2.3.0,

please note that NXP supports only own linux releases from source.codeaurora.org/external/imx/linux-imx repository
https://source.codeaurora.org/external/imx/linux-imx/tree/?h=lf-5.10.y

https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applicat...

Please try this latest linux release and provide linux/uboot logs for that issue and relevant sources changes.

Alternatively, support for other proprietary linux releases can be provided with NXP Professional Services:
https://contact.nxp.com/new-prof-svcs-sw-tech

In general one can try to debug it using   AN12631: Normal and Secure Debug for i.MX8/8X Family of Applications Processors – Application Note

Best regards
igor