All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Date: Mon, 15 Jul 2013 14:30:15 +0200	[thread overview]
Message-ID: <201307151430.15541.marex@denx.de> (raw)
In-Reply-To: <51E3B9CF.8070607@digi.com>

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.

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

Dang :-(

Best regards,
Marek Vasut

  reply	other threads:[~2013-07-15 12:30 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-11 23:03 [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue Marek Vasut
2013-07-11 23:18 ` Fabio Estevam
2013-07-12  3:41   ` Alexandre Pereira da Silva
2013-07-12  3:51     ` Marek Vasut
2013-07-12 11:37       ` Hector Palacios
2013-07-12 11:39         ` Fabio Estevam
2013-07-12 12:01         ` Marek Vasut
2013-07-12 15:08           ` Hector Palacios
2013-07-12 15:50             ` Albert ARIBAUD
2013-07-12 16:48             ` Marek Vasut
2013-07-15  8:58               ` Hector Palacios
2013-07-15 12:30                 ` Marek Vasut [this message]
2013-07-15 15:09                   ` Hector Palacios
2013-07-15 15:12                     ` Marek Vasut
2013-07-15 15:24                       ` Hector Palacios
2013-07-16  3:51                     ` Fabio Estevam
2013-07-16  4:18                       ` Fabio Estevam
2013-07-16  4:44                         ` Marek Vasut
2013-07-17 15:55                           ` Hector Palacios
2013-07-18  4:12                             ` Marek Vasut
2013-09-12 10:22                             ` Hector Palacios
2013-09-12 10:50                               ` Marek Vasut
     [not found]                                 ` <52319DE8.5080607@digi.com>
2013-09-12 11:00                                   ` Marek Vasut
2013-09-12 11:02                                 ` Robert Hodaszi
2013-09-12 14:05                                   ` Marek Vasut
2013-09-12 14:15                                     ` Robert Hodaszi
2013-09-12 14:31                                       ` Marek Vasut
2013-09-12 14:32                                         ` Robert Hodaszi
2013-09-12 15:06                                           ` Marek Vasut
2013-09-12 18:17                                     ` Wolfgang Denk
2013-09-12 18:39                                       ` Fabio Estevam
2013-09-12 18:53                                         ` Wolfgang Denk
2013-09-12 19:37                                           ` Fabio Estevam
2013-09-13 11:11                                             ` Robert Hodaszi
2013-09-13 11:13                                               ` Robert Hodaszi
2013-09-13 14:01                                                 ` Marek Vasut
2013-09-13 14:24                                                   ` Robert Hodaszi
2013-09-13 16:06                                               ` Wolfgang Denk
2013-09-13 16:24                                                 ` Marek Vasut
2013-09-13 17:46                                                   ` Wolfgang Denk
2013-09-14 22:05                                                     ` Fabio Estevam
2013-09-12 11:08                                 ` Robert Hodaszi
2013-09-12 18:12                                   ` Wolfgang Denk
2013-09-12 17:50                               ` Wolfgang Denk
2013-07-13  2:43   ` Troy Kisky
2013-07-15 13:41     ` Albert ARIBAUD
2013-07-15 17:39       ` Troy Kisky
2013-07-15 19:59         ` Troy Kisky
2013-07-15 20:20           ` Albert ARIBAUD
2013-07-15 20:20         ` Albert ARIBAUD
2013-07-15 21:18           ` Troy Kisky
2013-07-12  5:57 ` Albert ARIBAUD
2013-07-12  6:39   ` Albert ARIBAUD
2013-07-12 11:51     ` Marek Vasut
2013-07-12  6:56   ` Stefano Babic
2013-07-12  7:30 ` Stefano Babic
2013-09-15 18:12 Oliver Metz
2013-09-15 18:16 ` Fabio Estevam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201307151430.15541.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.