[U-Boot] dm9000 patch tftp, nfs fixes.
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.
cheers Chris
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!
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
participants (2)
-
Chris Ruehl -
Tom Rini