[Task 2010-02-25] Linux内核网卡驱动开发（步骤）

Question

按Fleya昨天所列，今天的主要目标是以太网驱动开发。
下面是一个非常“稳”且高效的开发步骤。其中Step 1~5在g-bios中完成，从step 6开始转入linux kernel。

Step 1: 探路，看硬件能否正常访问
MAC和PHY都要能正常读写。影响访问的常见因素有clock和memory controller的设置、init sequence、以及硬件布线等。

Step 2: 检测网络连接状态
一般通过读取PHY中相关寄存器的值即可确定连接状态。以DM9161 PHY为例，可读取reg 1（连接状态）和reg 17（连接速度）

Step 3:  接收数据包(polling mode)
中断可能会带来一些不确定的因素，开始调试时不妨使用polling mode。其实，即使在开发完成后，仍需保留polling mode，如Linux Kernel中的NAPI技术。

Step 4: 发送数据包
一般建议先做recv再做send。别外别忘了借助wireshark、tcpdump等工具来帮你调试

Step 5: 启用中断及DMA，在中断服务例程(ISR)中接收数据包
好了，现在收发都OK了，启用中断和DMA吧

Step 6: 将代码移植到Linux内核中
只需要将驱动的framework稍作调整即可，这一步只是个手工活。
好了，现在你的linux网卡驱动可以工作了，基本功能已经实现，测试一下看?

Step 7: 完善你的Linux网卡驱动
支持电源管理、eth tool等

Answer 1

{:3_179:}

很久没有见版主过来了，嘿嘿

Answer 2

本帖最后由 lasting007 于 2010-02-25 22:13 编辑

小弟认为先测试接收数据是否成功，这样排除由于发送数据侦不符合协议规范而造成接收端不可显示收到的数据

Answer 3

先测试recv,再测试send. 偶觉得这样在做send测试时，可以排除recv应答包出问题的概率，从而可以专注于数据帧格式以及相关register的调试。

Answer 4

在这个step 3:接收数据和step 4:发送数据，二步中的顺序中。我是这样的认为：二者的区别在于要不要上层软件的支持。
接收数据时，可以不要上层软件的支持，而发送数据要上层软件程序的支持，所以如果先没接收数据，可以更容易的测试硬件，而不必支关心上层软件是否正常工作。

Answer 5

我认为收包只需进行简单的寄存器读写即可，出现问题容易跟踪，而发包除了要向数据端口写数据外，还要发命令，还要进行组包，这些都可能导致发送出错。
因此，发包的不确定因素比收包多得多，如果先发包则难以调试。

Answer 6

回复 1# conke

    相对于接收，要成功发送一个数据包的条件要多，除了设置TX_CMD register, 还要正确设置TX_LENGTH register,
象楼上讲的，需要应用软件支持，正确组包并计算每个包大小。

Answer 7

我认为网卡先做收，再做发，有以下几点好处：
    1：如果收到数据，可以判断先前寄存器配置的正确性。
    2：先做发的话，应为包时直接从驱动层发的，需要按照一定的格式去组包，
       这个时候如果主机端收不到包的的话没法判断时寄存器设置问题，还是
       包的格式错误。

Answer 8

本帖最后由 HELLO_MAX 于 2010-02-27 02:05 编辑

发包由于设计到组包格式的缘故，设计到的相应寄存器要多，需要设置的寄存器多了，那么设置寄存器的顺序也相应复杂化；其中组包又要有相应的格式问题，比如大小端等。所以如果出问题了，相对于接包，出错了不容易定位。

Answer 9

偶认为先做recv,再做send的好处是：先确保recv寄存器的设置正确，再做send,这样可以排除包格式出错的干扰!