SERDES Bank 2 Protocol 9 + EC1 RGMII

NXP LX2160
1

I’ve built an image using lx2160a_build with a SERDES 8_9_2 configuration. This makes SD2 8 lanes of SGMII (1Gbps Ethernet). I don’t need all 8 lanes but need to configure Lanes 4,5,6,7 as SGMII 15,16,13 and 14 while retaining use of the RGMII interface (EC1). Both EC1 (RGMII) interface and SGMII.17 use the dpmac.17 resource but that should be OK because I don’t need to use SGMII.17.

Firstly, I’ve changed the RCW configuration by removing EC1_PMUX=1 from the lx2160a_SD2_9.rcwi RCW include. This change retains the EC1_PMUX setting as WRIOP MAC17 (RGMII). With this change, I can bring up the interface in Linux, if (and only if) the DPC mac configuration is set to fixed link:

mac@17 {
    link_type = "MAC_LINK_TYPE_FIXED";
};

The problem with setting fixed link is that the link state is no longer reflected by the interface and the link is always assumed to be up. Attempting to configure a PHY using link_type = “MAC_LINK_TYPE_PHY” results in the following dmesg error:

[ 5.294119] fsl_dpaa2_eth dpni.0 (unnamed net_device) (uninitialized): incorrect link mode rgmii for in-band status

Examining the device tree from the booted system gives the following clue:

# dtc -I fs -O dts /proc/device-tree 
                                ethernet@11 {
                                        compatible = "fsl,qoriq-mc-dpmac";
                                        pcs-handle = <0x50>;
                                        managed = "in-band-status";
                                        phys = <0x52>;
                                        reg = <0x11>;
                                        phandle = <0xdb>;
                                        sfp = <0x51>;
                                };

Whereas the original device tree for a build with working RGMII interface looks like this:

                                ethernet@11 {
                                        compatible = "fsl,qoriq-mc-dpmac";
                                        reg = <0x11>;
                                        pcs-handle = <0x3c>;
                                        phy-handle = <0x3d>;
                                        phy-connection-type = "rgmii-id";
                                        phandle = <0xab>;
                                };

This change in device tree seems to be originating from build/linux/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts.

&dpmac17 {
    /delete-property/ phy-handle;
    /delete-property/ phy-connection-type;
    sfp = <&c1_bb_sfp>;
    managed = "in-band-status";
    phys = <&serdes2_lane_c>;
};

I have also noticed that the u-boot environment has been configured to load the fsl-lx2160a-half-twins.dtb fdtfile rather than the usual setting of fdtfile=fsl-lx2160a-clearfog-cx.dtb

At this stage, it would be good to understand what “half twins” is exactly. Is this a different board being developed? Is it intended to be compatible with the LX2160A COM / Clearfog? Some of the changes brought in by the fsl-lx2160a-half-twins.dts do seem appropriate to what I’m trying to do (reconfigure some of the SD2 lanes as SGMII) on the LX2160 COM.

If “half twins” is intended to be compatible with ClearFog then would patching build/linux/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts be the appropriate method for enabling the EC1 / RGMII interface when SD2 is configured for SGMII?

2

half-twins is indeed a different carrier for the LX2160a COM, with all SFP ports.
SFP ports need the “in-band-status” to operate …

So what is happening is - U-Boot uses the serdes configuration to derive the name of fdtfile to load during boot. Because you are specifically using the 8_9_2 config, you now get the halftwins dtb by default.

The easiest way to deal with this is probably for you to change the fsl-lx2160a-half-twins.dts file in linux source code.

Alternatively you could patch u-boot (board/solidrun/lx2160a/eth_lx2160acex7.c:fsl_board_late_init) to set a different name to the fdtfile variable.

1 Like