Workaround in Zynq port for missing macros when using SDT drivers

[mike919192]

Workaround in Zynq port for missing macros when using SDT drivers

Description

This is a followup to PR #1227 . This is also discussed in the FreeRTOS forums

The summary of the problem is that with the new SDT drivers, Xilinx removed macros that were previously used as clock divider values for various link speeds (XPAR_PS7_ETHERNET_0_ENET_SLCR_100MBPS_DIV0 and similar). It seems that the intention is that the macros are no longer necessary, except that some link speeds do not function without writing the macro values to the SLCR_GEM0_CLK_CTRL_ADDR register. For me 1000Mbps worked without writing to the register but 100Mbps does not work. I have also reproduced the same problem with the Xilinx lwip port, so the problem is definitely with these missing macros.

The best work around seems to be to define these missing macros in the FreeRTOSIPConfig.h for the time being. The PR changes the section of the that writes the macro values to the register. It will now write the values if the macros exist, otherwise it will not perform a write.

Test Steps

I have again tested that this code works with both the old and new Xilinx drivers. I have also tested both the old and new drivers at 1000Mbps and 100Mbps link speeds.

Checklist:

Like before the changes are limited to the portable layer, which I don't believe have any unit tests.

• I have tested my changes. No regression in existing tests.
• I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[tony-josi-aws]

@mike919192

Thanks for creating this follow-up PR and contributing to FreeRTOS+TCP.

[mike919192]

@tony-josi-aws Thanks for merging this. I think that both this PR and the also #1227 probably also apply to the xilinx ultrascale port. I think I have access to the right hardware to run the ultrascale port, but I haven't had any time to check how close the code is to the Zynq port. Either way this probably should be a todo item, to check if ultrascale also needs updated and test it.

[tony-josi-aws]

@mike919192

Thank you. Yes, it should be a to-do item. I believe these 2 PRs should help someone trying to upgrade the ultrascale port to the latest drivers as a reference.