Ethernet issue - Rx frames not received

1

Hi,

I am working on a custom board based on the Cyclone V, u-boot and kernel 5.10
Unfortunately, I am having a very hard time to get the ethernet receive path fully working.

I got to the point where I am able to send out packets.
However, packets send to the board are not received; The EMAC registers indicate the no frames are received.

The relevant kernel messages during boot-up are:

[    3.980416] socfpga-dwmac ff700000.ethernet: IRQ eth_wake_irq not found
[    3.987063] socfpga-dwmac ff700000.ethernet: IRQ eth_lpi not found
[    3.993645] socfpga-dwmac ff700000.ethernet: PTP uses main clock
[    4.000267] socfpga-dwmac ff700000.ethernet: User ID: 0x10, Synopsys ID: 0x37
[    4.007435] socfpga-dwmac ff700000.ethernet:         DWMAC1000
[    4.012740] socfpga-dwmac ff700000.ethernet: DMA HW capability register supported
[    4.020281] socfpga-dwmac ff700000.ethernet: RX Checksum Offload Engine supported
[    4.027775] socfpga-dwmac ff700000.ethernet: COE Type 2
[    4.033059] socfpga-dwmac ff700000.ethernet: TX Checksum insertion supported
[    4.040158] socfpga-dwmac ff700000.ethernet: Enhanced/Alternate descriptors
[    4.047130] socfpga-dwmac ff700000.ethernet: Enabled extended descriptors
[    4.053968] socfpga-dwmac ff700000.ethernet: Ring mode enabled
[    4.059817] socfpga-dwmac ff700000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[    4.079978] Marvell 88E1510 stmmac-0:00: attached PHY driver [Marvell 88E1510] (mii_bus:phy_addr=stmmac-0:00, irq=POLL)

...
Configuring network interfaces... [    9.890779] socfpga-dwmac ff700000.ethernet eth0: PHY [stmmac-0:00] driver [Marvell 88E1510] (irq=POLL)
[    9.904265] socfpga-dwmac ff700000.ethernet eth0: No Safety Features support found
[    9.912017] socfpga-dwmac ff700000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
[    9.925021] socfpga-dwmac ff700000.ethernet eth0: registered PTP clock
[    9.933384] socfpga-dwmac ff700000.ethernet eth0: configuring for phy/rgmii link mode
udhcpc: started, v1.35.0
udhcpc: broadcasting discover
udhcpc: broadcasting discover
[   13.123845] socfpga-dwmac ff700000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   13.132582] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
udhcpc: broadcasting discover
udhcpc: no lease, forking to background

The only relevant entry in my device tree is:

&gmac0 {
	status = "okay";
	phy-mode = "rgmii";

	rxd0-skew-ps = <0>;
	rxd1-skew-ps = <0>;
	rxd2-skew-ps = <0>;
	rxd3-skew-ps = <0>;
	txen-skew-ps = <0>;
	txc-skew-ps = <2600>;
	rxdv-skew-ps = <0>;
	rxc-skew-ps = <2000>;
}

I’ve tried and tested many things already, too much to put in this post I am afraid.

Unfortunately, my experience with embedded Linux is still limited, so any advice how to debug this issue would be greatly appreciated!

Kind regards,
Bas

2

Any suggestions on how I could debug this issue would still be most welcome :sweat_smile:

Interestingly enough, we found that ethernet is working perfectly fine when using the following work-around:

  • Use bootargs ip=dhcp
  • Boot initially without ethernet cable inserted
  • Reinsert the ethernet cable when boot process halts because it waits for the dhcp/nfs

Also I am able to ping from u-boot, so something goes wrong after Linux takes over.

Using the workaround, I was able to compare some stuff between the working situation and the situation were no Rx frames are received. This comparison showed identical configurations. The only notable difference at the EMAC register level was that the so-called “Interrupt_Status rgsmiiis bit” was always set in case of non-functional Rx, which should indicate there are continuous changes in value of the Link Status of the RGMII interface. But not sure why that could happen or why the driver does not handle that interrupt.