i.MX8QXP RMII + 4.19.35 NXP Kernel Not Working

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

i.MX8QXP RMII + 4.19.35 NXP Kernel Not Working

Jump to solution
3,261 Views
mosaddek_hossai
Contributor III

Dear NXP Community,

i.MX8QXP fec is not responding. There is a link-up with KSZ micrel phy. The MDIO bus is working but the Fec is not responding. The TXEN line is always low. 

Is the 4.19.35 kernel FEC driver for rmii for i.MX8QXP working? The ref-clk is there but the FEC is not transmitting no data.

 

There is a fixup made for fec driver for RGMII in kernel 4.19.35 [fec_fixup.c] does that mean that kernel 4.19.35 only compatible for RGMII. 

/*fec_fixup.c*/

static int ar8031_phy_fixup(struct phy_device *dev)
{
u16 val;

/* Set RGMII IO voltage to 1.8V */
phy_write(dev, 0x1d, 0x1f);
phy_write(dev, 0x1e, 0x8);

/* Disable phy AR8031 SmartEEE function */
phy_write(dev, 0xd, 0x3);
phy_write(dev, 0xe, 0x805d);
phy_write(dev, 0xd, 0x4003);
val = phy_read(dev, 0xe);
val &= ~(0x1 << 8);
phy_write(dev, 0xe, val);

/* Introduce tx clock delay */
phy_write(dev, 0x1d, 0x5);
phy_write(dev, 0x1e, 0x100);

return 0;
}

As rmii IO requires 3.3 V, does that mean a kernel patch is required for RMII or is the fec_main.c is sufficient for RMII in FEC configuration.

@igorpadykov

@joanxie 

Thanking in advance. Hoping to hear from the community soon.

Kind Regards,
Hossain

0 Kudos
1 Solution
3,145 Views
mosaddek_hossai
Contributor III

Dear NXP Community,

Example device Tree for RMII https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dts/freescale/fsl-imx8qxp-... will not work for 4.19.35 kernel. 

For Ethernet for RMII to work in Linux with 50mHz ref clock out, a patch is needed as the clock parent function for SC_P_ENET0_RGMII_TXC_CONN_ENET0_RCLK50M_OUT is NULL. So the fec driver reads zero. Second and very important point is setting the magic registers for 3.3 V mode. 

SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB0_PAD 0x000014a0 /* Use pads in 3.3V mode */
SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB1_PAD 0x000014a0 /* Use pads in 3.3V mode */

Finally both in U-boot and Linux RMII ethernet is working. 

 

View solution in original post

8 Replies
3,146 Views
mosaddek_hossai
Contributor III

Dear NXP Community,

Example device Tree for RMII https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dts/freescale/fsl-imx8qxp-... will not work for 4.19.35 kernel. 

For Ethernet for RMII to work in Linux with 50mHz ref clock out, a patch is needed as the clock parent function for SC_P_ENET0_RGMII_TXC_CONN_ENET0_RCLK50M_OUT is NULL. So the fec driver reads zero. Second and very important point is setting the magic registers for 3.3 V mode. 

SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB0_PAD 0x000014a0 /* Use pads in 3.3V mode */
SC_P_COMP_CTL_GPIO_1V8_3V3_ENET_ENETB1_PAD 0x000014a0 /* Use pads in 3.3V mode */

Finally both in U-boot and Linux RMII ethernet is working. 

 

2,992 Views
rob_mclean
Contributor IV

You mentioned a patch to the kernel is needed for this to work, but you didn't go into detail about it.

Can you share a reference to that kernel patch to fix the SC_P_ENET0_RGMII_TXC_CONN_ENET0_RCLK50M_OUT clock parent?

0 Kudos
2,984 Views
rob_mclean
Contributor IV

I've been adding some debug statements to my kernel drivers to figure out what that patch might be, and it looks like the "enet_clk_ref" clock in the fec driver is set to 0MHz when the device tree sets it to be "IMX8QXP_ENET0_REF_50MHZ_CLK".

At this point I'm going to see what clock that references, and how I can get that clock to be the "enet_clk_ref".

I assume my finding that the reference clock inside the FEC is 0MHz is what you meant when you said: 

a patch is needed as the clock parent function for SC_P_ENET0_RGMII_TXC_CONN_ENET0_RCLK50M_OUT is NULL.

 

0 Kudos
2,977 Views
rob_mclean
Contributor IV

After some more digging I think I found the problem you mentioned.  In my linux kernel source code tree I have this file:  <kernel root directory>/drivers/clk/imx/clk-imx8qxp.c

In that file, I find this line:

 clks[IMX8QXP_ENET0_REF_50MHZ_CLK] = imx_clk_gate3_scu("enet0_ref_50_clk", NULL, SC_R_ENET_0, SC_C_DISABLE_50, true);

I think the patch you mentioned replaces that "NULL" with something that better identifies the parent clock source.

@mosaddek_hossai Can you please share a patch (or just some code, or some hints) to help me solve this issue?

0 Kudos
2,907 Views
rob_mclean
Contributor IV

We were able to fix our problem without a kernel patch. Our kernel is a 4.14.181 with some modified and backported drivers, so maybe our problem wasn't the same as the one described in this posting after all.

See this posting for further details:i.MX8QXP RMII Ethernet Phy issues 

0 Kudos
3,247 Views
igorpadykov
NXP Employee
NXP Employee

Hi Hossain

 

for rmii one can use fsl-imx8mm-ddr3l-val.dts :

https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dts/freescale/fsl-imx8mm-d...

 

>As rmii IO requires 3.3 V, does that mean a kernel patch is required for RMII

>or is the fec_main.c is sufficient for RMII in FEC configuration.

 

fec_main.c is sufficient.

 

 

Best regards
igor

0 Kudos
3,206 Views
mosaddek_hossai
Contributor III

Hello Igor,

Thanks a lot for your reply.

The device is similar to what you have provided. I have used reference of Mek board TJA1100 device tree.

My device tree is stated below:

/*Pin Mux*/

pinctrl_fec1: fec1grp {
fsl,pins = <
SC_P_ENET0_MDC_CONN_ENET0_MDC 0x06000020
SC_P_ENET0_MDIO_CONN_ENET0_MDIO 0x06000020
SC_P_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL 0x00000061 
SC_P_ENET0_RGMII_TXC_CONN_ENET0_RCLK50M_OUT 0x00000061
SC_P_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD0 0x00000061
SC_P_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD1 0x00000061
SC_P_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL 0x00000061 /*broad cast*/
SC_P_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD0 0x00000061 /*full-duplex =0 */
SC_P_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD1 0x00000021 /*phy add-2=1*/
SC_P_ENET0_RGMII_RXD2_CONN_ENET0_RMII_RX_ER 0x00000061
SC_P_ENET0_RGMII_RXD3_LSIO_GPIO5_IO08 0x00000061 /*sig detect*/
SC_P_ENET0_RGMII_TXD2_LSIO_GPIO5_IO01 0x00000061 /*reset pin*/
SC_P_ENET0_RGMII_RXC_LSIO_GPIO5_IO03 0x00000061 /*interrupt*/

>;
};

/* Ethernet */
&fec1 {
pinctrl-names = "default";
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 = <&ethphy0>;
fsl,magic-packet;
/delete-property/ phy-supply;
local-mac-address = [d2 85 d0 f2 26 47];
status = "okay";

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

ethphy0: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;

reset-gpios = <&gpio5 1 GPIO_ACTIVE_LOW>;
reset-assert-us = <10000>;
reset-deassert-us = <20000>;
max-speed = <100>;
};
};
};

 

If device tree is correct and the fec driver is also correct, why is the TXEN pin not getting high. Why TX and RX in Fec not responding?

From phy it is also receiving data from Host laptop. Rx line is working, but no response from Fec to tcmpdump or ethtool -S eth0 shows zero data in both Tx and Rx.

Hoping to hear from you soon.

Thanks in advance.

 

Kind Regards,

Hossain

0 Kudos
3,199 Views
igorpadykov
NXP Employee
NXP Employee

Hi Hossain

 

sorry I provided wrong dts example, correct is fsl-imx8qxp-enet2-tja1100.dtsi

https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm64/boot/dts/freescale/fsl-imx8qxp-...

 

&fec2 {
	pinctrl-0 = <&pinctrl_fec2_rmii>;
	clocks = <&clk IMX8QXP_ENET1_IPG_CLK>,
		 <&clk IMX8QXP_ENET1_AHB_CLK>,
		 <&clk IMX8QXP_ENET1_REF_50MHZ_CLK>,
		 <&clk IMX8QXP_ENET1_PTP_CLK>,
		 <&clk IMX8QXP_ENET1_TX_CLK>;
	phy-mode = "rmii";
	phy-handle = <&ethphy2>;
	/delete-property/ phy-supply;

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

		ethphy2: ethernet-phy@5 {
			compatible = "ethernet-phy-ieee802.3-c22";
			reg = <5>;
			tja110x,refclk_in;
		};
	};
};

&iomuxc {
	imx8qxp-mek {
		pinctrl_fec2_rmii: fec2rmiigrp {
			fsl,pins = <
				SC_P_ENET0_MDC_CONN_ENET1_MDC			0x06000020
				SC_P_ENET0_MDIO_CONN_ENET1_MDIO			0x06000020
				SC_P_ESAI0_FSR_CONN_ENET1_RCLK50M_OUT		0x06000020
				SC_P_SPDIF0_RX_CONN_ENET1_RGMII_RXD0            0x06000020
				SC_P_ESAI0_TX3_RX2_CONN_ENET1_RGMII_RXD1        0x06000020
				SC_P_ESAI0_TX2_RX3_CONN_ENET1_RMII_RX_ER        0x06000020
				SC_P_SPDIF0_TX_CONN_ENET1_RGMII_RX_CTL          0x06000020
				SC_P_ESAI0_TX4_RX1_CONN_ENET1_RGMII_TXD0        0x06000020
				SC_P_ESAI0_TX5_RX0_CONN_ENET1_RGMII_TXD1        0x06000020
				SC_P_ESAI0_SCKR_CONN_ENET1_RGMII_TX_CTL         0x06000020
			>;

 

additionally one can try to test it in uboot, use ENET1 :

https://source.codeaurora.org/external/imx/uboot-imx/tree/include/configs/imx8qxp_arm2.h?h=imx_v2019...

https://source.codeaurora.org/external/imx/uboot-imx/tree/board/freescale/imx8qxp_arm2/imx8qxp_arm2....

 

Best regards
igor

0 Kudos