i.MX8MP EQOS MAC RMII PHY connectivity issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX8MP EQOS MAC RMII PHY connectivity issue

3,014 Views
sinyuk
Contributor II

Dear NXP Team,

Looking for your help after 2 month debug process on our side.

Setup:

We have a custom board with i.MX8MP SOC  and  KSZ8081RNA  RMII PHY connected to EQOS MAC. The PHY drives 50Mhz clocks iMXMP MAC

The ethernet connectivity is tested in U-boot 2020.04

Issue:

While the auto-negotiation successfully passes and link status with led is green on both sides, no data traffic is detected.  Observed by issuing "dhcp" command in U-boot, but no data or error  is detected with "tcpdump" command from point-to-point Linux link partner.

Observations:

1) The RMII signals look good and we  tried 2 boards.

2) While programming PHY loopback (bit 14 of reg 0), we can see RMII signals on RX pins, but no data is received by DWC DMA.

3) When setting MAC loopback in dwc_eth_qos driver in U-boot  we successfully send and receive  while issuing "dhcp". So we trust U-boot driver

 

Conclusions:

Currently we suspect some desynchronization of RMII clock and data.

We tried tried all the options from GPR1 reg to properly synchronize on input clock from PHY. 

Will be glad to any hints from you side of how to proceed.       

Code modifications:

1) PINMUX

pinctrl_eqos: eqosgrp {
fsl,pins = <
MX8MP_IOMUXC_ENET_MDC__ENET_QOS_MDC 0x3
MX8MP_IOMUXC_ENET_MDIO__ENET_QOS_MDIO 0x3
MX8MP_IOMUXC_ENET_RD0__ENET_QOS_RGMII_RD0 0x91
MX8MP_IOMUXC_ENET_RD1__ENET_QOS_RGMII_RD1 0x91
MX8MP_IOMUXC_ENET_RD2__GPIO1_IO28 0x91
MX8MP_IOMUXC_ENET_RD3__GPIO1_IO29 0x91
MX8MP_IOMUXC_ENET_RXC__ENET_QOS_RX_ER 0x91
MX8MP_IOMUXC_ENET_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x91
MX8MP_IOMUXC_ENET_TD0__ENET_QOS_RGMII_TD0 0x1f
MX8MP_IOMUXC_ENET_TD1__ENET_QOS_RGMII_TD1 0x1f
MX8MP_IOMUXC_ENET_TD2__CCM_ENET_QOS_CLOCK_GENERATE_REF_CLK 0x0000000f
MX8MP_IOMUXC_ENET_TD3__GPIO1_IO18 0x1f
MX8MP_IOMUXC_ENET_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x1f
MX8MP_IOMUXC_ENET_TXC__ENET_QOS_TX_ER 0x1f
>;
};

2)  GPR1 register

static int setup_eqos(void)
{
struct iomuxc_gpr_base_regs *gpr =
(struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;

clrbits_le32(&gpr->gpr[1], BIT(20));

/* set INTF as RMII, enable RMII TXC clock */
clrsetbits_le32(&gpr->gpr[1],
IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_MASK, BIT(18));
setbits_le32(&gpr->gpr[1], BIT(19) );

return set_clk_eqos(ENET_50MHZ);
}

 

Best Regards,

   Konstantin.

5 Replies

2,862 Views
dh84
Contributor III

Hi @sinyuk,

have you found a solution for your problem? I've got nearly the same setup (eqos, rmii with external clock) and facing the same problems. In Linux everything is working fine, so it might be related to the uboot drivers.

Best regards,

Daniel

0 Kudos
Reply

2,786 Views
domzippi
Contributor II

Hi@dh84 ,

can you share your RMII configuration? I have a similar problem, but I'm unable to get it working in Linux. I'm stuck with the following error:

[    7.823171] imx-dwmac 30bf0000.ethernet: Failed to reset the dma
[    7.829205] imx-dwmac 30bf0000.ethernet eth1: stmmac_hw_setup: DMA engine initialization failed
[    7.838562] imx-dwmac 30bf0000.ethernet eth1: stmmac_open: Hw setup failed

 

Did you change anything else in the device tree?

0 Kudos
Reply

2,767 Views
dh84
Contributor III

Hi @domzippi,

find below my devicetree entries related to the eqos. In my opinion there might be something wrong with the pinmuxing. So, please check your pinctrl.

&eqos {
	phy-mode = "rmii";
	snps,rmii_refclk_ext;
	mdio_rst_after_resume;

	mdio {
		ethphy0: ethernet-phy@0 {
			compatible = "ethernet-phy-ieee802.3-c22";
			reg = <0>;
			max-speed = <100>;
			eee-broken-1000t;
			eee-broken-100tx;
			reset-gpios = <&gpio5 27 GPIO_ACTIVE_LOW>;
			reset-assert-us = <10000>;
			reset-deassert-us = <150000>;
		};
	};
};

    pinctrl_eqos: eqosgrp {
        fsl,pins = <
            MX8MP_IOMUXC_ENET_MDC__ENET_QOS_MDC        					0x00000002
            MX8MP_IOMUXC_ENET_MDIO__ENET_QOS_MDIO      					0x00000002
            MX8MP_IOMUXC_ENET_RD0__ENET_QOS_RGMII_RD0  					0x00000090
            MX8MP_IOMUXC_ENET_RD1__ENET_QOS_RGMII_RD1  					0x00000090
            MX8MP_IOMUXC_ENET_RXC__ENET_QOS_RX_ER      					0x00000090
            MX8MP_IOMUXC_ENET_RX_CTL__ENET_QOS_RGMII_RX_CTL 			0x00000090
            MX8MP_IOMUXC_ENET_TD0__ENET_QOS_RGMII_TD0  				 	0x00000016
            MX8MP_IOMUXC_ENET_TD1__ENET_QOS_RGMII_TD1  				  	0x00000016
            MX8MP_IOMUXC_ENET_TD2__CCM_ENET_QOS_CLOCK_GENERATE_REF_CLK 	0x40000090
            MX8MP_IOMUXC_ENET_TX_CTL__ENET_QOS_RGMII_TX_CTL 		  	0x00000016
            MX8MP_IOMUXC_SAI2_MCLK__GPIO4_IO27         					0x00000006
            MX8MP_IOMUXC_UART3_TXD__GPIO5_IO27         					0x00000006
        >;
    };

 

Best regards,

Daniel

2,760 Views
domzippi
Contributor II

Hi @dh84,

thanks for your configuration.

My dts looks very similar and I was able to resolve the issue by changing the direction of the RMII ref clock. Using an external clock (generated by the PHY) and adding snps,rmii_refclk_ext fixed the problem (without changing the pin configuration).

Can you explain why you use this pinmux setting?:

 

MX8MP_IOMUXC_ENET_TD2__CCM_ENET_QOS_CLOCK_GENERATE_REF_CLK 	0x40000090

 

Where does the leading 0x4 come from? Isn't the control register only 32bit?

Have you ever tried using the RMII interface when generating the ref clock from the MAC?

My pinctrl:

  pinctrl_eqos: eqosgrp {
		fsl,pins = <
			MX8MP_IOMUXC_ENET_MDC__ENET_QOS_MDC		0x3
			MX8MP_IOMUXC_ENET_MDIO__ENET_QOS_MDIO		0x3
			MX8MP_IOMUXC_ENET_RD0__ENET_QOS_RGMII_RD0	0x91
			MX8MP_IOMUXC_ENET_RD1__ENET_QOS_RGMII_RD1	0x91
			MX8MP_IOMUXC_ENET_RD2__GPIO1_IO28 0x91
			MX8MP_IOMUXC_ENET_RD3__GPIO1_IO29 0x91
			MX8MP_IOMUXC_ENET_RXC__ENET_QOS_RX_ER 0x91
			MX8MP_IOMUXC_ENET_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x91
			MX8MP_IOMUXC_ENET_TD0__ENET_QOS_RGMII_TD0	0x12
			MX8MP_IOMUXC_ENET_TD1__ENET_QOS_RGMII_TD1	0x12
			MX8MP_IOMUXC_ENET_TD2__CCM_ENET_QOS_CLOCK_GENERATE_REF_CLK 0x12
			MX8MP_IOMUXC_ENET_TD3__GPIO1_IO18 0x1f
			MX8MP_IOMUXC_ENET_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x12
			MX8MP_IOMUXC_ENET_TXC__ENET_QOS_TX_ER 0x12
		>;
	};

 

0 Kudos
Reply

2,746 Views
domzippi
Contributor II

Hi @dh84,

thanks for your configuration.

My dts looks very similar and I was able to resolve the issue by changing the direction of the RMII ref clock. Using an external clock (generated by the PHY) and adding snps,rmii_refclk_ext fixed the problem (without changing the pin configuration) -> I opened a thread for my problem: https://community.nxp.com/t5/i-MX-Processors/i-MX8MP-EQOS-RMII-DMA-issue/m-p/1466744 .

Can you explain why you use this pinmux setting?:

 

MX8MP_IOMUXC_ENET_TD2__CCM_ENET_QOS_CLOCK_GENERATE_REF_CLK 	0x40000090

 

Where does the leading 0x4 come from? Isn't the control register only 32bit?

Have you ever tried using the RMII interface when generating the ref clock from the MAC?

My pinctrl:

  pinctrl_eqos: eqosgrp {
		fsl,pins = <
			MX8MP_IOMUXC_ENET_MDC__ENET_QOS_MDC		0x3
			MX8MP_IOMUXC_ENET_MDIO__ENET_QOS_MDIO		0x3
			MX8MP_IOMUXC_ENET_RD0__ENET_QOS_RGMII_RD0	0x91
			MX8MP_IOMUXC_ENET_RD1__ENET_QOS_RGMII_RD1	0x91
			MX8MP_IOMUXC_ENET_RD2__GPIO1_IO28 0x91
			MX8MP_IOMUXC_ENET_RD3__GPIO1_IO29 0x91
			MX8MP_IOMUXC_ENET_RXC__ENET_QOS_RX_ER 0x91
			MX8MP_IOMUXC_ENET_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x91
			MX8MP_IOMUXC_ENET_TD0__ENET_QOS_RGMII_TD0	0x12
			MX8MP_IOMUXC_ENET_TD1__ENET_QOS_RGMII_TD1	0x12
			MX8MP_IOMUXC_ENET_TD2__CCM_ENET_QOS_CLOCK_GENERATE_REF_CLK 0x12
			MX8MP_IOMUXC_ENET_TD3__GPIO1_IO18 0x1f
			MX8MP_IOMUXC_ENET_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x12
			MX8MP_IOMUXC_ENET_TXC__ENET_QOS_TX_ER 0x12
		>;
	};

 

0 Kudos
Reply