xxc4401 

 解决你的U-boot+ RTL8019AS 驱动问题总结
解决你的U-boot+ RTL8019AS 驱动问题总结
终于忙完了老板的事情，这两天闲着没有事情做却反到不自在——大约是没那个命吧！于是又想起了我的那块早已成封的SUMSUNG S3C44B0X开饭板来。我的开发板网卡电路有问题，一直都没有时间去管他，抽这个无聊的时间来搞定它，本想上网copy一个现成的，结果xxc只发现很多人问和ZLG的有源代码（倒是省了不少编码的事儿：），没有搜到讲原理的。这是我对移植源码时觉得易混淆或易搞错的地方的一个总结，帖出来，如果你真的需要，希望本问对你有帮助（支持开源精神！！！！！！！1）。。。说了这么多废话：）该进入正题了。
一、偶（还是习惯用Xxc）的开发板问题描述：EA44B0-II, 搜了一下，目前还有大量的在叫卖，如果你打算买板子，认准了，别被烫！！外型相同却一个350+，一个260+，或者多半就是我这款。网卡问题在与：（1）RTL8019上的SA0~ SA0分别与CPU 的ADDR0~ADDR4连接，显然这样只能工作于8位模式，BUT引脚IOCS16B拉高，出现矛盾了撒（其实能通过软件配置解决这个问题的），（2）SA8、SA9
高（暗示BASE_ADDR = 0x300）；BD1 = 高(BASE_ADDR = 0x200)，又矛盾了撒，（3）JP = 低（即jumper model），这个到是没有做，不过我还是该成了常用的jumpless model.。
二、硬件解决方案：（1）IOCS16B 悬空（2）BD1悬空（3）RTL8019AS的SA0 接到44B0X的ADDR8（任意>  =ADDR5其实都可以）。该割的歌，该接的接，不要舍不得嘛：）
不管你是遇到硬件问题还是“packet too big”、
“TTTTTTTTTTT。。。”还是其他原因引起的网卡不通，呵呵十有八九都得改驱动。驱动怎么写，看DATASHEET和ZLG的驱动源代码吧，也没什么好说的。如果你的板子硬件没有问题，一般来说不过就是改一改地址偏移就ok了。但是如果你还想叫劲，想知道其所以然，或者你老觉得自己写的驱动没有错，可就是不工作。呵呵，你可以看看以下内容了（如果我错了，或你有其他想说的，xxc（email: xxc4401@126.com）双手欢迎你的续）。
三、移植过程中的常见问题。
（1）、byte order问题：大家都知道，主机与网络通讯时，常常要涉及到这个，写过linux socket程序的都知道hton(), ntoh()的东东。在u-boot中的RTL8019 driver不过就这几个主要的函数：
int eth_init (bd_t * bd)；/*bd_t 在u-boot.h中定义*/
extern int eth_send (volatile void *packet, int length);
extern int eth_rx (void);
NetReceive (NetRxPackets[0], rxlen);
这里要说的其实只是eth_send（）中的*packet。读源码知，packet 指向TCP/IP协议栈中分配的收发BUFFER（net.c中就可见一斑，和linux中的SKB处理差不多），在上层协议分配PKTBUF时，有意分配了5*1536的连续区域，第一个用于NetTxPacket, 后4个用与 NetRxPacket, 为什么是1536呢？ethernet IP包  <= 1500 + 14，所以Buffer>  = 1514, 而1536正好是第一个4字节对起的数字。打印*packet，你就知道，上曾协议已经将数据包按网络字节顺序（big-endian）存好了,其实想想你在socket编程时为什么显示使用hton\ntoh（）,就知道理应这样哈。所以这里要说的是：这个byte order与网卡完全无关。有关的是：1）rtl8019as的DCR（BOS），0：little endian; 1: big endian; 不是无关末？这个指的什么？其实RTL8019AS接受到FRAME后，自动添加“接受状态（1B）+下一页指针(1B)+以太帧长度(2B)” 接受状态 == 当前RSR; 下一页指针 == 当前CURR; 以太帧长度 == 含FCS的帧长度。DCR（BOS）应该是指这四个BYTE的BYTE ORDER。这一点在eth_rx (void);中解吸帧前4B时可能对你有用。
（2）、CURR和BNRY的初始化问题。有网友提到，到底是初始化 CURR == BNRY 还是CURR == BNRY+1。其实这个只是数据结构中循环队列的操作问题。都能实现，只是操作有点点区别罢了。接受BUFFER，被实现为一个循环队列。CURR由chip自己操作，驱动中一般只是读起直，BNRY的增加要程序实现，注意在eth_rx()中的实现。
（3）、93C46 EEPROM问题。嵌入式环境处于成本考虑，一般都不用之。如果RTL8019被搞成jmp model的话，大棵不比管他，信片的工作MODEL可以完全有PIN的连接方式决定。即PAGE3的CONFIG1~3由PIN初始状态决定。初始直见DATASHEET。如果是jmpless model，也可以用代码的方式对CONFIG1~3初始化。
（4）、local DMA Vs. remote DMA。这里的DMA只是盗用了OS的DMA concept, 其实与后者没有什么关系。是说不比每访问一次RAM
发一次地址命令，而是R/W RAM时，CURR自动增加，发送一次其使地址，可读写一段DATA。这样速度快多了：）“本地”指8019AS的硬件收发电路侧；“REMOTE”指CPU册，只是区分对片内的16K双口RAM的两个不同的访问方式的形象说发。LOCAL DMA 编程时可以完全不理睬它。By the way, 但LOCAL MDA  REMOTE DMA同时发生时，前者具有优先权，中断后者，完后恢复后者。这个对我们来说是通明的。
（5）、如何send packet。几乎所有动作的执行都是通过对CR（00H）赋值来实现的， remote Read : 00001010B; Remote Write: 00010010B; Abort/Complets remote DMA: 001**010; 但是send packet不是：**011***B，DATASHEET明明这样写的，但为什么“不是”呢？XXC也想问。可行的做发是对（TXP = 1）如：001**110B。
（6）什么是8bit,什么是16bit.。或许你会说，这个还用得着拿出来说。不管你笑不笑xxc, xxc还是写出来。请听我道来: 1）所谓的8位/16位，pin(IOCS16 set HIGH : 16bit,反之为低)，但是到底是8为模式还是16位模式，还优先取决于DCR的第0位，所以如果你见到有例子pin明明拉低，还津津有味的讲16位模式，就不要奇怪了哈。2）寄存器永远是“8位”的。0x0~0x0f对应的配置寄存器都是8位的。所以你的驱动程序里对0x0~0x0F的访问的数据传输都应该是底8位有效（如果你的NIC本来就是8位模式，那就没得说的了）。即NIC与cpu的数据总线的底8位有效，如果你统一按16位模式访问寄存器和REMOTE DMA，这在x86, ARM(若配置位little endian模式)，自然是没有问题的，但这样的驱动是不能跑ARM big endian模式或MIPS了（我们的骄傲“狗剩”应该也不行吧？：）。3）NIC的RJ45端永远是串行的。4）8位/16位的区别在那里？ ①remote DMA时NIC与CPU的有效数据宽度不同。8位模式是一次R/W一个”8元组”，后者是两个”8元组”。呵呵，说起来简单哦，如果没有practise, 问题来了，可能就象不知道一样，犯低级错误呢！② 如前述，从而导致对0x10~0x1a的data port的访问方式不同，eg. 16位模式时采用0x10作为DMA data port的话，则应该看作：0x10+0x11地址空间作为双端口RAM的数据口（xxc的说法不严谨，旦愿能读动xxc表达的意思）。这点很重要哦，如果你还是使用 put_reg(volatile unsigned char  addr, data), get_reg(volatile unsigned char  addr, data)进行DMA R/W或者你认为“16位模式采用辆次前述put_reg/get_reg，效果相同”，那就ERROR了！ 其实际上，在local /remote DMA 时，每次R/W后的位移是和所设置的模式想对应的。Eg. Remote DMA write 0x4000后，下一个写的地址是0x4001(8位模式)/ 0x4002(16位模式)，由此可见ERROR在哪里吧？
（7）其他注意的地方。1）注意chip的power模式，一般来说，jmper模式下，不用考虑。但是如果你确定chip没坏，驱动程序有找不出错，但就是工作不正常，LED不亮，那就可以看看PAGE3中的config中的值了，特别是CONFIG3中的POWER DOWN /SLEEP 在工作时应该为0。如果初始化为1，那DEBUG就头痛了。
（8）调试的时候，可使用各种抓报工具，还有就是LED1、LED2的blink。如果什么响动都没有的话可以用示波器测一测。
好吧，晚了，xxc累了，就写到这里，如果你有什么其他的东东，请续，谢谢了哈in advance. （xxc4401@126.com）
[/color][/color][/color][/color]

发表时间:2007年4月28日0:55:40