06-21-2018 02:27 AM - edited 06-28-2018 10:22 PM
Dear Xilinx Support,
I am using a baremetal Zynq-7000 platform with lwip network stack. My example design is a ZC706 with the provided echo_server project.
Since Vivado 2018.2 hotplug support for the network cable is supported represented by the new eth_link_detect() function. This was good news for me.
There is however a piece missing: When no ethernet cable is plugged in in during initialization, xemac_add() will throw an assert and never recover. xemac_add() tries to bring up the link and fails of course.
Thus there is no possibility to start a lwip network capable device without ethernet cable connection.
Are there any plans to fix this? Wouldn't it be better to remove autonegotiation from xemac_add() ?
Help is appreciated.
06-21-2018 06:13 AM
get_IEEE_phy_speed() within xemacpsif_physpeed.c serves three functions right now:
1. Resets the PHY,
2. Waits for auto-negotiation to complete and
3. Reads the link speed.
Its name only implies the third.
get_IEEE_phy_speed() is called during initialization by xemac_add(), where only the 1st function (PHY reset) is needed. Thus, there are problems during init when no cable is connected.
get_IEEE_phy_speed() is called again during eth_link_detect(), where only the 3rd function (read link speed) is needed. Thus, main loop is delayed for several seconds, because PHY is resetted after successful auto-negotiation again.
My proposal: Split get_IEEE_phy_speed() into a reset-function and a get_link_speed-function. Call reset-function during xemac_add() and call get_link_speed-function during eth_link_detect(). The waiting for auto-negotiation is already realized by baremetal while(1) loop itself, which regularly calls eth_link_detect().
This has two advantages:
1. Initialization can be done without Ethernet cable connection.
2. Auto-negotiation is not blocking the remaining application.
Are there any reasons to do PHY reset over and over again? Is there perhaps some odd PHY behavior, which requires reset after each link establishment?
Your comments are highly welcome.
06-28-2018 10:19 PM
is there anyone else using lwip and facing the problem, that his or her device might be powered up without an ethernet cable attached?
I thought, this should be quite common.
Anyway, my solution to split get_IEEE_phy_speed works well at my side.
10-31-2018 09:57 AM
i have the same issue, it is not acceptable that I'm running into an assertion if there is no ethernet cable connected during startup, the user must be allowed more than 30s to do that.
As far as I am aware, Xilinx up to date did not provide a solution for that, is that correct?
When you write "my solution to split get_IEEE_phy_speed", how did you do that?
How do you prevent SDK from overriding your code changes every time you rebuild the BSP?
11-07-2018 02:37 AM
For now, I use the workaround to disable auto negotiation and set the link speed to 1000 fixed.
This is not satisfying, but I can work with it until I find a better solution.
11-22-2018 04:46 AM - edited 11-22-2018 04:46 AM
my solution currently is to overwrite xemacpsif_hw.c and xemacpsif_physpeed.c with my own versions after generating the BSP inside the directory
This is not very convenient, but helps for the time being.
All my changes are marked with the tag SGi in the comment
I attach both files for you. Perhaps Xilinx could use my proposal for the following releases?
Have fun and leave me a Kudos if you wish,
11-22-2018 06:00 AM - edited 11-22-2018 06:05 AM
Thank you very much, I will try this out ASAP!
Xilinx should really fix this for good, not the least because this method of patching in the BSP is very error prone: if you forget to apply the patch after rebuiliding the BSP, you will not notice, but loose this important fix.
11-22-2018 07:52 AM
if I remember correctly it will be necessary to regularly call
inside the while(1) loop for example right after xemacif_input(&netif);
Hope that helps.
11-22-2018 08:08 PM
A better way is to patch the library once in a local repository so that any time the BSP is regenerated, it will use your patched library.
So for example, if you want a custom lwip:
Now, next time you create a new bsp, you will see your v1.9 lwip library. If you already have an existing bsp, you may have to remove the old lwip version, let the bsp recompile, and then try adding your version library to the bsp. You may have to close and reopen the workspace in order to add the new version lwip to an existing bsp.
11-23-2018 01:53 AM