OK6410上uboot1.1.6的dm9000AE移植

本文参考了前面转载的那几篇帖子进行移植，特别要注意你现在正在移植的uboot版本是不是和网上的那些博客解说时用的是同一个版本，否则你在1.1.6中作死都不会找到dm9000_initialize()这个函数！！！
重申：我用的是uboot-1.1.6版本，是飞凌OK6410光盘里面拷贝过来的！还有飞凌官方的uboot是支持dm9000，但是尼玛仔细看下自己板子上的网卡芯片，DM9000AE!!
为了缩短时间，我没有去拿一个新的uboot来完全移植到OK6410，我只是想把网卡加上去，方便用NFS挂载根文件系统。
好，直接上图：
smdk6410.h
 



dm9000x.c
 

 



board.c，加了一些调试信息
 



好，编译先，看一下效果！
 



启动还正常，但是ping不通，按照他们说的继续改！
dm9000x.c
 

 

 



重新编译，再走一遍...
 

第一次Ping不通
 

但是后面几次都可以ping通，断电重启再来还是这样，看起来很勉强的样子！
用抓包软件抓第一次ping的时候的包看：
 

 



对比一下后面可以ping通的情况：
 

 

 

ping的过程：客户先发一个包给主机，此包中主机的mac地址为空（因为此时知道主机ip，但不知主机mac），主机会做出回应，在dm9000接受到回复包后，取出对方的MAC地址封装一个ICMP包，再发给主机。


回去看第一次ping的包，客户发的第一个包里面缺了发送者的IP地址。
===================吃完饭了！继续。。。==================
再抓包截图，核对MAC地址，仔细看发现不对：
 

 

 

 

第一个tell 0.0.0.0这个包不是开发板发的，是主机在自娱自乐啊！主机广播一个消息，问谁是192.168.2.20啊？知道就告诉一声0.0.0.0，实际上0.0.0.0就是主机他自己（0.0.0.0和127.0.0.1这两个地址都是表示自己）


往后看，6、7、8这三个包才是开发板上进行的ping命令，但是仔细对比下上面可以Ping通时的包，两个竟然一样。
也就是说，实际是ping通了的，但是终端给我们的结果是没有ping通，而且后面去ping都是可以通。
于是去追踪”ping failed; host 192.168.2.20 is not alive“这个错误消息是怎么出现的。
 

追踪到时由于NETLOOP_FAIL导致的，然后是PingTimeout函数被执行，超时了啊啊啊啊！！！


====================2014-03-11，继续追踪。。。========================

找到了是net.c中NetLoop里面的这段代码被执行了：
 



if条件进去了，get_timer(0) - timeStart，获取定时器的时间，减去时间起点值，大于阈值，反正就是整个过程花的时间太长了，导致这个if条件执行；然后为什么第一次ping不通，后面就很容易ping通，估计是ARP缓存了上次得到的主机MAC地址。

但是第一次时这个超时问题就想不通了，先放着，后面再说......

原文：

http://www.mcuprimer.com/forum.php?mod=viewthread&tid=155&extra=