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

[Marek Vasut]

Hi Hector,

> Hi Marek,
> 
> On 07/15/2013 02:30 PM, Marek Vasut wrote:
> > Dear Hector Palacios,
> > 
> >> 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.
> > 
> > OK, makes sense.
> > 
> >> 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.
> > 
> > Can you try running "dcache off" command before running the TFTP
> > transfer? Does it still behave like this?
> > 
> > You might need to define #define CONFIG_CMD_CACHE for this to work.
> 
> Sourcery!
> It's not that it works with dcache off, I found something even more
> strange: The way I reproduce this issue is by setting the 'bootcmd' to
> 'dboot ${loadaddr} file100M'. When you set the 'bootcmd' like this:
> 
> 	setenv bootcmd tftp ${loadaddr} file100M
> 
> this eventually expands to
> 
> 	bootcmd=tftp 0x42000000 file100M
> 
> So this is the command that runs automatically after the bootdelay.
> I just discovered that if instead of letting the auto boot run, I press a
> key to stop the auto boot and run the command by hand (either running
> 'boot' or typing the command 'tftp 0x42000000 file100M'), the tftp
> transfer works perfectly.
> On the other hand, if I do the same but use the environment variable
> ${loadaddr}, i.e. 'tftp ${loadaddr} file100M'. It will stop after 10
> seconds.

Count it be your hardware needs some more delay to stabilize?

> And to make things funnier I just reproduced this issue on the MX28EVK
> using the imx U-Boot custodian tree at commit
> a3f170cdbf7ae0bd24c94c2f46725699bbd69f05. That discards being a platform
> issue.

It still might be a PHY issue, no?

> @Fabio: could you manually run the command 'tftp ${loadaddr} file100M'

I guess that'd be a 100MB file?

> in
> your EVK? If it doesn't fail, could you try running it again after playing
> with the environment (setting/printing some variables).
> As I said, this issue appeared with different TFTP servers and is
> independent of whether the dcache is or not enabled.
> 
> Best regards,
> --
> Hector Palacios

Best regards,
Marek Vasut