iMX6ULL ENET1 can receive packets but not transmit

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

iMX6ULL ENET1 can receive packets but not transmit

Jump to solution
1,186 Views
wisse-cp
Contributor I

Hello,

I'm using a Toradex Colibri iMX6ULL SoM and am having some issues with getting ethernet to work. The Toradex module has a Microchip KSZ8041 PHY on board, which is connected to ENET2 via RMII and MDIO and works without issues.

I'm attempting to connect a Microchip KSZ8463 switch to ENET1 via MII and SPI. So far I'm only able to receive data on the CPU and when attempting to transmit nothing shows up on the network and reading the switch statistics suggests it's just receiving garbage data from the CPU.

My device tree modifications are as follows:

&ecspi1 {
    status = "okay";

    ksz8463: ksz8463@0 {
        compatible = "microchip,ksz8463";
        reg = <0>;
        phy-mode = "mii";

        spi-max-frequency = <12000000>;
        status = "okay";

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

            port@0 {
                reg = <0>;
                label = "lan1";
            };

            port@1 {
                reg = <1>;
                label = "lan2";
            };

            port@3 {
                reg = <2>;
                label = "cpu";
                ethernet = <&fec1>;
                fixed-link {
                    speed = <100>;
                    full-duplex;
                };
            };
        };
    };

};

&fec1 {
    pinctrl-names = "default", "sleep";
    pinctrl-0 = <&pinctrl_enet1>;
    pinctrl-1 = <&pinctrl_enet1_sleep>;
    phy-mode = "mii";
    status = "okay";

    fixed-link {
        speed = <100>;
        full-duplex;
    };
};

pinctrl_enet1: enet1grp {
    fsl,pins = <
        MX6UL_PAD_UART2_RTS_B__ENET1_COL 0x1b0b0
        MX6UL_PAD_UART2_CTS_B__ENET1_CRS 0x1b0b0
        MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
        MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
        MX6UL_PAD_UART1_TX_DATA__ENET1_RDATA02 0x1b0b0
        MX6UL_PAD_UART1_RX_DATA__ENET1_RDATA03 0x1b0b0
        MX6UL_PAD_UART1_CTS_B__ENET1_RX_CLK 0x4b01b0a8
        MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
        MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x130b0
        MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
        MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
        MX6UL_PAD_UART2_TX_DATA__ENET1_TDATA02 0x1b0b0
        MX6UL_PAD_UART2_RX_DATA__ENET1_TDATA03 0x1b0b0
        MX6UL_PAD_ENET1_TX_CLK__ENET1_TX_CLK 0x4b01b0a8
        MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
        MX6UL_PAD_UART1_RTS_B__ENET1_TX_ER 0x1b0b0
    >;
};

When this didn't work, I changed the two fixed-link entries to 10mbit full-duplex and changed some registers in the KSZ8463 to switch to the same mode. As a result both the TX and RX clocks generated by the KSZ8463 went from 25MHz to 2.5MHz as expected, but transmitting still does not work while receiving works fine.

However, after doing this I noticed the following:

pastedImage_2.png

While you can see the TX_CLK has gone to 2.5MHz, somehow the data is being clocked at the original 25MHz while I think it's supposed to be clocked on the edge of the TX_CLK? My suspicion is that the same is happening at the original 100mbit and the data is being clocked out on the wrong clock somehow? The original umx6ull.dtsi does include some clock options but I'm not entirely sure what I should be overriding in this case:

fec1: ethernet@02188000 {
    compatible = "fsl,imx6ul-fec", "fsl,imx6q-fec";
    reg = <0x02188000 0x4000>;
    interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
                       <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&clks IMX6UL_CLK_ENET>,
                   <&clks IMX6UL_CLK_ENET_AHB>,
                   <&clks IMX6UL_CLK_ENET_PTP>,
                   <&clks IMX6UL_CLK_ENET_REF>,
                   <&clks IMX6UL_CLK_ENET_REF>;
    clock-names = "ipg", "ahb", "ptp",
                             "enet_clk_ref", "enet_out";
    stop-mode = <&gpr 0x10 3>;
    fsl,num-tx-queues=<1>;
    fsl,num-rx-queues=<1>;
    fsl,magic-packet;
    fsl,wakeup_irq = <0>;
    status = "disabled";
};

Please let me know if any additional information is required. Thanks.

Labels (1)
Tags (2)
0 Kudos
1 Solution
1,000 Views
wisse-cp
Contributor I

Hi Igor,

The problem turned out to be the iMX6ULL MAC generating it's own tx_clk signal, solved by changing the ENET1_TX_CLK_DIR and ENET1_CLK_ SEL bits in the GPR1 register.

View solution in original post

0 Kudos
2 Replies
1,000 Views
igorpadykov
NXP Employee
NXP Employee

Hi wisse-op

one can start with uboot and check if it is working in uboot

u-boot/colibri-imx6ull.c at master · ARM-software/u-boot · GitHub 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
1,001 Views
wisse-cp
Contributor I

Hi Igor,

The problem turned out to be the iMX6ULL MAC generating it's own tx_clk signal, solved by changing the ENET1_TX_CLK_DIR and ENET1_CLK_ SEL bits in the GPR1 register.

0 Kudos