[U-Boot] TFTP timeouts, i.mx fec problem?

[Ruud Commandeur]

Stefano, Wolfgang,

Thanks for your comments. The CONFIG_ARP_TIMEOUT was not set, so it will
take the default of 5 seconds. This is also the time it takes for the
first timeout. If I add a

	#define CONFIG_ARP_TIMEOUT    200UL

to my board config, I see the ARP request succeed after 2 to 4 attempts.
I always see only one ARP request in Wireshark. Apparently it takes 200
- 600 msecs for the phy to wake up and respond (as Wolfgang assumes as
possible and very plausible cause).

Increasing the ARP_TIMEOUT to some high value like 15000UL has no use,
the 5 seonds tftp timeout comes in earier and a new ARP request is sent
(which is answered as before).

So adding this timeout define will speed things up, and I guess I should
either also increase the CONFIG_NET_RETRY_COUNT or set the ARP_TIMEOUT
to 400 to prevent exceeding the retry count.

But of course it would be nicer to fix the actual cause. I could try and
find a way to keep the phy alive or at least try to proof that it is the
phy (the LAN8720A) that causes this. To be continued...

Regards,

Ruud


 

> -----Oorspronkelijk bericht-----
> Van: Stefano Babic [mailto:sbabic at denx.de] 
> Verzonden: vrijdag 31 mei 2013 10:50
> Aan: Ruud Commandeur
> CC: U-Boot list; sbabic at denx.de
> Onderwerp: Re: TFTP timeouts, i.mx fec problem?
> 
> On 31/05/2013 08:56, Ruud Commandeur wrote:
> > Hi everyone,
> > 
> 
> Hi Ruud,
> 
> > When tracing the code, it could see that fec_send is called 
> for the 1st
> > ARP request and also the return value indicates that 
> sending should have
> > been succeeded (fec_send: status 0xc00 index 0 ret 0). But 
> no package is
> > actually sent. My first guess would be that it has 
> something to do with
> > the TBD / DMA part. The fec_tbd_init also shows some note 
> about a rare
> > hardware condition regarding the WRAP bit (all in
> > drivers/net/fec_mxc.c). Could it be that there is still 
> another issue
> > regarding the chip that causes this? If I do a tftp 
> transfer from linux
> > on the same board and in the same network, it does start 
> immediately.
> 
> At first glance the problem should be with the set up of the phy. It
> could take longer as expected, or there are some issues with the
> specific PHY of the board. An issue in general code of FEC 
> driver is not
> probable, because the same code runs on most of i.MXes 
> without problems.
> From your report, it looks like that the link of the phy is not yet
> active when the fec_send is called, and then no ARP message is sent.
> Could you try setting #define CONFIG_ARP_TIMEOUT to some high value
> (when it is set, the value is often 200mS) to check if the issue
> disappears ?
> 
> Best regards,
> Stefano Babic
> 
> -- 
> =====================================================================
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
> =====================================================================
>