Hi Hector, On Fri, 12 Jul 2013 17:08:59 +0200, Hector Palacios <[email protected]> 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 <[email protected]> > >>>> wrote: > >>>>> On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut <[email protected]> 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 <[email protected]> > >>>>>> Cc: Albert ARIBAUD <[email protected]> > >>>>>> Cc: Fabio Estevam <[email protected]> > >>>>>> Cc: Stefano Babic <[email protected]> > >>>>> > >>>>> Excellent, managed to transfer 90MB via TFTP on mx28evk without a > >>>>> single timeout. > >>>>> > >>>>> Tested-by: Fabio Estevam <[email protected]> > >>>> > >>>> It's working here too. > >>>> > >>>> Tested-by: Alexandre Pereira da Silva <[email protected]> > >>> > >>> 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. _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
