DP83867E: Wrong PHY addr showing and link not working

Hi Ashutosh,

Interesting, it seems the MAC may be driving and affecting the strap pins during power-up. What is the power-up sequence?

Thanks for sharing the register dump, the configuration looks good to me... not sure why auto-negotiation is failing here.

Please share the schematic so I may review (can email to e-mayhew@ti.com for private share).

Thank you,

Evan

0525.schematics.pdfSchematics for the device is attached . Also we are using two power supply mode.

Hi Ashutosh,

Can you confirm if auto-negotiation is enabled during your tests? I see the strap register 0x6E[7] indicates aneg disable, but the enable strap for auto-negotiation is included in the schematic.

Is it possible to power the PHY before the SoC, to ensure the strap pins aren't being loaded by the MAC?

Thank you,

Evan

Hi Evan,

Thanks for the reply. Autoneg is enable on the peer pc to which the board is connected. Yes strap registers are showing autoneg disable. Yes it is possible to power the PHY before SoC. what exactly needed to be checked on PHY in this scenario? Yes i am also finding it strange enough that straps configuration are not aligned with registers value. One more point i want to share though reset pin of PHY is connected to WATCHDOG POR and a IO Expander. When i am giving reset from io expander the PHY basic control registers shows resetbit[15] as 1 which indicates PHY is not coming out of reset.

Hi Ashutosh,

Thanks for clarifying. Please share a register dump after powering the PHY first before the MAC.

Two things to check:

[1] Strap values following intended strap settings after powering PHY first.

[2] Reset behaving as intended with and without the MAC powered.

Thank you,

Evan

Hi Evan,

We made some changes in the reset process for the board and it is now only controlled through an I/O expander through which we are able to put the PHY in reset and bring it out of reset as well which was not happening before. As we are using GEM1 inside MPsoc which is connected to this PHY, we changed the pull up strength of RX_D0, RX_D2 & RX_CTL pins to "DISABLE" from "PULL UP" which resulted in correct PHY address as per strap configuration which is "3".

Secondly, we found that the status registers have to be read through indirect addressing method rather than a direct read command and after doing that the strap configuration is read correctly. The same PHY Address is visible at mii info as well as the register at 006E.  The correct values of 6E and 6F registers are as follows and it matches the strap configuration as well.

ZynqMP> mii write 0x03 0x0d 0x001f
ZynqMP> mii write 0x03 0x0e 0x006e
ZynqMP> mii write 0x03 0x0d 0x401f
ZynqMP> mii read 0x03 0x0e        
0003

ZynqMP> mii write 0x03 0x0d 0x001f
ZynqMP> mii write 0x03 0x0e 0x006f
ZynqMP> mii write 0x03 0x0d 0x401f
ZynqMP> mii read 0x03 0x0e        
0154

As we are using Zynq Ultrascale+ MPSoc (11eg family) this PHY is connected to GEM1 interface and this is visible on u-boot only when it is configured and enabled in the bitstream. Thus, I don't think we can enable the PHY and read the registers without enabling the MAC (which is the GEM in our case).

But even after this the link status is still down only, can you guide if any specific configuration is required through the registers to make the link status up.

Hi Ashutosh,

Glad to hear extended register procedure is returning the correct strap values.

Which device is the link partner in this case? The first thing to confirm is that both PHYs have auto-negotiation with the compatible speed advertisements enabled. Relevant registers are:

- 0x0[12] = '1' for auto-negotiation enable

- 0x4 to check speed advertisements

- 0x5 to check LP advertisements (after auto-neg complete)

- 0x9 to check gigabit advertisements

These can be accessed with direct register reads.

Thank you,

Evan

Hi Evan,

We have connected the PHY to one of the PC on which we are working.The auto negotiation is not getting completed(We have also tried with different speeds with autoneg off, result is same and link status is showing down only). Register dump of the PHY device:

ZynqMP> mii dump 0x03 0x00
0. (1140) -- PHY control register --
(8000:0000) 0.15 = 0 reset
(4000:0000) 0.14 = 0 loopback
(2040:0040) 0. 6,13 = b10 speed selection = 1000 Mbps
(1000:1000) 0.12 = 1 A/N enable
(0800:0000) 0.11 = 0 power-down
(0400:0000) 0.10 = 0 isolate
(0200:0000) 0. 9 = 0 restart A/N
(0100:0100) 0. 8 = 1 duplex = full
(0080:0000) 0. 7 = 0 collision test enable
(003f:0000) 0. 5- 0 = 0 (reserved)

ZynqMP> mii dump 0x03 0x04
4. (01e1) -- Autonegotiation advertisement register --
(8000:0000) 4.15 = 0 next page able
(4000:0000) 4.14 = 0 (reserved)
(2000:0000) 4.13 = 0 remote fault
(1000:0000) 4.12 = 0 (reserved)
(0800:0000) 4.11 = 0 asymmetric pause
(0400:0000) 4.10 = 0 pause enable
(0200:0000) 4. 9 = 0 100BASE-T4 able
(0100:0100) 4. 8 = 1 100BASE-TX full duplex able
(0080:0080) 4. 7 = 1 100BASE-TX able
(0040:0040) 4. 6 = 1 10BASE-T full duplex able
(0020:0020) 4. 5 = 1 10BASE-T able
(001f:0001) 4. 4- 0 = 1 selector = IEEE 802.3 CSMA/CD

ZynqMP> mii dump 0x03 0x05
5. (0000) -- Autonegotiation partner abilities register --
(8000:0000) 5.15 = 0 next page able
(4000:0000) 5.14 = 0 acknowledge
(2000:0000) 5.13 = 0 remote fault
(1000:0000) 5.12 = 0 (reserved)
(0800:0000) 5.11 = 0 asymmetric pause able
(0400:0000) 5.10 = 0 pause able
(0200:0000) 5. 9 = 0 100BASE-T4 able
(0100:0000) 5. 8 = 0 100BASE-X full duplex able
(0080:0000) 5. 7 = 0 100BASE-TX able
(0040:0000) 5. 6 = 0 10BASE-T full duplex able
(0020:0000) 5. 5 = 0 10BASE-T able
(001f:0000) 5. 4- 0 = 0 partner selector = ???

ZynqMP> mii dump 0x03 0x01
1. (7949) -- PHY status register --
(8000:0000) 1.15 = 0 100BASE-T4 able
(4000:4000) 1.14 = 1 100BASE-X full duplex able
(2000:2000) 1.13 = 1 100BASE-X half duplex able
(1000:1000) 1.12 = 1 10 Mbps full duplex able
(0800:0800) 1.11 = 1 10 Mbps half duplex able
(0400:0000) 1.10 = 0 100BASE-T2 full duplex able
(0200:0000) 1. 9 = 0 100BASE-T2 half duplex able
(0100:0100) 1. 8 = 1 extended status
(0080:0000) 1. 7 = 0 (reserved)
(0040:0040) 1. 6 = 1 MF preamble suppression
(0020:0000) 1. 5 = 0 A/N complete
(0010:0000) 1. 4 = 0 remote fault
(0008:0008) 1. 3 = 1 A/N able
(0004:0000) 1. 2 = 0 link status
(0002:0000) 1. 1 = 0 jabber detect
(0001:0001) 1. 0 = 1 extended capabilities

ZynqMP> mii dump 0x03 0x09
9. (0300) -- 1000BASE-T control register --
(e000:0000) 9.15-13 = 0 test mode
(1000:0000) 9.12 = 0 manual master/slave enable
(0800:0000) 9.11 = 0 manual master/slave value
(0400:0000) 9.10 = 0 multi/single port
(0200:0200) 9. 9 = 1 1000BASE-T full duplex able
(0100:0100) 9. 8 = 1 1000BASE-T half duplex able
(0080:0000) 9. 7 = 0 automatic TDR on link down
(1fc0:0300) 9. 6 = 12 (reserved)

Ethtool output of the link partner(PC to which PHY is connected):

user@user:~$ ethtool eno1
Settings for eno1:
    Supported ports: [ TP ]
    Supported link modes:   100baseT/Full
                            1000baseT/Full
                            10000baseT/Full
                            2500baseT/Full
                            5000baseT/Full
    Supported pause frame use: Symmetric
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes:  100baseT/Full
    Advertised pause frame use: Symmetric
    Advertised auto-negotiation: No
    Advertised FEC modes: Not reported
    Speed: Unknown!
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: off
    MDI-X: Unknown
Cannot get wake-on-lan settings: Operation not permitted
    Link detected: no

On more think i would like to tell is that analog loopback is successful(Reference taken from DP83867 troubleshooting guide). Kindly suggest future debugging sequence.

Hi Ashutosh, 

Ashutosh Tekriwal said:

Advertised auto-negotiation: No

Does the link partner have auto-negotiation enabled? This ethtool output suggests it may still be disabled on PC side.

Please share the wired network settings on the PC side.

Thank you,

Evan