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

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