• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 33 subscribers
  • Views 764 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.

Original question:

DP83867IR: phy can link up but can't transmit data

Linux/DP83867IR: Can link but ping is intermittent

Ben Hershey
Prodigy 50 points
Part Number: DP83867IR

Tool/software: Linux

I have a new board design using a Xilinx Zynq 7020 microprocessor running PetaLinux closely based on this design: http://zedboard.org/product/microzed, and cannot get Ethernet working with this PHY. It auto-negotiates reliably to 100Base-T when I connect it to a laptop, but when I try to ping the board from the laptop, pings rarely go through. Some days, I get about 30% of the pings back; other days I try all day and get nothing back. The same SD card works on the MicroZed board, so I don't think it's an OS issue. The Ethernet waveform looks normal on an o-scope, but I do not have a network analyzer so I can't be sure.

I do have the capability to read and set registers on this PHY via U-Boot. I've seen multiple forums on here suggest tweaking "clock and data skew" on the PHY, but I cannot find in the data sheet how this can be done. The only thing I see is RGMII Control Register at address 0x0032 and RGMII Delay Control Register at address 0x0086. Tweaking these don't seem to have any effect. Are there settings I can tweak that can help be narrow down the issue?

Is there anything else I should be doing to help narrow this issue down? I have extensive hardware resources, but I am not an Ethernet expert.

Thanks!

zedboard.org/.../microzed

  • 0
    TI__Mastermind 18425 points
    Hi Ben,

    Are there any schematic changes between the microzed design and your design? I was trying to find schematics for the microzed board to confirm that it uses DP83867 or not.
    RGMII is controlled on the PHY through register 0x32 and 0x86. The PHY will also add skew by default. In this case, the skew on the processor needs to be disabled else the data will not be clocked correctly. Can you check if RGMII is enabled on the processor and that the skew in the processor is disabled?

    -Regards
    Aniruddha
  • 0 in reply to Aniruddha Khadye
    Prodigy 50 points
    Aniruddha,

    Sorry, I didn't explain. The microzed design does not use the DP83867; our design does. We changed the PHY, and that is the one major schematic change. Board layout also changed completely, because we changed the shape of the board. I guess I am asking a more open-ended question regarding which settings on the PHY might be able to help narrow down the issue. At this point I'm not sure if it's an RGMII, or 100Base-T issue, or RX or TX for that matter.

    Since posting the question, I noticed that changing register 0x0086 does not seem to have any effect on the offset of RX_CLK (pin 32) and RX_D2 (pin 35) as measured with an o-scope. The clock and the data are perfectly aligned. Register 0x0032 is set to 0x***3, so skew should be enabled, right? Isn't register 0x0086 supposed to change pin 32's offset with respect to the other RX data pins?

    Regards,
    Ben
  • 0 in reply to Ben Hershey
    TI__Mastermind 18425 points
    Hi Ben,

    Since the schematic has changed can you check if the PHY is not getting strapped in any unexpected modes? Read registers 0x6E and 0x6F to get the status of the strap. Also are you using extended register access to read and write register 0x86? writing register 0x86 should change the skew.

    -Regards
    Aniruddha
  • 0 in reply to Aniruddha Khadye
    Prodigy 50 points
    Hi Aniruddha,

    I extensively looked through the straps, and I don't believe the strapping is the issue. Yes, I am using extended register access to read and write the registers above 0x1F. Another area I am looking is the device tree in the Linux build. I didn't do anything special to my Linux device tree. Is this something I need to do to ensure correct operation? I found here

    github.com/.../ti,dp83867.txt

    and here

    elixir.bootlin.com/.../ti-dp83867.h

    some relevant information regarding device tree nodes with regards to this PHY, but I was unable to find a complete example of what to put into the device tree. For example, I do not know what to put in the "compatible" string for the PHY.