Ethernet PHY
Added by Lucas Uecker over 3 years ago
I seem to be having trouble with the ethernet PHY on carrier board. I've tried to duplicate the PHY that is on the Critical Link demonstration board with the known exceptions of using a Microchip KSZ9021RN in place of the KSZ9031RN as well as using a Belfuse 0826-1X1T-23-F instead of 0826-1G1T-23-F. I did alter pins 13 and 47 on the chip accordingly and the as far as I'm aware the difference in connectors is only in the LEDs. The only information that we're seeing in dmesg on bootup is:
[ 7.096330] socfpga-dwmac ff702000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
[ 7.103896] socfpga-dwmac ff702000.ethernet eth0: registered PTP clock
[ 17.161172] NET: Registered protocol family 10
[ 17.182791] IPv6: ADDRCONF: eth0: link is not ready
The only things I can think of is layout, but I would expect more of a poor-performance rather than non-performance, or that I can't get away with single LED setup on a bi-directional part.
Thanks
Replies (10)
RE: Ethernet PHY - Added by Daniel Vincelette over 3 years ago
Hi Lucas,
Can you post your full boot log? With that I should be able to see if the ethernet MAC at least finds the PHY over the MDIO interface.
Thanks,
Dan
RE: Ethernet PHY - Added by Lucas Uecker over 3 years ago
Hi Dan-
I've attached the full dmesg in a text file. Or do you mean the full text from the debug UART on bootup?
Thanks!
RE: Ethernet PHY - Added by Daniel Vincelette over 3 years ago
Hi Lucas,
It looks like the MAC does see the phy because of the following line:
eth%d: PHY ID 00221611 at 3 IRQ POLL (stmmac-0:03) active
So that leads me to believe that the phy is at least out of reset and can at least talk over the MDIO interface.
You can use the following command to see if the phy thinks it has a connection:
ethtool eth0
Example of output of a connection @ 1000 Mb/s
root@mitysom-c5:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 3 Transceiver: external Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x0000003f (63) drv probe link timer ifdown ifup Link detected: yes
If Link detected says no then I would expect the issue to be on the analog side.
If Link detected says yes then I would expect the issue to be on the RGMII side. You could try forcing 10 Mb/s mode, which would really slow down the RGMII interface. Which if slowing it down works then that would point to a layout/trace length issue on the RGMII interface.
Force 10 Mb/s:
ethtool -s eth0 speed 10 duplex full
Dan
RE: Ethernet PHY - Added by Travis Rawson over 3 years ago
Hi Dan,
It does show no link detected. We will poke around further.
Thanks!
RE: Ethernet PHY - Added by Lucas Uecker over 3 years ago
Found the problem; it was right between my ears.
I was careful to alter the symbol for the KSZ9031 so that it was backwards compatible with the KSZ9021, but I made the assumption that the pads were the only difference. Close examination of the KSZ9021 datasheet showed that DVDDH should be 2.5 volts and the current setting resistor R505 should be 4.99k. Made those changes to the prototype and we at least have 100Mb/s. I'm assuming a little more care with the traces on the next board revision will have us at 1000Mb/s.
Thanks!
RE: Ethernet PHY - Added by Daniel Vincelette over 3 years ago
Hi Lucas,
That's awesome to hear, thank you for the update!
Also as a note, you could try adjusting the skew settings on the RGMII side through the device tree bindings to see if you can get 1000Mb/s if the issue is on the digital side of the phy. More info be found here: https://support.criticallink.com/gitweb/?p=linux-socfpga.git;a=blob;f=Documentation/devicetree/bindings/net/micrel-ksz90x1.txt;h=a35558cf3af66b97de28fa61822fcd9021ea1177;hb=refs/heads/socfpga-4.9.78-ltsi
Dan
RE: Ethernet PHY - Added by Lucas Uecker about 3 years ago
I'm having trouble on the new version of the board, which is super frustrating as a few bodges got the previous version working. The symptoms are the ethernet section resets itself every other second or so, pulling down the 1.2 rail every time.
On the above schematic the changes have been:
-KSZ9021RN instead of 31
-R505 is 4.99K as per datasheet
-1.8v has been replaced with 2.5v
-further reading of the datasheet shows that R502 and R504 are supposed to be between 1.0k and 4.7k, I've put on 1.1k
-also C523 is 10uF in the datasheet, but 0.1uF worked in the last version
-I've also changed the ethernet traces some, but that shouldn't affect startup function.
The only other grasping-at-straws difference is I had my hands on U501 this time instead of U502... but they're identical...
RE: Ethernet PHY - Added by Lucas Uecker about 3 years ago
Problem solved. Hopefully for real this time.
The KSZ9021RN takes about 500mA when running in 1000Mb/s mode. The current rating for the 1.2v LDO is 500mA.
Things seem to function fine with a bench supply running the 1.2v bus with current draw indeed around 500mA. It also turns out the last version was having this problem, but didn't for a lot of testing because it was running in a 100Mb mode and we never saw the difference.
Fingers crossed I haven't messed up and didn't know it again.
RE: Ethernet PHY - Added by Alexander Block about 3 years ago
Lucas,
Thanks for the followup.
It actually looks like at Gigabit speeds the KSZ9031 only specifies ~221mA for the 1.2V supply while the KSZ9021 is 563mA.
When operating in 100Mbit mode the KSZ9021 only draws 158mA which would explain why you didn't have an issue.
Alex