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

From: Hector Palacios <hector.palacios@digi.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Date: Wed, 17 Jul 2013 17:55:13 +0200	[thread overview]
Message-ID: <51E6BE61.1020908@digi.com> (raw)
In-Reply-To: <201307160644.53198.marex@denx.de>

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(

Best regards,
--
Hector Palacios