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

[Hector Palacios <hector.palacios@digi.com>]

Hi Marek,

On 07/12/2013 02:01 PM, Marek Vasut wrote:
> Hi Hector,
>
>> Dear Marek,
>>
>> On 07/12/2013 05:51 AM, Marek Vasut wrote:
>>> Hi,
>>>
>>>> On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam <festevam@gmail.com> wrote:
>>>>> On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut <marex@denx.de> wrote:
>>>>>> The MX28 multi-layer AHB bus can be too slow and trigger the
>>>>>> FEC DMA too early, before all the data hit the DRAM. This patch
>>>>>> ensures the data are written in the RAM before the DMA starts.
>>>>>> Please see the comment in the patch for full details.
>>>>>>
>>>>>> This patch was produced with an amazing help from Albert Aribaud,
>>>>>> who pointed out it can possibly be such a bus synchronisation
>>>>>> issue.
>>>>>>
>>>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>>>> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
>>>>>> Cc: Fabio Estevam <fabio.estevam@freescale.com>
>>>>>> Cc: Stefano Babic <sbabic@denx.de>
>>>>>
>>>>> Excellent, managed to transfer 90MB via TFTP on mx28evk without a
>>>>> single timeout.
>>>>>
>>>>> Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
>>>>
>>>> It's working here too.
>>>>
>>>> Tested-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
>>>
>>> Nice to hear, thank Albert for finding this.
>>
>> Thanks for sharing.
>>
>> Unfortunately I'm still seeing non-recoverable timeouts when doing tftp
>> transfers. Nevertheless, with this patch sometimes I'm able to transfer
>> big files (100MiB) without problems (I was never able before). So this is
>> a big improvement. I applied this patch over a v2013.01, does it need any
>> additional patch? I think I saw one email about flush dcache...
>
> Try Stefano's tree as Fabio suggested. I think it's already pushed and includes
> the fixes.

I just tried, but it didn't help.

>> Considering the other guys seem to work without problems I guess this
>> scenario is specific to my board. I'm using a Micrel KSZ8031RNLI at 50MHz.
>> I always suspect from the PHY.
>
> You can try using the PHYLIB (CONFIG_PHYLIB and CONFIG_PHY_SMSC as in sc_sps_1.h
> ) . Also, can you check which of the two "ret = -EINVAL" is triggered in
> fec_send() ? You can add simple printf() alongside both of them.

fec_send() *does not* ever fail, 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.
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?

Best regards,
--
Hector Palacios