Re: Linux kernel commit "add phy-mode support for the KSZ9031 PHY" broke ETH for Synopsys HSDK board.

Re: Linux kernel commit "add phy-mode support for the KSZ9031 PHY" broke ETH for Synopsys HSDK board.

[Oleksij Rempel]

[-- Attachment #1.1.1: Type: text/plain, Size: 2639 bytes --]

Hi Evgeniy,

Am 03.07.20 um 01:28 schrieb Evgeniy Didin:
> Hi Oleksij,
> 
> Synopsys ARC HSDK board has “Micrel KSZ9031 Gigabit PHY” chip on it, boot log:
>> Starting network: stmmaceth f0008000.ethernet eth0: PHY [stmmac-0:00] driver [Micrel KSZ9031
> Gigabit PHY] (irq=POLL)
> With recent commit bcf3440c6dd ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY")
> Ethernet stopped
> 
> working on HSDK board.
> 
> 
> It seems that there is a lack of *phy* configuration in hsdk.dts file, see:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arc/boot/dts/hsdk.dts#n229
> 
> What fields do you think we should add to the *ethernet-phy@0* configuration?
> Or maybe something else is causing the eth issue? Do you have any thoughts on this?

Short answer:
mac: ethernet@8000 {
  ...
  phy-mode = "rgmii-id"; (or "rgmii-rxid")
  ...
}

Long answer:
According to the RGMII v1.2 specification: "PC board design will require clocks to be routed such
that an additional trace delay
of greater than 1.5ns and less than 2.0ns"

Usually, to get this kind of delay on the clock line, you should make the clock line 10-15cm longer
then the data lines.

Since it is kind of complicated, to add this long traces to a tiny embedded board, was introduced
specification RGMII v2.0. It allows for MAC and/or PHY to have internal delay. A device with
internal delay will be called "rgmii-id". In the kernel it is preffered to add this delay by the
PHY, not MAC. Otherwise it will be a bug and should be fixed.

Since most of embedded boards do not have room for 15cm clock traces, then in most cases 'phy-mode =
"rgmii"' is not correct. It will work as long as PHY driver will be fixed. Like in this case.

Per default KSZ9031 was configured as "rgmii-rxid":
- no delay on TX path (MAC to PHY)
- 1.2ns delay on RX path (PHY to MAC)

If it was working on your board in "rgmii-rxid" mode, then:
- the MAC added some delay. in this case, most probably it is a bug and should be fixed in the MAC
driver.
- there was no TX delay and the PHY was working by accident on the edge of specification. Did you
had some kind of random packet drops?
- The clock line is actually 10-15cm longer then data lines.

Beside, phy0 on this board is bootstrapped to the address 0, which is broadcast address on the MDIO
bus. Please don't use this address if possible. And, it is probably a good idea to add in the
comment the part name of the PHY. Бecause patching PHY drivers is usually done like: "туши свет,
бросай гранату" ;)

-- 
Regards,
Oleksij


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

RE: Linux kernel commit "add phy-mode support for the KSZ9031 PHY" broke ETH for Synopsys HSDK board.

[Evgeniy Didin]

Hi Oleksij,

Thanks a lot for a detailed explanation and advices!  
Changing phy-mode to "rgmii-id" solved the issue.
Thank you for help!

Best regards,
Evgeniy Didin

-----Original Message-----
From: Oleksij Rempel <linux@rempel-privat.de> 
Sent: Friday, July 3, 2020 8:18 AM
To: Evgeniy Didin <didin@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>; Eugeniy Paltsev <paltsev@synopsys.com>; linux-snps-arc@lists.infradead.org; Jose Abreu <joabreu@synopsys.com>
Subject: Re: Linux kernel commit "add phy-mode support for the KSZ9031 PHY" broke ETH for Synopsys HSDK board.

Hi Evgeniy,

Am 03.07.20 um 01:28 schrieb Evgeniy Didin:
> Hi Oleksij,
> 
> Synopsys ARC HSDK board has “Micrel KSZ9031 Gigabit PHY” chip on it, boot log:
>> Starting network: stmmaceth f0008000.ethernet eth0: PHY [stmmac-0:00] 
>> driver [Micrel KSZ9031
> Gigabit PHY] (irq=POLL)
> With recent commit bcf3440c6dd ("net: phy: micrel: add phy-mode 
> support for the KSZ9031 PHY") Ethernet stopped
> 
> working on HSDK board.
> 
> 
> It seems that there is a lack of *phy* configuration in hsdk.dts file, see:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/
> arch/arc/boot/dts/hsdk.dts#n229
> 
> What fields do you think we should add to the *ethernet-phy@0* configuration?
> Or maybe something else is causing the eth issue? Do you have any thoughts on this?

Short answer:
mac: ethernet@8000 {
  ...
  phy-mode = "rgmii-id"; (or "rgmii-rxid")
  ...
}

Long answer:
According to the RGMII v1.2 specification: "PC board design will require clocks to be routed such that an additional trace delay of greater than 1.5ns and less than 2.0ns"

Usually, to get this kind of delay on the clock line, you should make the clock line 10-15cm longer then the data lines.

Since it is kind of complicated, to add this long traces to a tiny embedded board, was introduced specification RGMII v2.0. It allows for MAC and/or PHY to have internal delay. A device with internal delay will be called "rgmii-id". In the kernel it is preffered to add this delay by the PHY, not MAC. Otherwise it will be a bug and should be fixed.

Since most of embedded boards do not have room for 15cm clock traces, then in most cases 'phy-mode = "rgmii"' is not correct. It will work as long as PHY driver will be fixed. Like in this case.

Per default KSZ9031 was configured as "rgmii-rxid":
- no delay on TX path (MAC to PHY)
- 1.2ns delay on RX path (PHY to MAC)

If it was working on your board in "rgmii-rxid" mode, then:
- the MAC added some delay. in this case, most probably it is a bug and should be fixed in the MAC driver.
- there was no TX delay and the PHY was working by accident on the edge of specification. Did you had some kind of random packet drops?
- The clock line is actually 10-15cm longer then data lines.

Beside, phy0 on this board is bootstrapped to the address 0, which is broadcast address on the MDIO bus. Please don't use this address if possible. And, it is probably a good idea to add in the comment the part name of the PHY. Бecause patching PHY drivers is usually done like: "туши свет, бросай гранату" ;)

--
Regards,
Oleksij

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc