RGMII PHY connection doesn't come up 1000Mbps only 100Mbps

[tzsolt]

I use a STM32MP157C and connected to MAX24287 PHY by RGMII.

After linux booted there is only 100Mbps connection - I put the PHY into Diagnostic Loopback Mode and the situation is the same.

My dts:

&ethernet0{

pinctrl-names = "default", "sleep";

pinctrl-0 = <&eth1_pins_mx>;

pinctrl-1 = <&eth1_sleep_pins_mx>;

status = "okay";

/* USER CODE BEGIN ethernet0 */

phy-mode = "rgmii-id";

max-speed = <1000>;

phy-handle = <&phy0>;

 mdio0 {

#address-cells = <1>;

#size-cells = <0>;

compatible = "snps,dwmac-mdio";

reset-gpios = <&gpioa 4 GPIO_ACTIVE_LOW>;

reset-delay-us = <10000>;

post-reset-delay-us = <1000>;

phy0: ethernet-phy@3 {

    reg = <3>;

sfp;

/* compatible = "ethernet-phy-ieee802.3-c22"; */

/* interrupt-parent = <&gpioa>; */

/* interrupts = <9 IRQ_TYPE_EDGE_FALLING>; */

};

};

/* USER CODE END ethernet0 */

};

The PHY has 25MHz external clock, it gives 125MHz RX_CLK clock to the MAC, and the MAC would have give 125MHz TX_CLK (as GTX_CLK) to the PHY.

But with auto-negotiation the output on TX_CLK is only 25Mhz as 100Mbps.

This readable in the MAC registers:

devmem 0x50000A10 w 0x10800

devmem 0x50020004

0x00200000

devmem 0x500008FC

0x00000000

devmem 0x50000218

0x01004701

devmem 0x5800a000

0x0807E203

here ought to be 0x08072203 but the mac_speed_o[1] bit is "0" after negotiation.

Operating mode configuration register (ETH_MACCR)

Address offset: 0x0000

Reset value: 0x0000 8000

Bit 15 PS: Port Select

This bit selects the Ethernet line speed.

0: For 1000 Mbps operations

1: For 10 or 100 Mbps operations

In 10 or 100 Mbps operations, this bit, along with Bit 14, selects the exact line speed. In the

10/100 Mbps-only (always 1) or 1000 Mbps-only (always 0) configurations, this bit is readonly (RO) with appropriate value. In default 10/100/1000 Mbps configurations, this bit is readwrite (rw). The mac_speed_o[1] signal reflects the value of this bit.

Debug result from MAC registers:

 

What could be the bad settings?

I could not have any idea more.

Thank you.

[tzsolt]

Meanwhile yesterday I set the connection in the device tree for:

fixed-link {

speed = <1000>;

full-duplex;

pause;

};

and now there is 1Gbps link BUT the data transfer doesn't work:

[    5.789269] stm32-dwmac 5800a000.ethernet eth0: No Safety Features support found

[    5.796938] stm32-dwmac 5800a000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported

[    5.805903] stm32-dwmac 5800a000.ethernet eth0: registered PTP clock

[    5.813544] stm32-dwmac 5800a000.ethernet eth0: configuring for fixed/rgmii link mode

[    5.820435] stm32-dwmac 5800a000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

the ping command doesn't work either!

***************************************************************************************************************

Maybe could it be the cause of the not working auto-negotiation:

"does not report in-band status for link state, clock speed and duplexduring normal inter-frame" - I read in the MAX24287 (PHY) datasheet...?

Regards: Zsolt

[tzsolt]

It is important that it is an SFP module with gigabit fiber connection.

[OlivierK]

Hi tzsolt  (Community Member)

Did you manage to progress on this issue?

fixed-linked is indeed used when mdio is not present to manage the phy.

The particularity of this device (Max24287) is that it is a parallel to serial interface between the Phy (SFP in your case) and the MAC so both sides need to be checked. I scanned through the Max24287 specifications, on the serial side, did you check the autonegociation in 1000 base x went well?

System software can configure the MAX24287 for 1000BASE-X auto-negotiation by setting PCSCR.BASEX=1 and BMCR.AN_EN=1.

Are you able to read those using the mdio bus?

[tzsolt]

Unfortunatelly no progress...

Yes, I could read all of the registers and PCSCR.BASEX=1 and BMCR.AN_EN=1 are correct.

Meanwhile I figured out that there is one driver wrote by a guy but it is based on linux kernel 2.6 and now I downloaded 5.10.61 from ST.

We could not port it to 5.10...