【移植驱动到Linux3.4.2内核之二】LCD，触摸屏，按键，USB等驱动程序的移植心得总结

学习交流加

• 个人qq：
  1126137994
• 个人微信：
  liu1126137994
• 学习交流资源分享qq群：
  962535112

今天移植了按键，LED，LCD，触摸屏等驱动程序，移植驱动程序相对于写驱动程序，就简单得多，前提是得理解驱动程序。
现在来大体总结一下如何移植一个新的驱动程序（不是内核自带的驱动程序）的大体思路以及流程。

一移植驱动程序心得体会

首先呢，我们拿到一个新的驱动程序，直接先拿过来编译（先修改Makefile关于内核的路径），编译后，一般都会报错，因为我们的驱动程序，一般不是针对我们这个内核来写的，报错了不要怕，我们一个一个解决。

错误一般不会太难解决，因为驱动程序关于硬件的操作，都是完全一样的，除非你用的硬件都不一样，那样就得换驱动程序了。一般的错误不会涉及修改硬件的操作，一般都是因为新的内核里面某些函数的名字变了，或者某些函数的定义的形式变了，比如以前是一堆函数在定义，但是有可能在新内核中，这些函数有可能会统一放到一个结构体或者数组中被定义。也有可能这个函数的名字稍微有所变化，也或者是头文件的名字变了，或者缺少了某些头文件。总的来说，大概的错误就是以下几种：

错误：

1. 解决错误
   1.1 头文件不对：去掉或改名
   1.2 宏不对：改名使用新宏
   1.3 有些函数没有了：改名使用新函数

当我们遇到这样的错误，如果不会解决，就去参考内核中类似的驱动程序，看看别人是怎么实现这些我们错误的功能的，，记住，参考内核源码，是一个非常好的办法，随着经验的提高，这个方法一定要越来越熟悉。然后大概的解决办法，就是上面所说的几种。

之前移植过LED驱动程序，按键等，下面给出一两个移植的过程记录，方便以后查阅复习

---

二移植LCD驱动程序记录

1.直接编译
首先把我们的LCD的驱动程序以及它的Makefile拿到Linux系统编译，需要将Makefile里依赖的内核目录的路径修改为当前使用的内核路径，然后直接make编译，肯定会报错：

2.一个个解决错误
首先解决前面的错误，前三个错误都说，没有相关头文件，那么我们就把这三个头文件注释掉：

//#include <asm/arch/regs-lcd.h>
//#include <asm/arch/regs-gpio.h>
//#include <asm/arch/fb.h>

然后重新编译：

这里竟然直接编译通过了，说明新的内核关于LCD的变化不大。

3.测试驱动程序
我们把驱动生成的.ko文件拷贝到网络文件系统，然后还需要重新配置一下内核去掉它本身自带的LCD的支持来验证我们的新编译的驱动是否可以驱动我们的LCD屏。
配置内核：
make menuconfig
依次选择：

 Device Drivers  ---> 
	 Graphics support  ---> 
		  <*> Support for frame buffer devices  --->   
			  <M>   S3C2410 LCD framebuffer support  //将这一项前面尖括号的*号改成m，这样就去掉了内核自带的LCD驱动

重新编译内核。
编译好内核映像后，还需要make modules，因为我们的LCD驱动程序还依赖于其他三个函数：

static struct fb_ops s3c_lcdfb_ops = {
	.owner		= THIS_MODULE,
	.fb_setcolreg	= s3c_lcdfb_setcolreg,
	.fb_fillrect	= cfb_fillrect,  //下面这三个，这三个函数在三个不同的文件，我们需要把这三个文件编译为.ko文件加载到内核才能
	.fb_copyarea	= cfb_copyarea,  //使用LCD驱动程序。
	.fb_imageblit	= cfb_imageblit,
};

然后我把内核映像文件以及生成的三个依赖文件（cfb*ko）拷贝到网络文件系统，烧写内核重启开发板：
设置环境参数：
set bootargs console=ttySAC0,115200 root=/dev/nfs nfsroot=192.168.1.101:/work/nfs_root/fs_mini_mdev_new ip=192.168.1.104:192.168.1.101:192.168.1.1:255.255.255.0::eth0:off

保存环境参数：
save

烧写内核
nfs 30000000 192.168.1.101:/work/nfs_root/uImage_nolcd; bootm 30000000

启动后，先装载cfb*ko文件，然后装载lcd.ko文件，然后用测试程序测试是否可以操作显示屏。一切正常，移植完毕！！！

---

三移植按键输入子系统驱动程序

1.直接编译
同上lcd驱动的编译先修改Makefile后直接编译：

2.改错误
第一个错误：没有某个头文件，那就直接先注释掉。
第二到五的错误：没有定义那个宏，通过搜索内核相关类似驱动程序以及类似函数的用法，得知，应该将下面的结构体：

struct pin_desc pins_desc[4] = {
	{IRQ_EINT0,  "S2", S3C2410_GPF0,   KEY_L},
	{IRQ_EINT2,  "S3", S3C2410_GPF2,   KEY_S},
	{IRQ_EINT11, "S4", S3C2410_GPG3,   KEY_ENTER},
	{IRQ_EINT19, "S5",  S3C2410_GPG11, KEY_LEFTSHIFT},
};

改为：

struct pin_desc pins_desc[4] = {
	{IRQ_EINT0,  "S2", S3C2410_GPF(0),   KEY_L},
	{IRQ_EINT2,  "S3", S3C2410_GPF(2),   KEY_S},
	{IRQ_EINT11, "S4", S3C2410_GPG(3),   KEY_ENTER},
	{IRQ_EINT19, "S5",  S3C2410_GPG(11), KEY_LEFTSHIFT},
};

第六个错误：说是下面的IRQT_BOTHEDGE没有定义，可能是新内核的这个标志有所变化（双边沿触发）：

		request_irq(pins_desc[i].irq, buttons_irq, IRQT_BOTHEDGE, pins_desc[i].name, &pins_desc[i]);

搜索内核中request_irq函数的相通用法（注意搜索范围可以缩小到/drivers/char目录），最终查到可以用下面的代替：

		request_irq(pins_desc[i].irq, buttons_irq, (IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING), pins_desc[i].name, &pins_desc[i]);

先解决这上面的几个错误，重新编译：竟然编译成功了！！！这说明后面没有看的错误，其实是由前面的错误导致的。

3.测试驱动程序
我们把文件系统中/etc/inittab修改为（加一行：tty1::askfirst:-/bin/sh）：

::sysinit:/etc/init.d/rcS
console::askfirst:-/bin/sh
tty1::askfirst:-/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/bin/umount -a -r

然后重启系统：
那么开发板显示屏也会出现跟串口显示一样的内容，按下按键，可以直接操作了。按键驱动程序移植成功。

---

四移植触摸屏驱动程序

1.直接编译：

2.改错误
这次我们的错误比较简单，只需要把上面没有的头文件注释掉就行，然后重新编译。

3.tslib测试触摸屏
我们用tslib这个应用程序库来校准测试触摸屏。
首先我们按照下面的步骤编译tslib的库：
编译：
tar xzf tslib-1.4.tar.gz
cd tslib
./autogen.sh

mkdir tmp
echo “ac_cv_func_malloc_0_nonnull=yes” >arm-linux.cache
./configure --host=arm-linux --cache-file=arm-linux.cache --prefix=$(pwd)/tmp
make
make install

安装tslib库：
cd tmp
cp * -rf /work/nfs_root/fs_mini_mdev_new/

然后修改添加好的ts库的文件系统的配置文件：
修改 /etc/ts.conf第1行(去掉#号和第一个空格)：

# module_raw input
改为：
module_raw input

然后设置环境变量：
export TSLIB_TSDEVICE=/dev/event1
export TSLIB_CALIBFILE=/etc/pointercal
export TSLIB_CONFFILE=/etc/ts.conf
export TSLIB_PLUGINDIR=/lib/ts
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0

校准：
然后输入：
ts_calibrate

然后显示如下：
selected device is not a touchscreen I understand

看来是遇到了错误,去百度搜索关键字，最终得知：

原因非常简单：tslib中的输入系统和内核input系统版本不匹配，当然也有其他原因，不过这是最常见的情况，先分析一下tslib代码，观察这句话在什么情况下被打印就知道了。
将tslib库中c和H文件加入Source Insight，跟踪源码发现，在 input-raw.c文件中有这么一段代码：

static int check_fd(struct tslib_input *i) 

{

    struct tsdev *ts = i->module.dev;

    int version;

    u_int32_t  bit;

    u_int64_t  absbit;



    if (! ((ioctl(ts->fd, EVIOCGVERSION, &version) >= 0) &&

        (version == EV_VERSION) &&

        (ioctl(ts->fd, EVIOCGBIT(0, sizeof(bit) * 8), &bit) >= 0) &&

        (bit & (1 << EV_ABS)) &&

        (ioctl(ts->fd, EVIOCGBIT(EV_ABS, sizeof(absbit) * 8), &absbit) >= 0) &&

        (absbit & (1 << ABS_X)) &&

        (absbit & (1 << ABS_Y)) && (absbit & (1 << ABS_PRESSURE)))) {

        fprintf(stderr, "selected device is not a touchscreen I understand\n");

        return -1; 

    }   

    if (bit & (1 << EV_SYN))

        i->using_syn = 1;

    return 0;

}

其中关键的是version == EV_VERSION这个判断语句（可以通过注释法测试到底是哪个判断语句导致的打印语句），如果这俩不等，那么就会打印出selected device is not a touchscreen I understand。

tslib中的input版本号是在交叉编译的时候指定的，赋值给version，而EV_VERSION是在内核中定义，笔者做tslib时，用的2.6.39内核，这个EV_VERSION定义在include/linux/input.h中，值是0x010001，而tslib中的version是和交叉编译器相同，查看编译器，在/work/tools/usr/local/arm/4.3.2/arm-none-linux-gnueabi/libc/usr/include/linux/input.h中，值是0x010000，这俩明显不相等，当然不会满足version == EV_VERSION，所以导致错误。

解决办法：
以下提供两种解决方法
1.将内核源代码里的include/linux/input.h中的

#define EV_VERSION        0x010001

改为：

#define EV_VERSION        0x010000

2.将arm交叉编译工具中的头文件库中的

linux/input.h中的

#define EV_VERSION        0x010000

改为

#define EV_VERSION        0x010001

然后再编译tslib库

我们选用第二种。

然后重新编译tslib库：
make clean
make
make install
然后将库拷贝到网络文件系统。

修改配置文件以及设置环境变量（如上同）
然后校准输入：
ts_calibrate
可以正常校准触摸屏了。
输入：ts_test可以在屏幕上进行画圆。

以上操作，说明触摸屏驱动程序，以及校准程序，都可以正常使用。

---

五移植USB驱动程序

我们之前写过简单的USB鼠标驱动程序，实现鼠标左键输出字符“l”，右键输出字符“s”，中键输出回车。
跟上面的一样，直接编译USB驱动程序，出现以下错误：

去源码中看错误的行出现在：

	usb_buf = usb_buffer_alloc(dev, len, GFP_ATOMIC, &usb_buf_phys);
	。。。。。。
	。。。。。。
	usb_buffer_free(dev, len, usb_buf, usb_buf_phys);

错误说没有定义usb_buffer_alloc和usb_buffer_free，通过查找，找到如下内容：

/* Compatible macros while we switch over */
static inline void *usb_buffer_alloc(struct usb_device *dev, size_t size,
				     gfp_t mem_flags, dma_addr_t *dma)
{
	return usb_alloc_coherent(dev, size, mem_flags, dma);
}

static inline void usb_buffer_free(struct usb_device *dev, size_t size,
				   void *addr, dma_addr_t dma)
{
	return usb_free_coherent(dev, size, addr, dma);
}

说明，新的内核中，没有直接定义usb_buffer_alloc与usb_buffer_free，而是让他们返回usb_alloc_coherent和usb_free_coherent，所以我们将usb_buffer_alloc与usb_buffer_free分别替换为：usb_alloc_coherent和usb_free_coherent，应该就可以了！！！！

重新编译，成功！！！！
测试步骤较简单，省略！！！

好了经过以上的分析过程，自己对这种非内核自带的驱动程序的移植，有了一定的理解与掌握，相信以后随着经验的丰富，会更加熟练！！！

想一起探讨以及获得各种学习资源加我（有我博客中写的代码的原稿）：
qq：1126137994
微信：liu1126137994
可以共同交流关于嵌入式，操作系统，C++语言，C语言，数据结构等技术问题。