RMII-MDIO fails with Linux 4.9.11 Kernel

[dougbailey]

I have a board based on the Freescale iMX6DL SabreSD design that I have working fine with the Korgoth based BSP that runs Linux 4.1.15. I am trying to upgrade the BSP running on the board to the Morty based BSP that runs Linux 4.9.11.

I have been able to port my device tree files to the new BSP and I have migrated my init files over to the systemd board initialization.

One problem I am having is that the Ethernet port does not operate under the new kernel. (The Ethernet port works flawlessly with the 4.1.15 kernel.)

The first issue I am trying to correct is the operation of the MDIO communicating with the Phy. The behavior is manifested with the use of the mii-tool utility. Sometimes when the board boots, mii-tool properly communicates and I am able to read the Phy registers. Other times, the tool fails and all that I read back from the Phy are 0xffff's. (mii-tool never fails running under the 4.1.15 kernel.)

The network interface on this board is different from the SabreSD board in that it is communicating to a 10/100 Micrel KSZ8081RNA Phy. It communicates via an RMII interface with the 50 MHz reference clock supplied by the PHY device. That reference clock is input on the GPIO_16 pin of the iMX6DL.

In my device tree file, I have the fast Ethernet controller defined as:

&fec {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_enet>;
    phy-mode = "rmii";
    phy-reset-gpios = <&gpio1 2 0>;
    fsl,magic-packet;
    status = "okay";
};

where the fec is also defined in the imx6qdl.dtsi device tree include is defined as:

fec: ethernet@02188000 {
    compatible = "fsl,imx6q-fec";
    reg = <0x02188000 0x4000>;
    interrupts-extended =
         <&gpc 0 118 IRQ_TYPE_LEVEL_HIGH>,
         <&gpc 0 119 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&clks IMX6QDL_CLK_ENET>,
         <&clks IMX6QDL_CLK_ENET>,
         <&clks IMX6QDL_CLK_ENET_REF>;
    clock-names = "ipg", "ahb", "ptp";
    stop-mode = <&gpr 0x34 27>;
    fsl,wakeup_irq = <0>;
    status = "disabled";
};

The IOMuxc pins for the Ethernet is defined as:
pinctrl_enet: enetgrp {
    fsl,pins = <
        MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
        MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
        MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
        MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
        MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
        MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x1b0b0
        MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
        MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
        MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
        MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x1b0b0
        MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
    >;
};

All of these device tree definitions are the same between the 4.1.15 and the 4.9.11 kernel.

I am at a loss for what is causing the mii-tool to fail sometimes and succeed at other times. Does anyone have suggestions where I should look to determine what has changed in the Ethernet interface?

Regards, 

Doug Bailey 

[Bio_TICFSL]

Hi Doug,

Was this from a packaged image or a Yocto build?

If it was a Yocto build chances are the networking in the Kernel configuration were not enabled.

[dougbailey]

The two images I am using are both built from NXP/Freescale distributed BSP's.  These BSP's are derivatives of the Yocto build system. 

In both instances, the network is configured in the kernel.  I have run menuconfig in both instances and made them match as much as possible.  

The fec_main driver is loading in the 4.9 kernel and is responding to MII MDIO transactions when the PHY comes out of reset correctly. 

[Bio_TICFSL]

Hi Doug,

This appears to be a regresion, please answer these question:

1.  Where does the reference clock come from ?  External OSC or SOC internal clock ?

2. Please measure the RMII reference clock to ensure it is 50Mhz.

3. Please ensure the pin setting: MX6QDL_PAD_GPIO_16__ENET_REF_CLK        0x4001b0a8

Regard

[dougbailey]

The problem turned out to be the ENET_CLK_SEL bit (bit 21) of the IOMUXc GPR1 register.  

My PHY generated the 50 MHz reference clock but I had not selected the fact that it would be driven into the iMX6 so I ended up with contention on the clock signal .  

I found that the code setting this bit is in arch/arm/mach-imx/mach-imx6q.c:

gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
if (!IS_ERR(gpr))
    regmap_update_bits(gpr, IOMUXC_GPR1,
        IMX6Q_GPR1_ENET_CLK_SEL_MASK,
        IMX6Q_GPR1_ENET_CLK_SEL_PAD);

Unfortunately, there is no way of setting this pin value in the device tree and requires a code change. 

Regards, 

Doug 

[florian_germain]

I have a castom board based on imx6sx-sdb board. We use KSZ8081RNA with 50Mhz like you.

Uboot works correctly after many changes.

When kernel is started, PHY is detected with right address but can't connect to PHY.

The correction above is the only modification apply to kernel sources ?

Florian

[dougbailey]

It turns out that the PHY I am using is booting at a PHY address that I am not expecting.  The Micrel/Microchip KSZ8081RNA PHY is supposed to boot at either PHY address 0 or 3.  In my instance, it is booting at address 4.  

I have talked with the MicroChip people to try to determine what is going on with the PHY.