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

[Wolfgang Denk]

Dear Ruud,

In message <15AE5A936F5E3A42A9144E66875A0A893090E4 at server1-derijp.CLB-Benelux.lokaal> you wrote:
> 
> I have been testing for a while now on the i.mx28 evk, and I noticed
> that almost all tftp transfers take some time before they actually
> start. It will show a 'T' as first character, then followed by '#'
> chars. After enabling some debug info, it appeared that it would always
> start by sending an ARP request, but this ARP message does not get sent
> actually (monitored with Wireshark). After 5 seconds the 2nd ARP request
> is sent (this does get traced by Wireshark) and also responded and from
> that point all goes well.

This is a known problem on some hardware.  We usually work around this
by defining CONFIG_ARP_TIMEOUT in the board config file.  Try setting
something like

	#define CONFIG_ARP_TIMEOUT    200UL

> 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

I'm not sure about that.  It appears to depend on the PHY used on the
hardware, in combination on which switch you connect the system to,
and eventually a few more parameters including the phase of moon.  My
speculation is that in some cases the PHY may enter a low-power or
idle state if not used, and drops the first packet while still waking
up.

> 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.

All I can say is that (1) this depends on the hardware and (2) if you
have a combinatiuon of hardware where it happens, then it happens
reliably.  It would be great if you have time to investigate and find
the real cause of the problem.  The CONFIG_ARP_TIMEOUT workaround is a
bit ugly, but works pretty well.

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
"The whole problem with the world is  that  fools  and  fanatics  are
always so certain of themselves, but wiser people so full of doubts."
- Bertrand Russell