From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Mon, 15 Jul 2013 17:12:24 +0200 Subject: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue In-Reply-To: <51E410A8.3040302@digi.com> References: <1373583784-7129-1-git-send-email-marex@denx.de> <201307151430.15541.marex@denx.de> <51E410A8.3040302@digi.com> Message-ID: <201307151712.24408.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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