s3c2410 基于linux2.6的 cs8900网卡的移植

s3c2410 基于linux2.6的 cs8900网卡的移植
2007-07-24 15:34
硬件环境：SBC-2410X开发板（CPU：S3C2410X）
内核版本：2.6.11.1
运行环境：Debian2.6.8
交叉编译环境：gcc-3.3.4-glibc-2.3.3
第一部分 网卡CS8900A驱动程序的移植
一、从网上将Linux内核源代码下载到本机上，并将其解压：
#tar jxf linux-2.6.11.1.tar.bz2
二、打开内核顶层目录中的Makefile文件，这个文件中需要修改的内容包括以下两个方面。
（1）指定目标平台。
移植前：
        ARCH?= $(SUBARCH)
移植后：
ARCH            :=arm
（2）指定交叉编译器。
移植前：
CROSS_COMPILE ?=
移植后：
CROSS_COMPILE   :=/opt/crosstool/arm-s3c2410-linux-gnu/gcc-3.3.4-glibc-2.3.3/bin/arm-s3c2410-linux-gnu-
注：这里假设编译器就放在本机的那个目录下。
三、添加驱动程序源代码，这涉及到以下几个方面。（1）、从网上下载了cs8900.c和cs8900.h两个针对2.6.7的内核的驱动程序源代码，将其放在drivers/net/arm/目录下面。
#cp cs8900.c ./drivers/net/arm/
#cp cs8900.h ./drivers/net/arm/
并在cs8900_probe()函数中，memset (&priv,0,sizeof (cs8900_t));函数之后添加如下两条语句：
__raw_writel(0x2211d110,S3C2410_BWSCON);
__raw_writel(0x1f7c,S3C2410_BANKCON3);
注：其原因在"第二部分"解释。
（2）、修改drivers/net/arm/目录下的Kconfig文件，在最后添加如下内容：
Config ARM_CS8900
   tristate "CS8900 support"
depends on NET_ETHERNET && ARM && ARCH_SMDK2410
help
   Support for CS8900A chipset based Ethernet cards. If you have a network (Ethernet) card of this type, say Y and read the Ethernet-HOWTO, available from as well as .
   To compile this driver as a module, choose M here and read
. The module will be
   called cs8900.o.
注：内核系统配置文件由2.4版本的config.in变成了2.6版本Kconfig文件，在这个文件里面添加如上内容，则在运行make menuconfig或者make xconfig命令的时候就会出现：
        [ ]   CS8900 support
这一选项。
（3）、修改drivers/net/arm/目录下的Makefile文件，在最后添加如下内容：
obj-$(CONFIG_ARM_CS8900)    += cs8900.o
注：2.6版本内核的Makefile文件也与2.4版本的有所不同。添加以上语句，就会使内核在编译的时候根据配置将cs8900A的驱动程序以模块或静态的方式编译到内核当中。
（4）、在/arch/arm/mach-s3c2410/mach-smdk2410.c文件中，找到smdk2410_iodesc[]结构数组，添加如下如下内容：{vSMDK2410_ETH_IO, 0x19000000, SZ_1M, MT_DEVICE}
修改之后变成了：
static struct map_desc smdk2410_iodesc[] __initdata = {
       /* nothing here yet */
        /* Map the ethernet controller CS8900A */        {vSMDK2410_ETH_IO, 0x19000000, SZ_1M, MT_DEVICE}
};
注：由于在驱动程序的开发的时候，在驱动程序当中所用到的跟设备有关的地址都是虚拟地址，也就是说驱动程序操作的都是虚拟地址，那么要使驱动程序对设备的 操作反映到设备上去，就得将设备的物理地址映射到正确的虚拟地址上去，从而保证驱动程序对虚拟地址的操作也就是对相应的物理地址操作。以上添加的语句就是 为了将网卡的物理地址(0x19000000)映射到vSMDK2410_ETH_IO所指向的虚拟地址上去，上面的结构还定义了网卡虚拟地址所占用的区 间，也就是从vSMDK2410_ETH_IO开始的SZ_1M大小的去间，并指定了该区间所指向的域（的属性）。（疑问：在本开发板上，网卡占用的是 CPU的nGCS3片选信号，也就是在Bank3，根据处理器的地址空间定义，这个地址应该是0x18000000，为什么这里使用的是 0x19000000？查找到2.4.18的内核当中，也是用0x19000000来进行映射。）
（5）、在include/asm-arm/arch-s3c2410/目录下创建smdk2410.h文件，其内容为：
#ifndef _INCLUDE_SMDK2410_H_
#define _INCLUDE_SMDK2410_H_
#include
#define pSMDK2410_ETH_IO        0x19000000
#define vSMDK2410_ETH_IO   0xE0000000
#define SMDK2410_ETH_IRQ    IRQ_EINT9
#endif // _INCLUDE_SMDK2410_H_
注：因为在网卡驱动程序当中，用到了一些常量，所以特意在此添加这个头文件。这个头文件定义了网卡的物理地址、虚拟地址以及网卡占用的中断线。
四、配置、编译内核。在内核顶层目录当中键入：
   #make smdk2410_defconfig
由于2.6的内核默认就支持了S3C2410，所以就有一个默认的内核配置文件。里面只是包括了一个简单的配置，要使网卡编译进内核，还要进行手工配置。
#make menuconfig
       Networking support --->  
Ethernet (10 or 100Mbit) --->
[*]   CS8900 support
将刚才添加的网卡驱动程序静态添加到内核当中。
最后进行内核编译。
#make
然后将镜像下载到开发板中去。
第二部分 问题解析
在移植网卡的过程中，并不是一帆风顺的，整个过程遇到了问题虽然不多，但是去寻找问题的原因及解决的办法的时候却是非常曲折的。现在将本人在进行网卡驱动移植过程中所遇到的问题以及解决方法介绍如下。
因 为经验不足，刚开始进行工作的时候，没有将移植的思路明确。最先是打算将开发板供应商随板提供的2.4.18内核下的驱动程序cs8900a.c移植到 2.6.10的内核下。首先就是计划先以编译模块的方式将该程序编译通过之后，再将起编译到2.6.10的内核当中，然后再对其进行逻辑上的修改。在模块 编译该驱动程序的时候，首先碰到的问题就是头文件的问题，根据编译的出错信息，挨个将头文件添加好了。此时碰到的问题就是交叉编译器（arm- s3c2410-linux-gnu-gcc）编译到cs89x0_probe（）函数的时候出错。指向：BWSCON这一行，出错信息是：
Incorrect Lvalue in assignment
后 来查阅内核源代码，跟踪BWSCON的定义，其实它是指向一个常量地址的指针。在用2.95.3的交叉编译器对其进行编译的时候不会出错，而用3.3.4 的交叉编译器进行便宜的时候却出错，于是怀疑是跟编译器有关。将对BWSCON和BANKCON3的赋值操作这两条语句注释掉之后就不会报错，所以肯定了 在3.3.4版本的交叉编译器不支持这样的操作。原来以为这两条语句是对别的某个寄存器进行的操作，对网卡驱动没什么影响，于是就将注释之后的驱动程序加 入到2.6.10的内核当中进行编译，并下载到开发板当中。这个时候从串口打回控制台的出错消息是在很长时间内都无法解决的。如下：
Cirrus Logic CS8900A driver for Linux (Modified for SMDK2410)
         eth0: incorrect signature 0x1005
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
NET: Registered protocol family 1
IP-Config: Device `eth0' not found.
Looking up port of RPC 100003/2 on 192.168.0.1
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.0.1
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get mountd port number from server, using default RPC: sendmsg returned error 101
mount: RPC call returned error 101
Root-NFS: Server returned error -101 while mounting /friendly-arm/root
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
     观察串口打印的信息，发现vivi正确启动了内核，内核也对cpu进行了初始化，但是网卡就是无法驱动起来。核对驱动程序源代码，发现在内核初始化网卡 时，运行到了cs89x0_probe1()函数的时候，探测网卡的ProductID的时候读回的数据不是网卡的ID：0x630e。也就是没探测到网 卡而退出了cs89x0_probe1()函数。当时怀疑的是2.4.18的驱动程序跟2.6.10的设备驱动程序写法有很多不同，如果继续这样的工作， 也许工作量很大，所以马上转变了工作思路，决定从网上下载2.6的CS8900A的驱 动程序，在搜索了很长时间之后，终于在一个网站上下载到了2.6.7内核下的CS8900A的驱动程序。按照"第一部分"的步骤加进了驱动之后，下载新的 内核，串口回传的信息跟上面的信息是一样的。
重新启动开发板，问题依然存在，但是仔细对比了cs89x0_probe1()函数读回来的数据，发现这个signature在变化，而且没有找到其变化的规律。
查 看了驱动程序以及CS8900A的Datasheet，发现驱动程序的逻辑是正确的，于是首先怀疑是在驱动程序中，网卡iobase的物理地址不对，于是 查看开发板的原理图，发现网卡用的是cpu的nGCS3片选信号，该片选信号对应的地址空间起始地址是0x18000000，而在驱动中对用的是 0x19000000，于是修改arch/arm/mach-s3c2410/mach-smdk2410.c文件中的mdk2410_iodesc[] 结构对io地址的映射，将物理地址改为0x18000000，重新编译后网卡仍然无法被驱动，只是这个时候驱动程序读来的数据也就是那个 signature不会因为每次重起而改变的，也就是每次读回来的数据都是固定的。这时又怀疑是虚拟地址不正确。将2.6的驱动与2.4的驱动进行了比 较，发现2.4用的 虚拟地址是0xd000000，于是修改2.6内核中的虚拟地址为0xe000000,可是网卡还是无法驱动，反复修改了虚拟地址和物理地址，问题依旧存 在。这个时候思路几乎停止。经过思考之后，把工作的思路定位在比较2.4和2.6的驱动程序的区别上，经过仔细的比较，发现在2.4的驱动程序当中在 cs89x0_probe1()函数里有对寄存器的设置，而2.6的驱动程序则没有，查找cpu的Datasheet，发现该设置是对cpu内部两个重要 的控制器的设置。下面先介绍一下这两个寄存器。
在S3C2410X中BWSCON是Bus width & wait control register（总线宽度及等待控制寄存器），这个寄存器控制着系统地址空间内（包括bank0-bank7）的总线数据宽度以及是否等待。 BANKCONn(n=0~7)寄存器是Bank control register。这个寄存器控制着处于某个bank区间内的总线的地址setup的时钟周期，片选信号的保持时间，访问周期等。这个两个寄存器中每个位 的含义可以参见S3C2410X数据手册的5-13~5-15，在此不加以详叙。
查看了cpu的数据手册、开发板原理图以及2.4的驱动程序之后，发现在2.4的驱动程序中的以下两条语句：
BWSCON = (BWSCON & ~(BWSCON_ST3 | BWSCON_WS3 | BWSCON_DW3)) | (BWSCON_ST3 | BWSCON_WS3 | WSCON_DW(3, BWSCON_DW_16));
BANKCON3= BANKCON_Tacs0 | BANKCON_Tcos4 | BANKCON_Tacc14 | BANKCON_Toch1 | BANKCON_Tcah4 | BANKCON_Tacp6 | BANKCON_PMC1;
实际上是对地址区间BANK3（因为开发板用的的是nGCS3，处于BANKCON3区间内）进行了设置。
先 看对BWSCON的设置，这条语句实际上是要使BWSCON中除了ST3、WS3和DW3这四个位的其它各位得到保护，使ST3、WS3和DW3这四个位 清零，然后再对ST3、WS3和DW3这四个位进行设置，经过这条语句之后，ST3、WS3和DW3这四个位被设置成了1101（二进制），意思就是对 BANK3采用cpu引脚（A17、B16、C15、A16，这几个引脚都分别有三种信号表示意义）的nBE信号（具体什么意思，本人也不知道），对 BANK3使用WAIT enable，使用16位的数据总线宽度。
其次就是对BANKCON3寄存器的设置。这条语句将BANKCON3设置成了0001 1111 0111 1100。（各个位的意思，我也没弄明白什么意思，估计就是设置各种操作的时钟周期数目。）
清楚了驱动程序对寄存器的设置之后，就想到应该在vivi里面对cpu的这几个内存控制寄存器进行设置，于是找到vivi源代码中include/platform/目录下的smdk.h文件中对寄存器的初始化值的设置，修改之后如下：
/*#define vBWSCON               0x22111120*/
#define vBWSCON                 0x2211d110
#define vBANKCON0               0x00000700
#define vBANKCON1               0x00000700
#define vBANKCON2             0x00000700
#define vBANKCON3               0x00001f7c
#define vBANKCON4             0x00000700
#define vBANKCON5               0x00001f7c
#define vBANKCON6               0x00018005
#define vBANKCON7               0x00018005
#define vREFRESH                0x008e0459
#define vBANKSIZE               0xb2
#define vMRSRB6                 0x30
#define vMRSRB7                 0x30
重 新通过JTAG口下载vivi，重新启动内核后，发现问题依然存在，于是就想到在驱动程序里面添加对内存控制器的设置。最开始是想模仿2.4的驱动程序那 样，找到各个相应的宏去代替2.4驱动程序里的宏，在memset()函数之前添加，但是编译的时候出错，出错信息是：
LValue incorrect in assignment
跟踪内核的代码发现对S3C2410_BWSCON、S3C2410_BANKCON3宏的定义分别返回的其实是一个常量，分别是0xf0100000和0xf0100010，这个常量是右值，不能当左值。因此就想到采用如下直接对地址进行赋值的方式对寄存器进行设置：
*(volatile unsigned short __force *)(0xf0100000)=(0x2211d110)；
*(volatile unsigned short __force *)(0xf0100010)=(0x00001f7c);
后来运行内核时发现，驱动程序初始化到了memset()函数之后，上述两条语句之前就停止不动了（疑问：不知道这是什么原因）。最后查找linux内核代码找到了__raw_writell(v,a)这样一个函数，于是就将上述两条语句替换成：
__raw_writel(0x2211d110,S3C2410_BWSCON);
__raw_writel(0x1f7c,S3C2410_BANKCON3);
这样经过设置内存控制寄存器之后，网卡终于被驱动起来了。但是由于在移植的过程中没有将内核对devfs设备文件系统的支持编译进内核里面去，所以当网卡驱动之后去寻找网络文件系统的时候发现找不到根文件系统，最后在配置内核的时候将devfs的支持加入，如下：
File systems --->
Pseudo filesystems --->
     [*] /dev file system support (OBSOLETE)
之后，linux可以从主机上找到根文件系统，并创建init进程。这样，网卡驱动程序经过接近三周的时间终于被驱动了！