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

[Ruud Commandeur]

No real success here yet. By using a scope I did see that at least the
MAC is trying to send the 1st packet (activity on RMII TXD part). On the
Phy, the clock is running, LED's are blinking, but the 1st packet
doesn't come out. Although: occasionally it does. Also no clues found in
the datasheet of the phy.

For now, I have set the ARP Timeout to 200 msecs and the retries to 15.
Maybe next week I give it another try with some fresh thoughts.

Regards,

Ruud

> -----Oorspronkelijk bericht-----
> Van: Ruud Commandeur 
> Verzonden: vrijdag 31 mei 2013 12:17
> Aan: 'Stefano Babic'
> CC: U-Boot list; 'Wolfgang Denk'
> Onderwerp: RE: TFTP timeouts, i.mx fec problem?
> 
> 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
> > 
> =====================================================================
> >