[U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue

From: Hector Palacios <hector.palacios@digi.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Date: Mon, 15 Jul 2013 10:58:55 +0200	[thread overview]
Message-ID: <51E3B9CF.8070607@digi.com> (raw)
In-Reply-To: <201307121848.58405.marex@denx.de>

Hi Marek,

On 07/12/2013 06:48 PM, Marek Vasut wrote:
>>  [...]
 >>
>> but I found something:
>> It is very strange that the timeouts appear always after transferring
>> between 20 and 24 MiB. So I thought maybe it was not an issue with the
>> size of the file or the number of packets received, but instead a timed
>> issue (an issue that happens after some period of time). I checked, and in
>> fact the timeouts occur exactly 10 seconds after running the tftp command.
>> I verified that this is what is happening by adding a udelay(100000) at
>> fec_send(). In this case, the timeout also occurs after 10 seconds, but
>> due to the delay, I have transferred only a few Kbytes.
>
> Holy moly!
>
>> I tried to change different timeout related constants at tftp.c but still
>> the issue happens after 10s.
>> It's like if, after these 10 seconds, the PHY lost the link or something.
>> Really odd. Does it tell you anything?
>
> LAN8720 phy, right? Try implementing something like [1], by clearing the
> EDPWRDOWN bit , the PHY will never enter low-power mode. It's just a simple PHY
> register RMW which you can stick somewhere into the PHY net/phy/smsc.c code.
>
> [1]
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/djbw/dmaengine/+/b629820d18fa65cc598390e4b9712fd5f83ee693%5E!/#F0

No, my PHY is a Micrel KSZ8031RNLI.

The hint about the PHY possibly going to power down mode is interesting but I checked 
the PHY registers and EDPD mode (Energy Detect Power Down) is off, at least before 
running the tftp command. Power Down mode is off too, so unless these are somehow 
enabled during the TFTP process, this is not what's happening.

The sniffer shows that the TFTP server simply stops sending data packets. I can see 
however the target sending several times the ACK packet to the last received data 
packet. This would point to the TFTP server (as Albert suggested), but the fact is the 
problem occurs with different TFTP servers (I tried three different servers) and it 
does not happen with an old v2009 U-Boot using the same target.

Many times, though not always, after the timeout occurs, I cancel with CTRL+C and run 
the tftp command again, and then the file downloads completely.
The PHY is my usual suspect...

Best regards,
--
Hector Palacios