• State
  • Replies 1 reply
  • Subscribers 34 subscribers
  • Views 60 views
  • Users 0 members are here
Support feedback
Options
Options
Related

DP83867E: Implementing fixed-link RGMII for DP83867 and TDA4VM

Béla Schmidt
Prodigy 10 points

Part Number: DP83867E
Other Parts Discussed in Thread: TDA4VM

Hi everyone,

i'm working on implementing RGMII1 of the CPSW9G switch using custom hardware and a Beaglebone AI64. The custom hardware uses a DP83867 phy, just like BB-AI64 itself. The device is running a device specific Debian Trixie image, which contains the TI-Device tree.

My initial idea was to setup the port via fixed-link, as the MDIO0 pins are not available via GPIO expansion headers. For reference I used this TI overlay. I modified k3-j721e-beagleboneai64.dts and k3-j721e-main.dtsi as seen in the provided snippets. I have only provided my changes in the two files and omitted everything kept standard.

The phy strap pins are kept at default values, except for its address pins.

Behaviour with this approach:

  • Linux correctly identifies new interface and allows configuring
  • Link is discovered by connected pc (auto negotiation works as intended)
  • No dmesg errors regarding RGMII
  • Ping in both directions fails with checksum errors (identified with ethtool)

Other troubleshooting steps:

  • Reducing speed to fast ethernet
  • Using half-duplex
  • Using all available phy-modes
  • Exported active DT to confirm that modifications are loaded

k3-j721e-main.dtsi

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

			cpsw0_port1: port@1 {
				status = "okay";
				reg = <1>;
				label = "port01";
				phys = <&cpsw0_phy_gmii_sel 1>;
				phy-mode = "rgmii-rxid";

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

k3-j721e-beagleboneai64.dts

	rgmii1_pins_default: rgmii1-default-pins {
		pinctrl-single,pins = <
			J721E_IOPAD(0x4, PIN_INPUT, 4) /* (AC23) PRG1_PRU0_GPO0.RGMII1_RD0 */
			J721E_IOPAD(0x8, PIN_INPUT, 4) /* (AG22) PRG1_PRU0_GPO1.RGMII1_RD1 */
			J721E_IOPAD(0xc, PIN_INPUT, 4) /* (AF22) PRG1_PRU0_GPO2.RGMII1_RD2 */
			J721E_IOPAD(0x10, PIN_INPUT, 4) /* (AJ23) PRG1_PRU0_GPO3.RGMII1_RD3 */
			J721E_IOPAD(0x1c, PIN_INPUT, 4) /* (AD22) PRG1_PRU0_GPO6.RGMII1_RXC */
			J721E_IOPAD(0x14, PIN_INPUT, 4) /* (AH23) PRG1_PRU0_GPO4.RGMII1_RX_CTL */
			J721E_IOPAD(0x30, PIN_OUTPUT, 4) /* (AF24) PRG1_PRU0_GPO11.RGMII1_TD0 */
			J721E_IOPAD(0x34, PIN_OUTPUT, 4) /* (AJ24) PRG1_PRU0_GPO12.RGMII1_TD1 */
			J721E_IOPAD(0x38, PIN_OUTPUT, 4) /* (AG24) PRG1_PRU0_GPO13.RGMII1_TD2 */
			J721E_IOPAD(0x3c, PIN_OUTPUT, 4) /* (AD24) PRG1_PRU0_GPO14.RGMII1_TD3 */
			J721E_IOPAD(0x44, PIN_OUTPUT, 4) /* (AE24) PRG1_PRU0_GPO16.RGMII1_TXC */
			J721E_IOPAD(0x40, PIN_OUTPUT, 4) /* (AC24) PRG1_PRU0_GPO15.RGMII1_TX_CTL */
		>;
	};

&cpsw0 {
	pinctrl-names = "default";
	pinctrl-0 = <&rgmii1_pins_default>;
};

Alternativ using MDIO:

I also tried using MDIO to test different rx/tx delays. But this required soldering wires to V26 and V24 of TDA4VM and the phy was not discoverable over MDIO. With an oscilloscope I could measure traffic from the BB on the MDIO, without an answer from the phy. I’d like to remain using fixed-link, as I don’t have a need for configuring the phy and want to prevent further modifications to the hardware.

Does anyone have experience with the fixed-link ethernet approach? If more details are necessary for troubleshooting, let me know.

  • 0
    TI__Mastermind 38295 points

    Hi Bela,

    By 'fixed link' you are referring to using the PHY without register access correct? This is certainly possible to do even if RGMII delays are needed. A link up with ping failure does point towards the RGMII being the issue, and without register access our options for debugging will be limited. Here is what I can think of for next steps:

    1. Try running a unidirectional iperf (or similar) test to see if data can flow in either direction without errors. Ping will test both the TX and RX path of the PHY, so if we can isolate the TX and RX into separate tests we can see if one or the other is causing the problem.

    2. GPIO_0, GPIO_1, LED_2, and LED_1 are strap options to shift the RX and TX clock delays for RGMII. Can you try different strap settings on these pins within your design and see if the error rate gets better? The settings for these straps can be found in the DP83867 datasheet.

    3. It would be good to probe the RGMII lines to ensure data, clock, and CTRL signals are reaching the MAC from the PHY, and also reaching the PHY from the MAC.

    If these do not give us clues, we may need to get register access working to debug further. If you're able to solder wires to MDC/MDIO/GND you can use an MSP430 launchpad to act as a MDIO controller. This is described in our USB2MDIO user's guide.

    Best,

    Shane