Other Parts Discussed in Thread: STRIKE
[Follow-up to AM6548: PRU ICSSG (SR 2.0) receive stalls.]
Since the last activity reported on the "parent" thread, we have:
- updated the host driver for PRU-ICSSG EMAC to work with the current EMAC firmware
- switched to use EMAC firmware v02.02.11.02 (as advised by TI)
- confirmed that under the "receive stall" condition, the MII G RT hardware receive counters do not increment
This suggests that the receive stall involves a failure in the MII G RT and/or the connected PHY (TI DP83867). With that in mind, we have:
- carried out a detailed review of the hardware interface between the AM564x SoC and the Ethernet PHYs
- verified PHY configuration (internal delays, etc.)
- verified MDIO operation (timing, etc.)
Nothing was found to indicate any failures in operation of the PHY devices.
We have made some progress, though, by adjusting the sequence the host driver uses to initialise the MII G RT ICSSG G CFG register (offset 0 in the MII G RT register map).
Previously, this register was initialised in two stages:
- initialise all fields shared between interfaces (that is, all fields except MII[01]_MODE) - to be clear, this includes enabling TX_PRU, and both Tx and Rx L2 FIFOs
- initialise MII0_mode (to RGMII) when interface 0 is started
- initalise MII1_mode (to RGMII) when interface 1 is started
With that initialisation sequence, the receiver of one interface, typically slice 1, will go into the "stalled" state on start-up and will receive no frames (MII G RT hardware receive counters stuck at 0).
With the host driver changed to initialise the MII G RT ICSSG C CFG register in a single write, with no later update, we have not been able to reproduce the problem.
This suggests that leaving the MII G RT / PHY interface in a default configuration (MII) for some time before it is configured into the required mode (RGMII) may cause it "lock up" and fail to recover until a hardware reset occurs.
While this change to the driver seems to have stopped the immediate and frequent receive stall during start up, it is not clear whether this is in fact a correct solution to resolving the receive stall problem.
Please would you clarify whether there are undocumented requirements about the configuration sequence for MII G RT ICSSG C CFG - for example, MII[01]_mode fields must not be updated after Tx L2 FIFO and/or Rx L1 FIFO are enabled? Is it expected that the MII G RT receive path may stall indefinitely if the MII_mode fields are updated after other aspects of MII G RT have been enabled?
At the moment we feel uncomfortable about assuming this change to the host driver is a correct and complete solution to the receive stall. Clarification and advice from TI on this point would be much appreciated.
Thanks.