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:sba...@denx.de]
> Verzonden: vrijdag 31 mei 2013 10:50
> Aan: Ruud Commandeur
> CC: U-Boot list; sba...@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: sba...@denx.de
> =====================================================================
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
