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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Hector,

On Fri, 12 Jul 2013 17:08:59 +0200, Hector Palacios
<hector.palacios@digi.com> wrote:

> 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?

Well, such a round number makes me think of an application-layer
time-out. Do you have control over how your TFTP server is
configured?

> Best regards,
> --
> Hector Palacios

Amicalement,
-- 
Albert.