Actions
Forum Thread Details
  • Replies 5 replies
  • Subscribers 324 subscribers
  • Views 390 views
  • Users 0 members are here
Related

Ethernet PHY problems on MicroZed rev. H

rgaddi

I'm having intermittent problems communicating with the Marvell Ethernet PHY on the MicroZed. Very possibly the same problem as Microzed 7Z010 rev H having intermittent Ethernet issues a year ago.

According to the system message log, and confirming with mii-diag and phy-tool, it looks like it's failing to find the PHY. My hunch is that it's a continuation of the same reset problem seen on previous MicroZed revisions.

If I It will usually identify the PHY correctly and communicate with it from a very cold boot, like it's been off for half an hour cold boot. And will often keep finding it through several power cycles after that. But at some point it'll stop finding the PHY, and one it does the PHY is lost for however many more quick power cycles. But then if I get a grounded wire and hold PG_MODULE low externally (which is the only thing on the board that triggers a PHY reset) then all of a sudden the PHY works and keeps working.

I've got the MicroZed connected to a custom carrier; that carrier only monitors PG_MODULE and does not drive it.

Some units with this intermittent failure went into the field, and are now failing intermittently at customer sites, so we've got a real problem. I have no way of identifying which MicroZeds will and will not show the problem because again, it's intermittent. So my not having seen a given unit fail yet means nothing.

Parents

  • On the chance this was some kind of a configuration issue on my end I tried firing up the baseline image available at "Open Source Linux boot images for MicroZed 7010/7020".  After a couple of reboots I get the same problem; a dead Ethernet link that, when I go in and ask over the serial console, shows me in dmesg


    root@zynq:~# dmesg | grep ethernet
    xemacps e000b000.ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
    xemacps e000b000.ethernet: eth0: no PHY found
    xemacps e000b000.ethernet: XEMACPS mii bus mii_probe fail.

    Following this test, to confirm that the problem is not with the way we're powering or resetting the Microzed, I removed it from our custom carrier board and, just powering through the USB cable and unplugging it for roughly 1 second before plugging it back in, was able to once again replicate the behavior.  No PHY found.

Reply

  • On the chance this was some kind of a configuration issue on my end I tried firing up the baseline image available at "Open Source Linux boot images for MicroZed 7010/7020".  After a couple of reboots I get the same problem; a dead Ethernet link that, when I go in and ask over the serial console, shows me in dmesg


    root@zynq:~# dmesg | grep ethernet
    xemacps e000b000.ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
    xemacps e000b000.ethernet: eth0: no PHY found
    xemacps e000b000.ethernet: XEMACPS mii bus mii_probe fail.

    Following this test, to confirm that the problem is not with the way we're powering or resetting the Microzed, I removed it from our custom carrier board and, just powering through the USB cable and unplugging it for roughly 1 second before plugging it back in, was able to once again replicate the behavior.  No PHY found.

Children
  • in reply to rgaddi

    There is an RC circuit in the way. Perhaps the way you are cycling isn’t allowing the PG module signal or the cap in the RC to discharge enough to reset the PHY?

    There probably should be a path to GND there to discharge those signals through.

    If i were you l, I would put a scope on the PG module signal (input) and the translator (output) and review the behavior.

    Another option would be SW reset if possible using MDIO interface.

  • in reply to iksevas

    Thanks.  I took a look across the level-shifter and the 1.8V side follows the 3.3V side cleanly and quickly.

    On at least one Microzed so far the problem seems to be linked to whether the Ethernet cable is connected; with the cable disconnected the PHY can be found just fine (and will then proceed to work), but with the cable connected to the network it loses the PHY.

    Software reset over MDIO would be tempting, but I can't find a way to force one.  Whether or not the PHY has been detected I get

    # ethtool --reset eth0 all
    ETHTOOL_RESET 0xffffffff
    Cannot issue ETHTOOL_RESET: Operation not supported

    phytool just gives me error -22 about everything, and as far as I can tell doesn't even attempt to clock anything out the MDIO.


    Other things I've found:

    • There's a blip on the ETH_RST_N line (output of the last AND gate that drives the PHY) on power up during the sequence prior to the actual reset generation.
    • Because the TXS0102 only pulls up the output ETH_RST_# with 10k, the RC time-constant in the pull-up direction is about 3x what you'd expect from the datasheet.
    • The PHY apparently once-upon-a-time had an errata sheet, but either it's no longer available or I'd need a Marvell NDA to even be allowed to know such a thing exists.  But there was once such a thing, and in 2014 led to some changes to the driver under both Linux and U-Boot to handle some behavior on reboot.
  • in reply to rgaddi

    More on SW options from a search:

    1. Checking the Ethernet driver for reset functionality: Look for driver-specific functions or IOCTL commands designed to reset the PHY.
    2. Unloading and reloading the driver module: This can effectively reset the PHY if a specific driver function isn't available.
    3. Utilizing the BMCR.RESET bit: If possible, directly accessing and manipulating the BMCR.RESET bit via software could achieve a reset, but be aware of the potential for link drops. 
  • in reply to iksevas

    Can't find anything digging through the driver code.  Tried using devmem to force an MDIO reset by writing the XEMACPS_PHYMNTNC register, but no luck.

    What does seem to work, lending more credence to the idea that the Microzed reset logic is too touchy, is that I added an STM1818 power-on-reset chip.  It's monitoring my carrier's VCCO supply to the zed, and using that (as well as monitoring PG_MODULE) to ensure a minimum 100ms reset on PG_MODULE.  For a Microzed that I was able to get to consistently fail, with the POR chip in it seems to consistently succeed.

    Having to jury-rig this onto existing units and eventually spin my board to cover this is going to be brutal though.