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.

802.3x Flow Control on the AM335x

Other Parts Discussed in Thread: AM3356

Hello,

We'd like to enable Ethernet flow control in the AM335x but have been unsuccessful so far, and would appreciate some insights on how to go about this.

Hardware is a custom AM3356 design with an Xway Gigabit PHY connected to the RGMII1 interface, and the EMAC configured as a single Ethernet port with a two-port switch in front.

Our intention is to have the EMAC automatically send out 802.3x pause frames when it runs out of RX DMA descriptors.

What we do is we advertise PAUSE/APAUSE capability from the PHY.

When auto-negotiation is complete, we verify that the link partner supports pause frames as well, and that pause frames have been enabled in the PHY.

In the EMAC we enable Full Duplex Gigabit operation, and set RX_FLOW_EN and TX_FLOW_EN in the MACCONTROL register.

We configure the FIFO allocation to 6 RX and 14 TX buffers as recommended in the TRM by writing 0xE6 to Px_MAX_BLKS for each port.

We enable flow control on all ports by setting Px_FLOW_EN to 1 for each port in the FLOW_CONTROL register.

To test it all, we flood the interface with incoming UDP packets, and observe the EMAC running out of RX descriptors, dropping packets.

The EMAC however does not send out any pause frames. We confirm this by using Wireshark dumps, and by monitoring statistics counters in the connected Ethernet switch as well as the AM3356's own counters.

Our results are the same using a variety of managed switches and PC's as link partners.

We've browsed the forum and do see a number of other questions relating to flow control, but haven't managed to find any definitive answers. The latest AM335x errata document makes no mention of Ethernet flow control either.

An alternative question - the TRM states that "Receive flow control is triggered (when enabled) when the RX_FLOW_TRIGGER input is asserted", but does not go into great detail beyond that. Could anyone shed some light on what the conditions are to trigger RX flow control?

I'll be out of the office for about a week so apologies in advance for any delays in replying.

Best regards,
Carsten

  • Hi Carsten,

    I will forward this to the Ethernet experts.

  • What operating system are you using?
    The pause frames will only be issued if the CPDMA function is disable. The RX descriptor exhaustion will not cause the pause frames to be issued. In the stats region is RX DMA Overruns count increasing?
  • Schuyler,

    Thank you very much, the reply does however raise a few more questions.

    I'm not sure why you are asking (or why it would matter), but the operating system is Windows Embedded Compact 7 based on the Adeneo BSP. We've made a number of changes to the cpsw3g driver to support the Xway PHY as well as implement flow control, and I should probably mention that we've tried enabling flow control in the KITL/debug driver as well and seen similar behaviour.

    Anyway I'm intrigued by the statement that pause frames will only be issued if the CPDMA function is disabled. I didn't realise it was even possible to use the Ethernet ports without DMA, and as far as I can determine the Transmit/Receive Operation chapters in the TRM makes no mention of how one would go about this, i.e. implement an Ethernet driver without DMA.

    Am I misunderstanding something? Is it indeed an option not to use DMA? And what would the rationale be behind not generating pause frames when the RX engine runs out of DMA descriptors (or, rather, gets close to running out)? It seems like that would be a requirement to effectively implementing flow control.

    Best regards,
    Carsten

  • Carsten,
    I need to expand the CPDMA function disabling. You are correct in that for ethernet frames to be received you need to have CPDMA enabled, there is not a no DMA method. I apologize for adding some confusion.
    The pause frame generation happens inside the CPSW and is triggered on the port FIFOs. If the destination port FIFO is full then that will cause the sending Port to issue the pause frame. So in this scenario the external port is trying to send a packet to the host port. The host port is connected to the CPPI DMA engine, which in effect always accepts the incoming packet. If the RX descriptors are exhausted the CPPI DMA engine drops the frame.
    The only way I have been able to get pause frames to be sent once flow control is configured is to turn off the CPDMA. Once that is disabled the CPPI DMA that is connected to the switch then tells the host port in the switch there is no place to put the incoming packet and that will trigger a pause frame.
    Best Regards,Schuyler
  • Understood, thank you Schuyler.

    Since disabling the DMA is obviously not a practical solution, we'll start looking at a software implementation.

    Thanks again,
    Carsten