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.

Trouble connecting to PHYs

Hello,

I'm working on a custom board based on the BBB with two LAN8710A PHYs. I have a 1.5k pull up on RXER/PHYAD0 on one of them (to configure it to address 1) and the other has all pull downs on the PHY address pins (address 0). When I boot up the Sitara can't find either PHY:

[ 6.683133] libphy: PHY 4a101000.mdio:00 not found
[ 6.687952] net eth0: phy 4a101000.mdio:00 not found on slave 0
[ 6.694060] libphy: PHY 4a101000.mdio:01 not found
[ 6.698876] net eth0: phy 4a101000.mdio:01 not found on slave 1

I've tested this code (kernel/uboot/devicetree) with a BBB and it finds the slave 0, obviously there is no PHY on slave 1 so I get the same message for that one. I've checked the oscillator and that appears to be fine. I've check the MDIO lines and they seem to be signalling just fine, although it's hard to see any communications for the PHY address I'm actually using since it scans all possible addresses. 

Can you give me any ideas where I might look next?

Thanks,

Matt

  • Hi Matt,

    A couple of things to check:

    1) Are the PHY's out of reset?

    2) Did the PHY's enter suspend?

  • Hi DK,

    1. I have the same design as the beagle bone black for the system reset line and I can see the reset line go high (albeit very slowly, I'm surprised at the 2.2uF cap on the reset line on the BBB.) I also notice that the PHY address pins start signalling as the reset line goes high and during my testing I did pull on of the termination resistors to the isolate the pin from the Sitara so I feel safe to say it's the PHY coming out of reset that is activating the line.

    2. How would I test that they are not in suspend?

    While I was testing last night I watched the MDIO bus and noticed that someone was responding to address 2, it's hard to capture with my standard scope but I haven't found any other address with a response yet. I modified the PHY address in the devicetree to 2, and it does find a PHY there (not sure which one) and the id appears to be correct, 0x7c0f1 same as I get with the BBB. I've since strengthened the strapping resistors for setting the PHY address (from 10k -> 1.5k) but I still find one of them (maybe both?) at address 2.

  • Perhaps the PHYs are latching the incorrect address due to the slow reset. SMSC recommends externally augmenting the internal resistors on all config strap pins. This applies to both PU and PD straps (section 3.7 of the LAN8710 datasheet). There are also some pretty strict POR/nRST + Config Strap timing requirements that need to be followed (section 5.5.3). Please check all of this.

    It would also be useful to examine the values the PHY actually strapped via the PHYAD bits in the LAN8710 Special Modes Register (section 4.2.9) to see if they match your expectations.

  • It does look like the slow reset was causing the issues. I've removed both caps (C24 & C30 in the BBB design) on the reset line and it is recognizing the PHYs appropriately. FYI I had externally augmented all of the strap resistors already and that did not seem to help. I will try to access the register you mentioned, could you give me any tips how to get that from Linux? I'm still pretty new to Linux and I'm not sure how I would go about reading the value in that register.

    I still have concerns that the reset release is too close to the power up, it's only about 22ms and the datasheet for the LAN8710A says the minimum is 25ms. I may add a second buffer with a schmitt trigger input to get the extra time from an RC circuit but at the same time have a fast transition. Alternatively is there a way to tie a GPIO to the driver for the PHYs?
  • Just to clarify I mean to ask is there a way to tie a GPIO to the reset pin of the PHY and have it appropriately controlled by the driver?