• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 508 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83867E: No communication established when connected to a 1Gbps capable end device

Linda Igboanugo
Intellectual 1820 points
Part Number: DP83867E

HI Please we have a few queries;

Issue 1 : No communication established when connected to a 1Gbps capable end device

When using the default Linux and uboot drivers on the board and when the PHY is connected to a PC consisting  of 1Gbps capable port, communication failure happens (Board Tx side atleast). The following are further observations.

  1. On PC side, the Ethernet port is correctly auto negotiated to 100Mbps (since deliberately only 2 pairs of Ethernet on analog side are actually routed on the PCB).
  2. On the Ti PHY side, I see the auto negotiation result is 100Mbps as well, as expected.
  3. The auto negotiation advertise settings in the 1000BASE-T Configuration Register (0x09) are populated in the Ti PHY claiming 1Gbps capability (Nothing wrong per say as the PHY is unaware of Analog side routing).
  4. When I remove 1Gbps advertise capability in the point c above, everything works fine. This removal is infact, provided as a feature in Linux where a device tree node value of “max-speed = <100>” can be provided.
  5. I have added similar feature in uboot and it works fine too.
  6. All changes are in the GE github now. I also plan to push this max-speed feature to mainline Xilinx official uboot as well.

 

Issue 2 : No reply from Ti PHY’s MDIO interface in Linux

The below points summarize this issue

  1. On PC side, Ethernet interface speed is forced to 100Mbps and then connected to RTM-E board.
  2. In uboot everything works fine with native drivers.
  3. In Linux, the DP83867 PHY enters reset with the native Linux DP83867 driver as part of bootup process. The PHY however never recovers and it does not respond on any address 0-31. Most probable cause is software rest using register 0x1f causes issues in this PHY which is how reset is done by this Ti PHY driver.
  4. This issue is resolved by removing the DP83867 PHY driver and using the generic PHY driver.

 

Issue 3 : Strange PHY address

Refer to my in email for information;

Can you advice best help?? 

thanks Linda