ENC28J60 SPI网卡移植 linux 2.6.28 SAMSUNG 6410 ARM11

目录

1       概述：... 2

2       已经移植好的驱动下载：... 2

3       驱动相关文件：... 3

4       内核配置：... 3

5       SPI驱动结构：... 4

6       在SPI总线上挂接设备：... 5

7       修改SPI时钟极性，匹配ENC28J60：... 6

8       编译内核：... 7

9       修复BUG1：SPI驱动接收数据后无时钟输出：... 7

9.1        正常时的设备节点：... 8

9.2        手工发送测试：... 8

9.3        手工接收测试：... 8

9.4        错误波形：... 9

9.5        正确波形：... 10

9.6        代码修改说明：... 10

10     ENC28J60网卡：... 12

10.1          电路参考图：... 12

10.2          网卡流程图：... 13

10.3          中断处理：... 13

10.3.1           新增中断GPIO配置函数：... 13

10.3.2           修改enc28j60_probe（）, enc28j60_irq（）函数：... 14

11         修复BUG2，SPI传输丢失数据：... 14

11.1          首先看Iris抓包情况：... 15

11.2          分析SPI通讯波形：... 15

11.3          代码修改说明：... 16

12         测试结果：... 17

13         从NFS启动测试：... 18

14         相关链接：... 19

 

 

1      概述：

 

移植平台：linux2.6.28

开发板：飞凌TE6410 (256M RAM2G NAND)

网卡：ENC28J60 SPI

测试用的工具：Saleae logic （逻辑分析仪），Iris 抓包工具

 

6410作为一颗强大的ARM11处理器，网卡模块已经是相当的成熟（如：DM9000/3RTL8139等），移植工作几乎易如反掌，在此去移植一颗ENC28J6010M SPI网卡，是否有些搞笑，但是ENC28J60的超小体积和IO脚（28PIN），以及几块钱的价格，在单片机领域网卡占用一定市场，对于网络环境要求不高的产品还是可以考虑的，况且内核已经提供了驱动程序（其中的SPI BUG还不少，花费了近2周的时间）。当然不一定是要在6410上移植，本例只是抛砖引玉，供大家学习讨论。

 

欢迎讨论：QQ：67016879 EMAIL：[e-mail]

 

2      已经移植好的驱动下载：

（附件）http://download.csdn.net/detail/lxj_com2006/3779598

注：代码内容以本例附件文件代码为准，本文未提及的修改为测试用或参考部分，非特别重点。

 

3      驱动相关文件：

ENC28J60驱动：drivers/net/enc28j60.c 头文件：drivers/net/enc28j60_hw.h

6410 SPI驱动：drivers/spi/spi_sam.c 头文件：drivers/spi/spi_sam.h

SPI用户接口：drivers/spi/spidev.c头文件：linux2.6.28\include\linux\spi\spidev.h

 

SPI总线设备挂接：arch/arm/mach-s3c6410/mach-smdk6410.c

linux SPI接口（与设备无关）：drivers/spi/spi.c 头文件：linux2.6.28\include\linux\spi\spi.h

 

 

4      内核配置：

linux2.6.28内核自带了6410 SPI驱动和ENC28J60驱动，找到对应位置打开相应配置，重新编译，驱动将被编译到内核，本例将驱动均编译到内核，没有采用模块（.ko）形式。

 

5      SPI驱动结构：

由linux提供两个与设备无关的IO函数spi_write和spi_read使SPI外部设备和SPI总线接口，当外部设备read或write 时，最终会回到spi_sam.c的handle_msg()函数进行处理，如：DMA队列处理，允许DMA，开启SPI TX,RX等，最后物理上数据从总线获取或被发送。

 

6      在SPI总线上挂接设备：

arch/arm/mach-s3c6410/mach-smdk6410.c

修改挂接到的设备，其它参数默认

 

7      修改SPI时钟极性，匹配ENC28J60：

ENC28J60采用SPI0模式（SPI共四种通讯模式，请参考相关文档），即时钟上升沿接收数据，下降沿发送数据，片选低电平有效。为了简单起见，本例直接修改程序，并没有采用非常规范的修改方式：

 

8      编译内核：

完成上述步骤后，可以尝试编译内核，一般情况不会出现错误。

 

9      修复BUG1：SPI驱动接收数据后无时钟输出：

编译内核后，启动测试（本例使用双网卡nfs测试，最后只留ENC28J60网卡烧入nand测试），

如果正确应该会出现/dev/spidev1.0（或spidev0.0看如何挂接配置）类似设备文件，如果没有，请检查arch/arm/mach-s3c6410/mach-smdk6410.c文件，查看设备驱动是否挂载正确，spidev驱动会自动创建设备节点，所以不用手工mknod。

 

9.1    正常时的设备节点：

 

9.2    手工发送测试：

echo "ABC" > /dev/spidev1.0

 

9.3    手工接收测试：

cat /dev/spidev1.0

注：如果需要收发二进制可使用 dump 命令，在此cat只是测试字符。

 

经过测试，单独发送，接收，用逻辑分析仪（taobao有卖，50元左右）抓波形，均正常，可是进行混合操作后，如：先发送，再接收，再次发送，之后时钟信号没有了，片选正常，抓到的波形如下：

 

9.4    错误波形：

9.5    正确波形：

 

9.6    代码修改说明：

分析：应该是在接收数据后，使用了SAMSPI_PACKET_CNT（字节总数寄存器），而发送没有开启，所以将改成与接收对应，问题解决。

 

10            ENC28J60网卡：

10.1       电路参考图：

10.2       网卡流程图：

10.3       中断处理：

drivers/net/enc28j60.c

10.3.1     新增中断GPIO配置函数：

配置6410 GPIO的INT16（连接到ENC28J60的中断脚）：

10.3.2     修改enc28j60_probe（）, enc28j60_irq（）函数：

 

11            修复BUG2，SPI传输丢失数据：

通过以上代码修改，编译测试，可以看到 eth0:link up，证明和网卡SPI通讯基本正常，但是ping不通，经过分析代码，抓波形，Iris网络抓包，查到在发送大一点的数据时，SPI时序有错，片选信号没有了，导致有数据未完全送出：

 

11.1       首先看Iris抓包情况：

通过Iris网络抓包分析，可以初步确定问题还是出在SPI通讯上。

 

11.2       分析SPI通讯波形：

果然是SPI通讯有错误，在未通讯完时，片选信号停掉了，导致网卡读到的数据错误，把FIFO以前的数据发送出去了。

 

11.3       代码修改说明：

通过代码分析，主要原因在于，DMA开启，SPI TX,RX ENABLE后进入status =wait_for_xfer(sspi, xfer); 即等待数据被完全送出/接收，但是实际效果并非如此，wait_for_xfer()函数也是通过等待中断返回状态，决定是否发送成功，再做后续处理，思路没错，出于时间原因，没有花更多时间去研究，本例提出的解决办法也不算很好，但可以解决（就是做延时处理），以便下一步，等整个流程调通在回头深究：

drivers/spi/spi_sam.c

handle_msg()

 

12            测试结果：

到此网卡已经可以ping通，TCP连接/收发测试OK。

注：由于延时原因，导致PING时，响应时间过慢，time=557ms。

 

13            从NFS启动测试：

做为简单少量数据通讯时，效果还可以，但使用数据量比较大时，显得比较慢，测试从nfs启动一个100多M的文件系统，居然花了半个小时，并且中间出现丢包现象，网卡重启数次。抓包分析，发送没有问题，不知为何nfs不回应。用另一张网卡测试nfs服务器正常。

 

看来还存在很多不足，需要改进的地方不少。不过ENC28J60做为在ARM11平台使用，确实意义不大。

 

 

14            相关链接：

ENC28J60 驱动补丁，修复nfs启动时与控制台死锁：

https://lkml.org/lkml/2009/3/25/207

附件代码已经打上此补丁

 

nfs启动参数，支持UDP，TCP：

http://blog.csdn.net/do2jiang/article/details/4950613

upd,tcp均测试，丢包原因仍在驱动中