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

[Ruud Commandeur]

Dear Wolfgang, Stefano,

I'm pretty sure I found the cause:

For each tftp transfer the ethernet part is re-initialised. This means
that also fec_init is called. And in fec_init this piece of code
resides:

#ifndef CONFIG_PHYLIB
	if (fec->xcv_type != SEVENWIRE)
		miiphy_restart_aneg(dev);
#endif

This means (in this case) that miiphy_restart_aneg() is called. And here
the phy gets a software reset and autonegotiation restart command, wich
can take up to 500 msces according to the datasheet. So when we would
like to send out the 1st ARP request, the phy is busy with restart and
negotiation. If I skip these commands, any tftp transfer is fast as
lightning! About 150 msecs between pressing enter and the completion of
a small file (68 bytes).

Of course, re-initialisation of all parts for each transfer sounds like
the safest solution. But perhaps the phy could only be reset /
initialised once after start-up. Would this be an option?

Regards,

Ruud

> -----Oorspronkelijk bericht-----
> Van: Wolfgang Denk [mailto:wd at denx.de] 
> Verzonden: vrijdag 31 mei 2013 16:19
> Aan: Stefano Babic
> CC: Ruud Commandeur; U-Boot list
> Onderwerp: Re: [U-Boot] TFTP timeouts, i.mx fec problem?
> 
> Dear Stefano Babic,
> 
> In message <51A86445.3040703 at denx.de> you wrote:
> >
> > 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.
> 
> Well, we do have this first-ARP-failing problem on a number of boards,
> and especially the i.MX based boards appear to be affected - just
> check which boards set CONFIG_ARP_TIMEOUT in their board configs:
> 
> 	mx31ads
> 	mx35pdk
> 	mx51evk
> 	mx53ard
> 	mx53evk
> 	mx53loco
> 	mx53smd
> 	mx6qarm2
> 	mx6qsabre
> 	qong
> 	woodburn
> 
> Actually these are only_ i.MX based boards!
> 
> > 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.
> 
> The question is if there is no better way to wait for the PHY to
> become (really) ready?
> 
> > 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 ?
> 
> Indeed, this should help.  But it remains just a workaround, it ain't
> a real fix.
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> I can't say I've ever been lost, but I was bewildered once for  three
> days.                                     - Daniel Boone (Attributed)
>