From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Ruehl Date: Fri, 29 Mar 2013 13:32:42 +0800 Subject: [U-Boot] dm9000 patch tftp, nfs fixes. In-Reply-To: <20130328215058.GB30253@bill-the-cat> References: <51507EB6.1040900@gtsys.com.hk> <20130328215058.GB30253@bill-the-cat> Message-ID: <5155277A.3070002@gtsys.com.hk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Friday, March 29, 2013 05:50 AM, Tom Rini wrote: > On Mon, Mar 25, 2013 at 06:43:34AM -0000, Chris Ruehl wrote: > >> Hi, >> >> I start a project on a freescale imx27 using the dm9000a for network. >> >> I learned that the tftp , nfs and other network related working more >> less very unstable. I start compare the dm9000.c code with the >> upstream kernel v3.8.4 and fix some issues. >> >> issues >> tftp >> with many bad checksums and timeouts >> nfs >> with not working at all when upload a 38Mbyte rootfs.jffs2 >> >> >> After the patch its works much better for me. >> please find my patch attached and consider to merge it the the head branch. > [snip] >> @@ -351,75 +353,82 @@ static int dm9000_eth_rx (struct eth_device *edev) >> u32 tmplen, i; >> u32 tmpdata; >> >> + udelay(2500); // we called in a loop to quick .. give me some time > > No // style comments, and "We were called into the loop too quickly". > > And I don't know if the big delay here is a good thing or not, without > knowing the hardware. Jason, you've touched this driver recently and I > assume know the hardware at least a little bit, can you comment here? > For full context see http://patchwork.ozlabs.org/patch/230759/ thanks! > Tom, yeah, .. sorry about the style, I'd missed the comment .. ( I gonna fix this and resend my patch later ..) you right about its hardware dependency, on the mx27 @ 400Mhz I tried it with delays from 1000-3000 where 2500 give me the best result. Without a delay its end up in tftp *TTTT#.. and NFS is not working at all. Chris