From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Fri, 12 Jul 2013 17:50:02 +0200 Subject: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue In-Reply-To: <51E01C0B.2000009@digi.com> References: <1373583784-7129-1-git-send-email-marex@denx.de> <201307120551.39019.marex@denx.de> <51DFEA5C.9060905@digi.com> <201307121401.29749.marex@denx.de> <51E01C0B.2000009@digi.com> Message-ID: <20130712175002.16eae002@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Hector, On Fri, 12 Jul 2013 17:08:59 +0200, Hector Palacios 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 wrote: > >>>>> On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut 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 > >>>>>> Cc: Albert ARIBAUD > >>>>>> Cc: Fabio Estevam > >>>>>> Cc: Stefano Babic > >>>>> > >>>>> Excellent, managed to transfer 90MB via TFTP on mx28evk without a > >>>>> single timeout. > >>>>> > >>>>> Tested-by: Fabio Estevam > >>>> > >>>> It's working here too. > >>>> > >>>> Tested-by: Alexandre Pereira da Silva > >>> > >>> 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.