QorIQ T1042 networking issues

[obiokafor]

We have a custom QorIQ T1042 board using SERDES protocl 0xA7. DTSEC1 and DTSEC2 are configured as 2.5G SGMII and are directly connected to an external switch which supports 2.5G SGMII, there are no PHYs attached, this is a direct connection. DTSEC4 is 1G RGMII using a Marvell PHY.

Firstly I cannot seem to correctly configure the SGMII ports. In the u-boot board eth.c file, I set DTSEC3 and DTSEC5 to disabled as they are unused. If we do not set PHY addresses for DTSEC1/2 (effectively the PHY addresses are 0) then even the RGMII port stops working. If I set PHY addresses for DTSEC1/2 then the RGMII port works but of course I get errors for DTSEC1/2 saying that we are unable to connect to the PHY. How do I correctly configure DTSEC1/2 in u-boot?

Secondly, if if change the device tree such that DTSEC1/2 use a fixed link I get and error in u-boot from the fixed PHY driver which appears to be because the fixed PHY driver does not support 2.5G speed. Is there a way for Linux to support 2.5G SGMII without an attached PHY?

Thirdly, when the RGMII port is working I am able to connect to the network in u-boot, update u-boot over Ethernet and also configure and run NFS boot. After the kernel comes up, NFS initially works fine. udev then tries to rename the interface from eth2 to fm1-gb3 and an error is printed because the device is in use. After this, NFS and stops working and I get errors saying that the server is not responding. This happens even if I comment out the line that tries to rename the interface. Can you provide any insight into why this is happening?

Regards

Obi

[yipingwang]

Hello Obi,

It seems that your design is similar as T1040RDB, please refer the following, so you could follow u-boot and dts configuration for T1040RDB.

u-boot configuration:

Please refer to drivers/net/fm/t1040.c,

        case FM1_DTSEC1:
        case FM1_DTSEC2:
                if (is_serdes_configured(QSGMII_SW1_A + port - FM1_DTSEC1) ||
                    is_serdes_configured(SGMII_SW1_MAC1  + port - FM1_DTSEC1))
                        return PHY_INTERFACE_MODE_QSGMII;

Please refer to board/freescale/t104xrdb/eth.c:

        /* Connect DTSEC1 to L2 switch if it doesn't have a PHY */
        if (serdes_get_first_lane(FSL_SRDS_1, SGMII_FM1_DTSEC1) < 0)
                vsc9953_port_enable(8);

        /* Connect DTSEC2 to L2 switch if it doesn't have a PHY */
        if (serdes_get_first_lane(FSL_SRDS_1, SGMII_FM1_DTSEC2) < 0) {
                /* Enable L2 On MAC2 using SCFG */
                struct ccsr_scfg *scfg = (struct ccsr_scfg *)
                                CONFIG_SYS_MPC85xx_SCFG;

                out_be32(&scfg->esgmiiselcr, in_be32(&scfg->esgmiiselcr) |
                         (0x80000000));
                vsc9953_port_enable(9);
        }

Please refer to include/configs/T104xRDB.h:

#if defined(CONFIG_T1040RDB) || defined(CONFIG_T1040D4RDB)
#define CONFIG_VSC9953
#define CONFIG_CMD_ETHSW
#ifdef CONFIG_T1040RDB
#define CONFIG_SYS_FM1_QSGMII11_PHY_ADDR        0x04
#define CONFIG_SYS_FM1_QSGMII21_PHY_ADDR        0x08

For Linux dts configuration, please refer to the following.

Please refer to arch/powerpc/boot/dts/fsl/t1040d4rdb.dts
        soc: soc@ffe000000 {
                fman0: fman@400000 {
                        rcpm-wakeup = <&rcpm 0x00000008>;

                        enet0: ethernet@e0000 {
                                fixed-link = <0 1 1000 0 0>;
                                phy-connection-type = "sgmii";
                                rcpm-wakeup = <&rcpm 0x80000000>;
                        };

                        enet1: ethernet@e2000 {
                                fixed-link = <1 1 1000 0 0>;
                                phy-connection-type = "sgmii";
                                rcpm-wakeup = <&rcpm 0x40000000>;
                        };

                     ... ...

Please refer to arch/powerpc/boot/dts/fsl/t1040si-post.dtsi

       l2switch@800000 {

                ... ...

                port@180000 {
                        fixed-link = <2 1 2500 0 0>;
                        phy-connection-type = "sgmii";
                };
                port@190000 {
                        fixed-link = <3 1 2500 0 0>;
                        phy-connection-type = "sgmii";
                }; 

                 ... ...

      }

For RGMII port problem, I am not sure whether it is caused by hardware or environment configuration, would you please check the status with "ethtool fm1-gb3"? Please check whether it is possible to ping other networking device from fm1-gb3?

Have a great day,
TIC

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

[obiokafor]

Thanks for your reply.

The RGMII issues turned out to be a variant of this thread, T1042 Device Tree Fman RGMII-ID. The Marvell 88E151x PHY does support internal Tx and Rx delays, but because the PHY type in Linux is RGMII and not RGMII-ID the delays are removed even though they had previously been set by u-boot. My quick solution was to modify the Linux driver so that it sets the delays for both RGMII and RGMII-ID. The optimal solution is probably to ensure CONFIG_OF_MDIO is enabled in the kernel and use the and use 'compatible' and 'marvell,reg-init' properties of the ethernet-phy in the deice tree to set the appropriate register.

Note that the u-boot driver for the Marvell 88E1510/88E1518 PHYs is broken. The function m88e1111s_config() is ultimately invoked and it does not set the appropriate registers, it does not even select the correct page. The driver only works because the default settings after a hard reset have both Tx and Rx delays enabled. This bug is still present on mainline u-boot.

With regards to DTSEC1/2, we are using the T1022 so there is no internal Ethernet switch. With SERDES protocol 0xA7, the DTSECs are:

DTSEC1 - SGMII 2.5G

DTSEC2 - SGMII 2.5G

DTSEC3 - SGMII

DTSEC4 - RGMII

DTSEC5 - SGMII

As such, drivers/net/fm/t1040.c need to return PHY_INTERFACE_MODE_SGMII_2500 to ensure that drivers/net/fm/t1040.c() in drivers/net/fm/eth.c configures the SERDES correctly as per section 31.6.1 of the reference manual.

I am not yet at a stage where I can verify the SGMII ports in Linux but the device tree suggestions you made look ok.

Thanks

Obi