• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 594 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.

Help with AM347x in RMII mode

Matthew Caron
Intellectual 430 points

Hello all,

I'm trying to get a custom board working with GMII1 in RMII mode under Linux. It uses an external 50MHz oscillator. I've verified:

  1. The oscillator is clocking.
  2. The .dts is configured with rmii-clock-ext.
  3. The emac is configured with phy-mode = rmii, and I've verified that this is propagated through 
  4. The PHY is configured for RMII mode (verified via MDIO read)
  5. The PHY shows link (again, read over MDIO).
  6. Verified correct settings of GMII_SEL register (GMII1 is RMII, GMII2 is MII (for my second interface), RMII1_IO_CLK_EN is set to 1).
  7. Verified that the RMII gasket is set to 100Mbps for 100Mbps link (done by Linux driver, but hand verified).
  8. Checked pinmux pinouts and they look right.
  9. The EE has checked the schematic and says it's right.
  10. We've tried 3 different prototypes and they all fail, so it's unlikely a fab issue.

Does anyone else have any ideas? Am I missing programming a register somewhere?

  • 0
    TI__Guru**** 393215 points
    Hi,

    Please post what Linux version you are using and what is the type of the failure (log file).
  • 0 in reply to Biser Gatchev-XID
    Intellectual 430 points
    Linux version is 3.12.10 based on the git tag ti2013.12.01. There are no errors. CPSW is configured in default switch mode, the MII interface hooked to GMII2 passes traffic to eth0, but the RMII interface hooked to GMII1 doesn't.
  • 0 in reply to Matthew Caron
    TI__Mastermind 27890 points

    Hi Matthew,

    Do you see any activity on the physical interface? Check to see that all the RMII pins are toggling during (attempted) transfers. If so, disconnect Port 2 (MII), reboot, attempt a PING using Port 1 (RMII) and post the contents of CPSW_STATS (section 15.5.4 of TRM) register.

  • 0 in reply to -DK-
    Intellectual 430 points
    Okay, finally got back to this.

    The RMII pins toggle during attempted transfers. The clock always oscillates, and, when pinging PC -> device, I see RXD0, RXD1, and CRS_DV toggling. If log in via the serial port and try to ping out (device -> PC), I see TXD0, TXD1, and TXEN toggling. This all looks normal to me.

    Packet captures on either the device or the the PC show that they only see their own outgoing traffic, not the one from the other side.

    Checking the CPSW_STATS registers (via ethtool -S which looks to dump all of them), I see that, when pinging PC->device, the Rx CRC errors, Rx Align/Code errors, and Rx Fragments all increase, suggesting RX failures.

    I have my own theories as to what is going on here (all involving jitter and a bad clock source, but the EE assures me that the clock looks great), but I'd love to hear any alternate suggestions.

    Thanks in advance.
  • 0 in reply to Matthew Caron
    TI__Mastermind 27890 points
    It could be jitter on your clock source, but unless the jitter was inordinately high, I'd expect SOME packets to make it through. What are the specs of the oscillator you are using?

    I think a more likely answer is that the interface timing is off...did you perform a timing analysis of the RMII interface prior to PCB fab? RMII has notoriously tight timing as an interface so care must be taken during PCB design to ensure that the timing requirement can be met on your particular board.
  • 0 in reply to -DK-
    Intellectual 430 points
    So, the EE looked at this and found some clock contention (a 2.5MHz signal superimposed on the 50MHz signal) and that lead us to believe that the phy was misbehaving, and, despite reporting that it was in RMII mode, it was still outputting a 2.5MHz signal on that pin. A software reset of the phy is apparently necessary to make this change stick, despite it not being noted as such in the datasheet, and that reading the register reports that it is in the desired mode without the reset.

    So, this was all me. Sorry for the bother.