Request help with updating Xilinx Zynq drivers #1225
-
Sometime around 2023, Xilinx started introducing breaking changes to their drivers along with their new IDE. As an example you can look at this file where they use the macro I was able to make modifications to the Zynq portable code to get it to compile, but I am also running into runtime issues, I will describe below. Changes to make it compile:
What is working:I have some test code that I can pretty easily compile with the old or new drivers, so I can compare what is and what isn't working. With the new drivers, all the initialization and link auto negotiation seems to work with no issues. Also everything in the receive path seems to work ok because I can see the log messages about processing arp messages. What is not working:To my untrained eye it seems like the transmit path is not working, but I cannot tell what could be the issue. The new drivers do not respond to ping, even though I can see a message about the arp request being processed. Likewise, it seems like the network buffers are slowly getting filled but never release. My theory is that the responses are getting written to the buffers, but never getting written to the interface. In Wireshark I never see anything from the embedded device. Here is attachment of the debug messages running the new drivers, like I describe. Also attaching the configuration: I have tried stepping through some of the code in the transmit path and I don't see any obvious problems. If anyone has tips on specific things to look at, I can check again. With the same test code using the old drivers, I can see the arp responses and ping responses in wireshark. Sorry for the long post! But if I can get it working I would be happy to help clean it up for a PR. Thanks Edit to mention all this testing is with 4.3.1 release. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Some debugging updates: All of the interrupts seem to be working properly. I have set break points in functions Because the problem is on the tx path, I also looked at I am positive that the rx path is working fine because I was able to set a breakpoint and catch the portable code creating the response to a broadcast ping. I manually inspected the contents of the buffer and all of the fields looked correct. But the response never reaches the wire. |
Beta Was this translation helpful? Give feedback.
I finally found that the issue was in the
SetUpSLCRDivisors
function. The macroXPAR_PS7_ETHERNET_0_ENET_SLCR_1000MBPS_DIV0
and similar no longer exist, so the variable SlcrDiv0 was never getting initialized and garbage was being written to registerSLCR_GEM0_CLK_CTRL_ADDR
.I checked the example xilinx code and the register is never written to with the new drivers so something like this can be done.