Second ethernet interface only receives malformed packets on iMX6ULL

Technical Support
, , , ,
1

Hello,

I’m trying use the second ethernet interface on a iMX6ULL, however any packets that are sent appear to be lost, and packets that are received are dropped by the kernel, as indicated by ifconfig:

root@colibri-imx6ull:~# ifconfig eth1
eth1   Link encap:Ethernet HWaddr 00:14:2d:71:a4:b8
     inet6 addr: fe80::214:2dff:fe71:a4b8/64 Scope:Link
     UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
     RX packets:0 errors:1749 dropped:0 overruns:0 frame:1749
     TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
     collisions:0 txqueuelen:1000
     RX bytes:0 (0.0 B) TX bytes:7883 (7.6 KiB)

eth0 is the default interface provided by the KSZ8041 from the iMX6ULL module, and I’m attempting to connect a KSZ8463 via MII and SPI to eth1.

The device tree has the following additions:

&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;
        };
};

&iomuxc {
        imx6ull-eval-v3 {
                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     0x1b0b0
                                MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN      0x1b0b0
                                MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER      0x1b0b0
                                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    0x1b0b0
                                MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN      0x1b0b0
                                MX6UL_PAD_UART1_RTS_B__ENET1_TX_ER      0x1b0b0
                        >;
                };

                pinctrl_enet1_sleep: enet1sleepgrp {
                        fsl,pins = <
                                MX6UL_PAD_UART2_RTS_B__ENET1_COL        0x0
                                MX6UL_PAD_UART2_CTS_B__ENET1_CRS        0x0
                                MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x0
                                MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x0
                                MX6UL_PAD_UART1_TX_DATA__ENET1_RDATA02  0x0
                                MX6UL_PAD_UART1_RX_DATA__ENET1_RDATA03  0x0
                                MX6UL_PAD_UART1_CTS_B__ENET1_RX_CLK     0x0
                                MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN      0x0
                                MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER      0x0
                                MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x0
                                MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x0
                                MX6UL_PAD_UART2_TX_DATA__ENET1_TDATA02  0x0
                                MX6UL_PAD_UART2_RX_DATA__ENET1_TDATA03  0x0
                                MX6UL_PAD_ENET1_TX_CLK__ENET1_TX_CLK    0x0
                                MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN      0x0
                                MX6UL_PAD_UART1_RTS_B__ENET1_TX_ER      0x0
                        >;
                };
        };
};

The device is configured via SPI, and a virtual MDIO bus is created by the KSZ8463 driver, and that part is working fine and the chip can be configured.

2

HI @wisse-cp

Could you provide the software version of the module?

however any packets that are sent appear to be lost, and packets that are received are dropped by the kernel, as indicated by ifconfig:

Could you provide the dmesg log and the schematic of your connection of the second interface (you can post a comment with Visibility set to “Original Poster and Moderators”)?

How is your network set-up (router, switch, …)?

Thanks and best regards,
Jaski

17

Hi Max,

Those two bits were the solution. By disabling the ENET1 TX CLK output driver (bit 17) and enabling the external clk (bit 13) data is now succesfully transmitted.

As for the pad settings, I copied those from one of the EVK boards that uses MII but I’ve gone ahead and changed them as well.

Thank you!

18

Hi

Could you try to play with all 4 possible combinations of bit 13 and bit 17 of GPR1 (@ 0x20E4004). It is possible that these internal clock routing stuff overrides whatever your MII signals would command.
devmem2 is installed in our images, so you should be able to read and write to said register.

While looking through your device tree I noted that both TX_CLK and RX_CLK have a pad setting of 0x4b01b0a8. I guess that the first ‘b’ is there by accident and 0x4001b0a8 would be less confusing. Likely you could even omit the SION bit and have both at 0x1b0a8.

Max

19

Hi

Great that you found the root cause.

These bits are hard-coded in the kernel here. IMHO the macro names used are not well chosen if not plainly wrong.

I would hard-code whatever you require there.

Max

20

Hi,
we are designing a custom board using the Colibri iMX7D module. We want to add two additional ethernet ports with the same IP address. We have some experience with KSZ8463 on Cortex M7 platform, but not in linux enviroment.

Where did you find KSZ8463 drivers? There is no reference of KSZ8463 under /drivers/net/phy
/micrel.c.

21

HI @iel and Welcome to the Toradex Community!

Could you ask a new Question?
Thanks and best regards,
Jaski