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.

AM3352ZCZ RGMII2 KSZ9031 Phy Tx works, Rx fails

Hello,

We have a custom board designed using the AM3352ZCZ sitara processor.  We are using a non-standard configuration for the ethernet phy, a micrel kzs9031.  The hardware has been confirmed to work correctly, previous work on u-boot allows us to DHCP and use the phy.  My current kernel fails (3.14.49) which is being built using the current arago distribution.


MDIO is working correctly and identifies the phy at address 0x01.  I have modified the micrel driver to implement timing register setups specific to our board.  After setting the timing registers correctly, my kernel is able to broadcast packets and I can confirm this on wireshark.  The receive channel is not working, it appears as though a cpdma interrupt is happening, but the dma operation is not completing.  Here is what ethtool reports for statistics:

root@nspsom:~# ethtool -S eth0
NIC statistics:
     Good Rx Frames: 0
     Broadcast Rx Frames: 0
     Multicast Rx Frames: 0
     Pause Rx Frames: 0
     Rx CRC Errors: 0
     Rx Align/Code Errors: 0
     Oversize Rx Frames: 0
     Rx Jabbers: 0
     Undersize (Short) Rx Frames: 0
     Rx Fragments: 0
     Rx Octets: 0
     Good Tx Frames: 325
     Broadcast Tx Frames: 325
     Multicast Tx Frames: 0
     Pause Tx Frames: 0
     Deferred Tx Frames: 0
     Collisions: 0
     Single Collision Tx Frames: 0
     Multiple Collision Tx Frames: 0
     Excessive Collisions: 0
     Late Collisions: 0
     Tx Underrun: 0
     Carrier Sense Errors: 0
     Tx Octets: 112450
     Rx + Tx 64 Octet Frames: 0
     Rx + Tx 65-127 Octet Frames: 0
     Rx + Tx 128-255 Octet Frames: 0
     Rx + Tx 256-511 Octet Frames: 325
     Rx + Tx 512-1023 Octet Frames: 0
     Rx + Tx 1024-Up Octet Frames: 0
     Net Octets: 112450
     Rx Start of Frame Overruns: 0
     Rx Middle of Frame Overruns: 0
     Rx DMA Overruns: 0
     Rx DMA chan: head_enqueue: 2
     Rx DMA chan: tail_enqueue: 126
     Rx DMA chan: pad_enqueue: 0
     Rx DMA chan: misqueued: 0
     Rx DMA chan: desc_alloc_fail: 0
     Rx DMA chan: pad_alloc_fail: 0
     Rx DMA chan: runt_receive_buf: 0
     Rx DMA chan: runt_transmit_buf: 0
     Rx DMA chan: empty_dequeue: 0
     Rx DMA chan: busy_dequeue: 0
     Rx DMA chan: good_dequeue: 1
     Rx DMA chan: requeue: 1
     Rx DMA chan: teardown_dequeue: 63
     Tx DMA chan: head_enqueue: 326
     Tx DMA chan: tail_enqueue: 0
     Tx DMA chan: pad_enqueue: 0
     Tx DMA chan: misqueued: 0
     Tx DMA chan: desc_alloc_fail: 0
     Tx DMA chan: pad_alloc_fail: 0
     Tx DMA chan: runt_receive_buf: 0
     Tx DMA chan: runt_transmit_buf: 0
     Tx DMA chan: empty_dequeue: 327
     Tx DMA chan: busy_dequeue: 0
     Tx DMA chan: good_dequeue: 326
     Tx DMA chan: requeue: 326
     Tx DMA chan: teardown_dequeue: 0

 


Notice that we have plenty of good Tx packets, but the Rx DMA channel queue is full and nothing is completing.  I suspect this may be a bad configuration of the cpsw because we are using the secondary emac as the primary (single emac configuration).  Broadcasts go out (DHCP), but the return path fails due to the switches routing configuration. 

I have probed the Rx clock and it is running at 125Mhz nominal (1Ghz link) and occasionally switches to 25Mhz briefly before going back to 125Mhz.  This seems like normal operation.

Any help would be greatly appreciated.