On 29.03.19 15:59, Eugen.Hristev@microchip.com wrote:
On 29.03.2019 16:52, Stefan Roese wrote:
Hi Eugen,
On 29.03.19 15:40, Eugen.Hristev@microchip.com wrote:
I've noticed that the first ethernet packet after PHY link establishment is not tranferred correctly most of the time on my AT91SAM9G25 board. Here I usually see a timeout of a few seconds, which is quite annoying.
Adding a small delay (10ms in this case) after the link establishment helps to solve this problem. With this patch applied, this timeout on the first packet is not seen any more.
Hi Stefan,
I find this a bit odd... maybe someone with a different board having this Ethernet controller can confirm or infirm this ?
I've seen such issues of timeouts with the first ethernet packet after link negotiation on other platforms / controllers a few times before in U-Boot. Using a short delay after link-up always did help here.
I'm not saying that this is the perfect solution, but its one that works and removes these timeouts, which really annoy me.
Linux driver for macb has a similar issue ?
Not that I am aware of. There might be some delay in the link establishment hidden as well. I did not check yet.
Adding a delay just for the sake of it might hide another issue that we are missing at this point: why exactly transfer fails right away... it is likely that we want to send packets but link in fact is not ready ?
Yes, something like this.
I see there is a small udelay below your code, you add a delay 100 times bigger... maybe that small delay is related ?
The udelay(100) below is for the timeout handling of the link autoneg loop. This should be probably moved to some loop using get_timer() so that this udelay can be removed completely.
Coming back to your question, if these delays are related. No, they are not. The one that I insert is explicitly added *after* the link was established. I could experiment if a smaller value also works, but I found that 100ms was working in all my test cases. Possibly 10ms or even 1ms also works. Not sure.
Thanks, Stefan