Hi Wayne
I have been doing all those changes and have it well document in my 1st post in this thread.
I went back and also confirmed the pinmux by reading some of the registers at runtime. As you can see the registers match the expectation (eqos mode, rsvd0 for interrupts, etc)
#eqos td3
sudo busybox devmem 0x02445000
0x00002400
#rst
sudo busybox devmem 0x02434070
0x00000058
#int
sudo busybox devmem 0x02434078
0x00000000
In my previous post you replied that there has been no change to RGMII between 5.0.1 and 5.0.2
I can only see that the device tree (read back from the device) is different. I especially see that >=5.0.2 I have “interconnects” nodes which I can’t see in 5.0.1. So at least something has changed.
I wonder if anything regarding the DMA architecture has changed…
Here is the device tree dump from 5.0.1:
dts.txt (328.9 KB)
Let me summarize my status:
- I have confirmed that the pinmux and dtb get applied.
- I can see the device being recognized (which to my understanding means that at least mdio is fine). Also I can see the connection status and it correctly negotiates the data rate.
- I see the interrupts arriving
- I see some packets being received and sent, but the actual communication doesn’t work.
- The loopback test (ethertool -t) fails with -110 (timeout)
- The very same hardware works with Xavier on JP 5.1 and on Orin with JP 5.0.1
My questions:
- What can cause the packet counts (seen using ifconfig) rise while (not all?) packets are actually received
- Again: What has changed from 5.0.1 to 5.0.2
- How is the mechanism of moving the data from the phy to the system. Who triggers the DMA transfers. Is there any way to debug this?
- Any suggestions for further debugging?
Thank you Marc