Request help with updating Xilinx Zynq drivers

[mike919192]

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 SDT to detect whether the new or old drivers are being used: https://github.com/Xilinx/embeddedsw/blob/master/XilinxProcessorIPLib/drivers/emacps/examples/xemacps_example_intr_dma.c

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:

• Macro XPAR_PS7_ETHERNET_0_BASEADDR changed to XPAR_XEMACPS_0_BASEADDR. Both have same value of 0xe000b000
• Macro XPAR_PS7_DDR_0_S_AXI_HIGHADDR changed to XPAR_PS7_DDR_0_HIGHADDRESS. Both have the same value of 0x3fffffff
• Macro XPAR_PS7_SCUGIC_0_BASEADDR (0xF8F00100U) is also changed. Judging by the name, the best candidate seems to be XPAR_XSCUGIC_0_BASEADDR (0xf8f01000) but the value is different. I also tried XPAR_INTC_BASEADDR_1 (0xf8f00100) which has the same value but both options seem to result in the same runtime issues.
• Macros XPAR_PS7_ETHERNET_0_DEVICE_ID and XPAR_PS7_ETHERNET_1_DEVICE_ID no longer exist. These were set to values 0 and 1 and were used to index an array up to size 2. Likewise the Xilinx struct XEmacPs_Config no longer has member DeviceID. My dev board only has 1 ethernet port, so my array size is always 1. I have hard coded everywhere BaseType_t xEMACIndex = xemacpsif->emacps.Config.DeviceId; to BaseType_t xEMACIndex = 0; just to get it running. I would think this wouldn't be too difficult to implement a new method of getting the correct index.

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.
debuglog.txt

Also attaching the configuration:
FreeRTOSIPConfig.txt

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.

[mike919192]

Some debugging updates:

All of the interrupts seem to be working properly. I have set break points in functions XEmacPs_IntrHandler, emacps_send_handler, and emacps_recv_handler. Stepping through these functions looks the same between the old and new drivers.

Because the problem is on the tx path, I also looked at xZynqNetworkInterfaceOutput and emacps_send_message. Again I can't see any difference in behavior between old and new drivers.

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.

[mike919192]

I finally found that the issue was in the SetUpSLCRDivisors function. The macro XPAR_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 register SLCR_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.

/* SDT drivers should not write to the register */
#ifndef SDT
    SlcrTxClkCntrl = *( volatile unsigned int * ) ( slcrBaseAddress );
    SlcrTxClkCntrl &= EMACPS_SLCR_DIV_MASK;
    SlcrTxClkCntrl |= ( SlcrDiv1 << 20 );
    SlcrTxClkCntrl |= ( SlcrDiv0 << 8 );
    *( volatile unsigned int * ) ( slcrBaseAddress ) = SlcrTxClkCntrl;
#endif

Now I have a working application connection and I can further test that everything is working.