| 硬件環(huán)境：SBC-2410X開(kāi)發(fā)板（CPU：S3C2410X） 內核版本：2.6.11.1 運行環(huán)境：Debian2.6.8 交叉編譯環(huán)境：gcc-3.3.4-glibc-2.3.3 第一部分 網(wǎng)卡CS8900A驅動(dòng)程序的移植 一、從網(wǎng)上將Linux內核源代碼下載到本機上，并將其解壓： #tar jxf linux-2.6.11.1.tar.bz2 二、打開(kāi)內核頂層目錄中的Makefile文件，這個(gè)文件中需要修改的內容包括以下兩個(gè)方面。 （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- 注：這里假設編譯器就放在本機的那個(gè)目錄下。 三、添加驅動(dòng)程序源代碼，這涉及到以下幾個(gè)方面。（1）、從網(wǎng)上下載了cs8900.c和cs8900.h兩個(gè)針對2.6.7的內核的驅動(dòng)程序源代碼，將其放在drivers/net/arm/目錄下面。 #cp cs8900.c ./drivers/net/arm/ #cp cs8900.h ./drivers/net/arm/ 并在cs8900_probe()函數中，memset (&priv,0,sizeof (cs8900_t));函數之后添加如下兩條語(yǔ)句： __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文件，在這個(gè)文件里面添加如上內容，則在運行make menuconfig或者make xconfig命令的時(shí)候就會(huì )出現： [ ] CS8900 support 這一選項。 （3）、修改drivers/net/arm/目錄下的Makefile文件，在最后添加如下內容： obj-$(CONFIG_ARM_CS8900) += cs8900.o 注：2.6版本內核的Makefile文件也與2.4版本的有所不同。添加以上語(yǔ)句，就會(huì )使內核在編譯的時(shí)候根據配置將cs8900A的驅動(dòng)程序以模塊或靜態(tài)的方式編譯到內核當中。 （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} }; 注：由于在驅動(dòng)程序的開(kāi)發(fā)的時(shí)候，在驅動(dòng)程序當中所用到的跟設備有關(guān)的地址都是虛擬地址，也就是說(shuō)驅動(dòng)程序操作的都是虛擬地址，那么要使驅動(dòng)程序對設備的 操作反映到設備上去，就得將設備的物理地址映射到正確的虛擬地址上去，從而保證驅動(dòng)程序對虛擬地址的操作也就是對相應的物理地址操作。以上添加的語(yǔ)句就是 為了將網(wǎng)卡的物理地址(0x19000000)映射到vSMDK2410_ETH_IO所指向的虛擬地址上去，上面的結構還定義了網(wǎng)卡虛擬地址所占用的區 間，也就是從vSMDK2410_ETH_IO開(kāi)始的SZ_1M大小的去間，并指定了該區間所指向的域（的屬性）。（疑問(wèn)：在本開(kāi)發(fā)板上，網(wǎng)卡占用的是 CPU的nGCS3片選信號，也就是在Bank3，根據處理器的地址空間定義，這個(gè)地址應該是0x18000000，為什么這里使用的是 0x19000000？查找到2.4.18的內核當中，也是用0x19000000來(lái)進(jìn)行映射。） （5）、在include/asm-arm/arch-s3c2410/目錄下創(chuàng )建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_ 注：因為在網(wǎng)卡驅動(dòng)程序當中，用到了一些常量，所以特意在此添加這個(gè)頭文件。這個(gè)頭文件定義了網(wǎng)卡的物理地址、虛擬地址以及網(wǎng)卡占用的中斷線(xiàn)。 四、配置、編譯內核。在內核頂層目錄當中鍵入： #make smdk2410_defconfig 由于2.6的內核默認就支持了S3C2410，所以就有一個(gè)默認的內核配置文件。里面只是包括了一個(gè)簡(jiǎn)單的配置，要使網(wǎng)卡編譯進(jìn)內核，還要進(jìn)行手工配置。 #make menuconfig Networking support ---> Ethernet (10 or 100Mbit) ---> [*] CS8900 support 將剛才添加的網(wǎng)卡驅動(dòng)程序靜態(tài)添加到內核當中。 最后進(jìn)行內核編譯。 #make 然后將鏡像下載到開(kāi)發(fā)板中去。 第二部分 問(wèn)題解析 在移植網(wǎng)卡的過(guò)程中，并不是一帆風(fēng)順的，整個(gè)過(guò)程遇到了問(wèn)題雖然不多，但是去尋找問(wèn)題的原因及解決的辦法的時(shí)候卻是非常曲折的?，F在將本人在進(jìn)行網(wǎng)卡驅動(dòng)移植過(guò)程中所遇到的問(wèn)題以及解決方法介紹如下。 因 為經(jīng)驗不足，剛開(kāi)始進(jìn)行工作的時(shí)候，沒(méi)有將移植的思路明確。最先是打算將開(kāi)發(fā)板供應商隨板提供的2.4.18內核下的驅動(dòng)程序cs8900a.c移植到 2.6.10的內核下。首先就是計劃先以編譯模塊的方式將該程序編譯通過(guò)之后，再將起編譯到2.6.10的內核當中，然后再對其進(jìn)行邏輯上的修改。在模塊 編譯該驅動(dòng)程序的時(shí)候，首先碰到的問(wèn)題就是頭文件的問(wèn)題，根據編譯的出錯信息，挨個(gè)將頭文件添加好了。此時(shí)碰到的問(wèn)題就是交叉編譯器（arm- s3c2410-linux-gnu-gcc）編譯到cs89x0_probe（）函數的時(shí)候出錯。指向：BWSCON這一行，出錯信息是： Incorrect Lvalue in assignment 后 來(lái)查閱內核源代碼，跟蹤BWSCON的定義，其實(shí)它是指向一個(gè)常量地址的指針。在用2.95.3的交叉編譯器對其進(jìn)行編譯的時(shí)候不會(huì )出錯，而用3.3.4 的交叉編譯器進(jìn)行便宜的時(shí)候卻出錯，于是懷疑是跟編譯器有關(guān)。將對BWSCON和BANKCON3的賦值操作這兩條語(yǔ)句注釋掉之后就不會(huì )報錯，所以肯定了 在3.3.4版本的交叉編譯器不支持這樣的操作。原來(lái)以為這兩條語(yǔ)句是對別的某個(gè)寄存器進(jìn)行的操作，對網(wǎng)卡驅動(dòng)沒(méi)什么影響，于是就將注釋之后的驅動(dòng)程序加 入到2.6.10的內核當中進(jìn)行編譯，并下載到開(kāi)發(fā)板當中。這個(gè)時(shí)候從串口打回控制臺的出錯消息是在很長(cháng)時(shí)間內都無(wú)法解決的。如下： 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) 觀(guān)察串口打印的信息，發(fā)現vivi正確啟動(dòng)了內核，內核也對cpu進(jìn)行了初始化，但是網(wǎng)卡就是無(wú)法驅動(dòng)起來(lái)。核對驅動(dòng)程序源代碼，發(fā)現在內核初始化網(wǎng)卡 時(shí)，運行到了cs89x0_probe1()函數的時(shí)候，探測網(wǎng)卡的ProductID的時(shí)候讀回的數據不是網(wǎng)卡的ID：0x630e。也就是沒(méi)探測到網(wǎng) 卡而退出了cs89x0_probe1()函數。當時(shí)懷疑的是2.4.18的驅動(dòng)程序跟2.6.10的設備驅動(dòng)程序寫(xiě)法有很多不同，如果繼續這樣的工作， 也許工作量很大，所以馬上轉變了工作思路，決定從網(wǎng)上下載2.6的CS8900A的驅 動(dòng)程序，在搜索了很長(cháng)時(shí)間之后，終于在一個(gè)網(wǎng)站上下載到了2.6.7內核下的CS8900A的驅動(dòng)程序。按照"第一部分"的步驟加進(jìn)了驅動(dòng)之后，下載新的 內核，串口回傳的信息跟上面的信息是一樣的。 重新啟動(dòng)開(kāi)發(fā)板，問(wèn)題依然存在，但是仔細對比了cs89x0_probe1()函數讀回來(lái)的數據，發(fā)現這個(gè)signature在變化，而且沒(méi)有找到其變化的規律。 查 看了驅動(dòng)程序以及CS8900A的Datasheet，發(fā)現驅動(dòng)程序的邏輯是正確的，于是首先懷疑是在驅動(dòng)程序中，網(wǎng)卡iobase的物理地址不對，于是 查看開(kāi)發(fā)板的原理圖，發(fā)現網(wǎng)卡用的是cpu的nGCS3片選信號，該片選信號對應的地址空間起始地址是0x18000000，而在驅動(dòng)中對用的是 0x19000000，于是修改arch/arm/mach-s3c2410/mach-smdk2410.c文件中的mdk2410_iodesc[] 結構對io地址的映射，將物理地址改為0x18000000，重新編譯后網(wǎng)卡仍然無(wú)法被驅動(dòng)，只是這個(gè)時(shí)候驅動(dòng)程序讀來(lái)的數據也就是那個(gè) signature不會(huì )因為每次重起而改變的，也就是每次讀回來(lái)的數據都是固定的。這時(shí)又懷疑是虛擬地址不正確。將2.6的驅動(dòng)與2.4的驅動(dòng)進(jìn)行了比 較，發(fā)現2.4用的 虛擬地址是0xd000000，于是修改2.6內核中的虛擬地址為0xe000000,可是網(wǎng)卡還是無(wú)法驅動(dòng)，反復修改了虛擬地址和物理地址，問(wèn)題依舊存 在。這個(gè)時(shí)候思路幾乎停止。經(jīng)過(guò)思考之后，把工作的思路定位在比較2.4和2.6的驅動(dòng)程序的區別上，經(jīng)過(guò)仔細的比較，發(fā)現在2.4的驅動(dòng)程序當中在 cs89x0_probe1()函數里有對寄存器的設置，而2.6的驅動(dòng)程序則沒(méi)有，查找cpu的Datasheet，發(fā)現該設置是對cpu內部?jì)蓚€(gè)重要 的控制器的設置。下面先介紹一下這兩個(gè)寄存器。 在S3C2410X中BWSCON是Bus width & wait control register（總線(xiàn)寬度及等待控制寄存器），這個(gè)寄存器控制著(zhù)系統地址空間內（包括bank0-bank7）的總線(xiàn)數據寬度以及是否等待。 BANKCONn(n=0~7)寄存器是Bank control register。這個(gè)寄存器控制著(zhù)處于某個(gè)bank區間內的總線(xiàn)的地址setup的時(shí)鐘周期，片選信號的保持時(shí)間，訪(fǎng)問(wèn)周期等。這個(gè)兩個(gè)寄存器中每個(gè)位 的含義可以參見(jiàn)S3C2410X數據手冊的5-13~5-15，在此不加以詳敘。 查看了cpu的數據手冊、開(kāi)發(fā)板原理圖以及2.4的驅動(dòng)程序之后，發(fā)現在2.4的驅動(dòng)程序中的以下兩條語(yǔ)句： 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; 實(shí)際上是對地址區間BANK3（因為開(kāi)發(fā)板用的的是nGCS3，處于BANKCON3區間內）進(jìn)行了設置。 先 看對BWSCON的設置，這條語(yǔ)句實(shí)際上是要使BWSCON中除了ST3、WS3和DW3這四個(gè)位的其它各位得到保護，使ST3、WS3和DW3這四個(gè)位 清零，然后再對ST3、WS3和DW3這四個(gè)位進(jìn)行設置，經(jīng)過(guò)這條語(yǔ)句之后，ST3、WS3和DW3這四個(gè)位被設置成了1101（二進(jìn)制），意思就是對 BANK3采用cpu引腳（A17、B16、C15、A16，這幾個(gè)引腳都分別有三種信號表示意義）的nBE信號（具體什么意思，本人也不知道），對 BANK3使用WAIT enable，使用16位的數據總線(xiàn)寬度。 其次就是對BANKCON3寄存器的設置。這條語(yǔ)句將BANKCON3設置成了0001 1111 0111 1100。（各個(gè)位的意思，我也沒(méi)弄明白什么意思，估計就是設置各種操作的時(shí)鐘周期數目。） 清楚了驅動(dòng)程序對寄存器的設置之后，就想到應該在vivi里面對cpu的這幾個(gè)內存控制寄存器進(jìn)行設置，于是找到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 重 新通過(guò)JTAG口下載vivi，重新啟動(dòng)內核后，發(fā)現問(wèn)題依然存在，于是就想到在驅動(dòng)程序里面添加對內存控制器的設置。最開(kāi)始是想模仿2.4的驅動(dòng)程序那 樣，找到各個(gè)相應的宏去代替2.4驅動(dòng)程序里的宏，在memset()函數之前添加，但是編譯的時(shí)候出錯，出錯信息是： LValue incorrect in assignment 跟蹤內核的代碼發(fā)現對S3C2410_BWSCON、S3C2410_BANKCON3宏的定義分別返回的其實(shí)是一個(gè)常量，分別是0xf0100000和0xf0100010，這個(gè)常量是右值，不能當左值。因此就想到采用如下直接對地址進(jìn)行賦值的方式對寄存器進(jìn)行設置： *(volatile unsigned short __force *)(0xf0100000)=(0x2211d110)； *(volatile unsigned short __force *)(0xf0100010)=(0x00001f7c); 后來(lái)運行內核時(shí)發(fā)現，驅動(dòng)程序初始化到了memset()函數之后，上述兩條語(yǔ)句之前就停止不動(dòng)了（疑問(wèn)：不知道這是什么原因）。最后查找linux內核代碼找到了__raw_writell(v,a)這樣一個(gè)函數，于是就將上述兩條語(yǔ)句替換成： __raw_writel(0x2211d110,S3C2410_BWSCON); __raw_writel(0x1f7c,S3C2410_BANKCON3); 這樣經(jīng)過(guò)設置內存控制寄存器之后，網(wǎng)卡終于被驅動(dòng)起來(lái)了。但是由于在移植的過(guò)程中沒(méi)有將內核對devfs設備文件系統的支持編譯進(jìn)內核里面去，所以當網(wǎng)卡驅動(dòng)之后去尋找網(wǎng)絡(luò )文件系統的時(shí)候發(fā)現找不到根文件系統，最后在配置內核的時(shí)候將devfs的支持加入，如下： File systems ---> Pseudo filesystems ---> [*] /dev file system support (OBSOLETE) 之后，linux可以從主機上找到根文件系統，并創(chuàng )建init進(jìn)程。這樣，網(wǎng)卡驅動(dòng)程序經(jīng)過(guò)接近三周的時(shí)間終于被驅動(dòng)了！ |
聯(lián)系客服
