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

Hector Palacios
2013-07-17T15:55:13Z

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