From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Date: Thu, 18 Jul 2013 06:12:03 +0200 [thread overview]
Message-ID: <201307180612.03640.marex@denx.de> (raw)
In-Reply-To: <51E6BE61.1020908@digi.com>
Dear Hector Palacios,
> Dear Marek,
>
> On 07/16/2013 06:44 AM, Marek Vasut wrote:
> > Dear Fabio Estevam,
> >
> >> On Tue, Jul 16, 2013 at 12:51 AM, Fabio Estevam <festevam@gmail.com> wrote:
> >>> On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios
> >>>
> >>> <hector.palacios@digi.com> wrote:
> >>>> @Fabio: could you manually run the command 'tftp ${loadaddr} file100M'
> >>>> in your EVK?
> >>>
> >>> Yes, this is what I have been running since the beginning.
> >>>
> >>>> If it doesn't fail, could you try running it again after playing with
> >>>> the environment (setting/printing some variables).
> >>>
> >>> I can't reproduce the problem here.
> >>>
> >>>> As I said, this issue appeared with different TFTP servers and is
> >>>> independent of whether the dcache is or not enabled.
> >>>
> >>> Can you transfer from a PC to another PC via TFTP?
>
> Yes I can.
>
> > Another thing of interest would be a 'tcpdump' pcap capture of that
> > connection.
>
> I was initially filtering out only TFTP packets of my wireshark trace and
> all looked correct. After taking a second look to the full trace I see now
> a hint. Around 7 seconds after starting the TFTP transfer the server is
> sending an ARP to the target asking for the owner of the target's IP. The
> target is receiving this ARP and apparently responding (at least this is
> what my debug code shows as it gets into arp.c:ArpReceive(), case
> ARPOP_REQUEST and sending a packet), but this ARP reply from the target is
> not reaching the network. My sniffer does not capture this reply.
>
> The server resends the ARP request twice more (seconds 8 and 9) to the
> target and since it doesn't get a reply then sends a broadcast ARP
> (seconds 10) asking who has that IP. Since nobody responds it stops
> sending data.
>
> The times that it works (and I don't know the magic behind using a numeric
> address versus using ${loadaddr} when they have the same value), the ARP
> replies do reach the network and the server continues the transmission
> normally.
>
> Using a v2009 U-Boot, the behaviour is exactly the same, but the target's
> ARP replies always reach the network, and the transfers always succeed.
>
> Since Fabio cannot reproduce it I guess it must be a local ghost. :o(
Try a 1:1 connection with a direct cable. Also, try multiple cables ;-)
Best regards,
Marek Vasut
next prev parent reply other threads:[~2013-07-18 4:12 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
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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
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=201307180612.03640.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox