Device Tree (.dts) configuration for eTSEC2 in SGMII/Serdes mode

[arashaz_]

Hello,

In a custom board based on P1020RDB, eTsec3 is set in SGMII mode, so beside eTSEC2, there are two Ethernet interfaces in SGMII mode and naturally eTSEC1 in RGMII mode.  Two interfaces are connected to a Gigabit SGMII/SERDES  4-port Ethernet switch on the board, and eTSEC1 to a Vitesse PHY. eTSEC1 works fine, but I could not find an appropriate configuration to be put in device tree (.dts) file for two other SGMII interfaces. When I use p1020rdb.dts which has at least eTSEC2 in SGMII mode, Linux does not detect any eth interface on eTSEC2 (it detects only one for eTSEC1).  I appreciate if you could advise me how the .dts file should be modified.

Note that a difference between P1020RDB configuration for eTSEC2 in SGMII board and our board is that in the former, eTSEC is connected to an SGMII PHY, but in our board to an SGMII/Serdes 4-port Ethernet switch. I am not sure if a driver should be installed for the Ethernet switch.

Thank you for your support.

[lunminliang]

See below technical support comment:

If the device tree specifies a PHY connected to the MAC, Linux attempts to find, read and initialize it.  If the PHY does not respond, Linux  shuts the interface down. All Freescale reference boards carry PHYs  at their SGMII interfaces,  therefore SDK default device trees are not good if another MAC is directly connected to the processor SGMII. In the case of a zero-PHY connection,  the following changes to the corresponding  MAC node should be done:

1. Remove the reference to the PHY.

2.  Remove the PHY node itself.

3.  Keep the reference to the TBI node  intact.

4.  Add the property "fixed-link". See ./Documentation/devicetree/dts-        bindings/fsl/tsec.txt for details.

As of the driver for the switch, it is a third party device for which Freescale neither provides, nor maintains any driver.  Our suggestion in this regard is to  consult at the switch manufacturer  for any driver requirement/availability as well as for related device tree bindings.

[arashaz_]

  Dear Lunmin,

Thank you very much for your comment. I followed your comment (as you can find it attached) and now I have both eth0 and eth1 in Linux. Eth0 works well as before, but by eth1, there is no incoming data. I am not sure if it is the problem of the hardware to which the eTSEC2 is connected, or the problem of my configuration for eTSEC2 because sometimes the device is known in Linux, but because something is wrong in the naming or configuration, the interface does not work. I appreciate if you kindly advise me:

• Have a look at the file and verify if the configuration for eTSEC2 is correct
• Linux reports that eTSEC2 has a link (link detected). Is it because of our fixed link definition or it really detected a link? In other words, if I define a fixed link, but the switch (to which the eTSEC is connected) is off, does it still report “link detected”? Note that I have no mean to turn the switch off to test. 
• Finally, as I explained, eTSEC3 is also in sgmii mode exactly the same as eTSEC2. To define it in .dts, is it enough to define 

  mdio@26000 {

• #address-cells = <1>;
• #size-cells = <0>;
• compatible = "fsl,etsec2-tbi";
• reg = <0x26000 0x1000 0xb1030 0x4>;
• tbi0: tbi-phy@11 {
• reg = <0x11>;
• device_type = "tbi-phy";
• };
• };

and enet0: ethernet@B2000  or the name of tbi0 and its register value 0x11 have to be chaged?

Thank you in advance.

Arash

	mdio@24000 {
		#address-cells = <1>;
		#size-cells = <0>;
		compatible = "fsl,etsec2-mdio";
		reg = <0x24000 0x1000 0xb0030 0x4>;

		phy0: ethernet-phy@0 {
			interrupt-parent = <&mpic>;
			interrupts = <3 1>;
			reg = <0x1>;
		};

};

	mdio@25000 {
		#address-cells = <1>;
		#size-cells = <0>;
		compatible = "fsl,etsec2-tbi";
		reg = <0x25000 0x1000 0xb1030 0x4>;
		tbi0: tbi-phy@11 {
			reg = <0x11>;
			device_type = "tbi-phy";
		};
	};

	enet1: ethernet@B0000 {
		#address-cells = <1>;
		#size-cells = <1>;
		cell-index = <0>;
		device_type = "network";
		model = "eTSEC";
		compatible = "fsl,etsec2";
		fsl,num_rx_queues = <0x8>;
		fsl,num_tx_queues = <0x8>;
		local-mac-address = [ 00 00 00 00 00 00 ];
		interrupt-parent = <&mpic>;
		phy-handle = <&phy0>;
		phy-connection-type = "rgmii-id";
		queue-group@0{
			#address-cells = <1>;
			#size-cells = <1>;
			reg = <0xB0000 0x1000>;
			fsl,rx-err-int-map = <0xAA>;
			fsl,tx-int-map = <0xAA>;
			interrupts = <29 2 30 2 34 2>;
		};
		queue-group@1{
			#address-cells = <1>;
			#size-cells = <1>;
			reg = <0xB4000 0x1000>;
			fsl,rx-err-int-map = <0x55>;
			fsl,tx-int-map = <0x55>;
			interrupts = <17 2 18 2 24 2>;
		};
	};

	enet0: ethernet@B1000 {
		#address-cells = <1>;
		#size-cells = <1>;
		cell-index = <0>;
		device_type = "network";
		model = "eTSEC";
		compatible = "fsl,etsec2";
		fsl,num_rx_queues = <0x8>;
		fsl,num_tx_queues = <0x8>;
		local-mac-address = [ 00 00 00 00 00 00 ];
		interrupt-parent = <&mpic>;
			fixed-link = <1 1 1000 0 0>;
		tbi-handle = <&tbi0>;
		phy-connection-type = "sgmii";
		queue-group@0{
			#address-cells = <1>;
			#size-cells = <1>;
			reg = <0xB1000 0x1000>;
			fsl,rx-err-int-map = <0xAA>;
			fsl,tx-int-map = <0xAA>;
			interrupts = <35 2 36 2 40 2>;
		};
		queue-group@1{
			#address-cells = <1>;
			#size-cells = <1>;
			reg = <0xB5000 0x1000>;
			fsl,rx-err-int-map = <0x55>;
			fsl,tx-int-map = <0x55>;
			interrupts = <51 2 52 2 67 2>;
		};
	};

[lunminliang]

Have a look at the file and verify if the configuration for eTSEC2 is correct

->Looks correct, more or less.

Linux reports that eTSEC2 has a link (link detected). Is it because of our fixed link definition or it really detected a link?

->It is not always possible to detect a fixed link because there is no PHY that would report the status. Linux does not do any specific check for this kind of links.

In other words, if I define a fixed link, but the switch (to which the eTSEC is connected) is off, does it still report “link detected”?

->Yes, but in the spcific case of SGMII, where two PCS are sitting in between, it is possible. Check the TBI SR register to see if the TBI has detected a link. More details can be found in AN3869.

Finally, as I explained, eTSEC3 is also in sgmii mode exactly the same as eTSEC2. To define it in .dts, is it enough to define ...

...and enet0: ethernet@B2000 or the name name of tbi0 and its register value 0x11 have to be changed?

->There shall be no duplicated lables like tbi0: or enet0:. Refer to the SDK default device tree definnitions for your chip for the proper eTSEC3 node and apply the modifications described in the initial response. Equal values of the "reg" property are valid because the addressed entities sit on independent buses.

[arashaz_]

Hi,

Thank you very much.