做Linux底层软件工作也有两年了，算上研究生时期对底层软件的研究，加起来也快四年了。慢慢地发现有必要总结一些一般性的方法了。因为一般性的方法有宏观上的指导意义，以后调试和移植驱动时，经常性地回味这些一般性的方法可以防止自己犯同样的错误，进而少走弯路，以最高的效率完成工作。
当谈到底层软件，我们一般都会想到bootloader、BSP、device driver、linux kernel等等。这篇文章将会着重介绍linux device driver调试的一般性方法。另外，关于设备驱动移植的方法会在文章最后以补充说明的形式给出。
注意，这里说的一般方法不是固定套路，也就是说你不用把它当做教科书来读。你只需要根据具体情况灵活的选用其中某些步骤即可。
一般情况下，进行设备驱动的调试之前，你必须具备以下条件：
l 设备驱动的代码和应用层测试软件（或者代码）
因为你做驱动的最终目的还是要给上层应用去操作的。所以，一个针对驱动的测试应用程序是必须的。这里的应用层测试软件一般都是供应商提供的，或者系统现有的可以用的应用，如果没有就必须自己写了。
l 你要调试的设备对应的datasheet、规格书和相关资料
尽可能地去搞到详尽的芯片相关资料和相关说明，因为这些都是你随后调试驱动的指引。
l 开发板的原理图和贴片图
一般情况下，你可能不需要贴片图，但是如果你们的硬件工程师对你的支持力度不够，那你就需要一个板子的贴片图。原因可能有以下几点：
（1） 如果是飞线过来的模块，而且你又不确定硬件工程师的操作是完全正确的，是不是每条线都接的是对的，这时候你就必须搞到贴片图和原理图，然后和板子上的飞线一条一条线的核对一遍。如果准确无误，那你就开工。
（2） 当你们的硬件工程师没有给你提供硬件板子的引脚具体在板子上的哪个位置的说明时，你就必须搞到贴片图。
（3） 此外，经常贴片图有助于提高一个驱动工程师的硬件素养。
l 万用表、示波器
万用表和示波器是必备的，其次，根据需要，你可能会用到频谱分析仪和逻辑分析仪。
OK!当你拿到这些资料后，你就可以大刀阔斧地进行设备驱动调试了。一般的，设备驱动的调试都会经历如下几个步骤：
一、把设备驱动的代码添加进kernel
这一点要注意了，不同的方案提供商给出的添加方法是不同的。例如，对于Mediatek方案提供商，添加设备驱动的方法就和一般化的不一样，
因为Mediatek的体系架构不同于像telechips、Qualcomm等这样的kernel传统架构。所以，对于像Mediatek这样的特殊供应商，你必须遵循其提供的一套添加驱动的流程（mtk支持比较好，一般会提供sop）。传统架构的话，就很简单了，一般都会涉及到一下几步：
l 新建设备驱动目录
l 添加头文件
l 创建当前目录的Makefile
l 创建上层目录的Makefile
l 在上层目录添加Kconfig选项
l 在板文件添加对应项。
l 如果不想每次都用menuconfig配置，就在kernel/arch/arm/configs/XXX_defconfig里面添加编译项
具体的实例我之类就不写了，google一下一大把，这篇文章也不会涉及到过多的细节问题。
设备驱动添加进来之后，一般的，都需要你添加、删除、修改一些内容，才能保证其编译通过。如果是调试，这里可能改动不大，因为驱动文
件一般是由芯片原厂提供的，他们已经修改的基本可以编译通过了。但如果是移植，在这里花费的精力一般是比较大的，这会在后文中的附加说明里面提及到。
三、检查设备驱动是否正常初始化
进行到这一步，你需要检查设备驱动是否可以顺利初始化，这个很简单，你只需要在设备驱动的probe函数或者init函数里面添加一条打印
信息即可在串口观察是否有打印，如果没有打印，说明驱动根本就没有得到初始化。此时，你应该：
l 首先，你赶紧跑过去问和你合作的硬件工程师：“hi，我这块板子，那个XXX芯片是否贴上了？”，或者问他们：“这些飞线是不是都连接的OK了？”。 问这些问题都是很有必要的，因为很有可能硬件上没有准备好，或者硬件连线本来就有问题。所以，为了避免浪费时间，你还是主动去问下他们。
l 其次，如果芯片确实贴上了而且硬件连线都接对了（后来你不放心，自己也核对了一遍），这时候问题就在你喽。马上检查设备驱动的添加是否有什么问题，是否是板文件没有修改好，是否驱动本身就没有注册好等等。
一、检查应用程序是否可以正常使用
如果驱动得到了正常的初始化，这时候你开始检查该设备驱动对应的应用程序是否可以正常使用（或者自己写设备驱动的测试应用程序）。如果可以正常使用，那你太幸运了，这说明芯片原厂为你考虑的很周到，你可以节省N多时间干别的事儿了。
但遗憾的是，往往事情不会这么顺利，当你检查应用程序的时候，你发现应用程序没有做出应有的反应——例如当你辛苦把camera的驱动添加到kernel而且顺利初始化之后，你兴奋地进入系统打开camera发现：黑屏！你郁闷了，但是郁闷不能解决问题，这时候真正的所谓设备驱动的“调”和“试”才来了。赶紧去找一个万用表和一个示波器吧。
二、设备驱动的“调”和“试”
所谓“调”，就是你依据设备芯片datasheet、主控datasheet、相关的规格书等资料，以及观察与测量的结果，不断地对设备驱动 code进
行添加、删除和修改。
所谓“试”，就是你在添加、删除和修改的同时要不断地：
l 通过串口对反馈信息进行观察；
l 通过万用表对各电源引脚电压进行测量；
l 通过示波器对芯片的时钟（输入的和输出的）频率（包括测量晶振）、数据信号的波形、某种总线信号的波形，等各个引脚进行测量。
观察设备的上电时序，数据交互时序等等是否正常（参考datasheet）。
l 通过测试应用程序对驱动进行测试，并反复观察设备驱动的运行状态。
测试不光是测试员的事情，你必须保证自己调试的驱动可以运行稳定才可以提交代码，发给测试员进行大量测试。测试自己调试的设备驱动有以下几种：
（1） 利用系统里面现有的应用程序进行测试
这个是最直接的测试，也省去了你自己编写测试程序的时间。
（2） 自己编写linux应用程序来测试驱动
如果你对系统现有的应用程序不放心，或者不满意，就自己编写测试驱动吧。
（3） 利用proc或者sys文件系统的读和写函数
如果你在设备驱动里面添加了proc或者sys文件系统的读和写函数，你就可以在命令行通过cat或者echo命令来对设备驱动的各项参数进行手动测试。
注：以上测试方法是我习惯用的，除了这些，还是有其他一些测试方法我没有列举出来，感兴趣的话可以google一下。
此外，应该养成一个好习惯，那就是在测量各个引脚的同时，你最好创建一份excel表格，把各个引脚的电压、波形等情况记录下来，目的是在N多次修改之间作比较，也更有备忘的作用。
这里的“调”和“试”的过程是最耗时的，也是设备驱动调试的最关键的步骤，所以你应该非常有耐心的走好这一步。还应该注意的是，设备驱动的调试不光是你一个人的事情，有时候你闷头苦干一个星期都不一定能搞定。所以，进行调试的同时，必须有一个硬件工程师配合你，因为驱动不能正常运行也很有可能是硬件的设计纰漏导致的。此外，不要闭门造车，毕竟你在一个大的开发团队里面，你需要及时和同事进行有效的交流，避免走弯路。最后，如果还是存在问题，你就得邀请芯片原厂的FAE过来喽。
补充说明
要进行设备驱动的移植，一般的，你必须具备以下几个条件：
l 和当前设备芯片相近的或者相类似的芯片的现有驱动代码。
这句话有点拗口了，举个例子来讲吧。例如，你现在要移植一份驱动到g-sensor（BMA250E）上，你现在就应该尽可能
地去找到和芯片BMA250E相近的芯片所对应的驱动代码。这时候，你高兴的发现，咦？！手头上还有一份BMA250的代码,太幸运了。此时你就可以基于BMA250的代码来做移植。但有时候并没有这么幸运，那怎么办呢？这时候你完全可以去找其他类型的g-sensor啊，假如你手头上并没有BMA250的代码，但是你有一份ADXL345的代码，那当然也是可以的，你完全可以基于ADXL345的代码来做移植。至于为什么要选择与当前设备芯片相近的芯片所对应的驱动代码，原因就四个字“提高效率”。
l 当前芯片的详细datasheet，以及芯片的相关说明
l 开发板的原理图
如果有pads版本的原理图和贴片图，那是最好的了，方便以后测量引脚的各项参数。
l 万用表和示波器
这是调试、移植、开发设备驱动必不可少的设备。
具备了以上几个条件之后，接着走上文所讲的第一个和第二个步骤，尤其在第二个步骤，你可能得费好大力气来针对你当前的开发板进行驱动文件的修改。修改一般都包括I\O配置、中断的设置、总线的配置（例如I2C、SPI、SDIO等）、寄存器的配置、甚至驱动代码的框架都得修改。等你这一步做好了，接着进行上文谈到的第三步，然后一步一步往下走完即可。
用一句话概括一下驱动移植吧。驱动的移植实际上就是：“通过添加、删除和修改，使现有的一份芯片相近的驱动代码可以在目标芯片和目标板上跑起来并且跑的很稳定！”
设计和编写设备驱动的一般方法
我的上一篇博客《设备驱动调试和移植的一般方法》详细介绍了调试和移植的几个步骤，依照那几个步骤，按部就班，外加不屑的努力，你就可以完成驱动的调试和移植。但是当你面临的是一块崭新的芯片XXXX，当前并没有现有的芯片相近驱动代码，更没有芯片原厂提供给你的驱动代码，只有一份该芯片的数据手册，此时，你就不得不FROM SCRATCH。
这时候你是不是有点不知所措呢？其实你不用着急，根据可知论，世界是可以被认知的，linux设备驱动的一般性的设计和编写方法也是存在的，所以，你大可不必惊慌。Linux设备驱动的设计一般可以遵循以下几个步骤。
一、深刻理解datasheet和原理图
这里讲的datasheet包括主控的datasheet和设备芯片的datasheet，原理图就指的是开发板的的原理图了，
如果有pads版本的原理图和贴片图，那是最好的了，方便以后测量引脚的各项参数。阅读和深刻理解设备芯片的datasheet对第一个步骤里面最重要的组成部分，设备驱动就是datasheet的最直观表达，只有在深刻理解的datasheet的基础之上，才有可能设计和开发出优秀的设备驱动。另外，datasheet在一定程度上就是你做驱动软件的需求文档。你做软件总该有个需求吧，那么这里谈到的datasheet就是驱动软件的最好的、最清楚的需求分析。所以，在没有理解datasheet之前就着手做驱动，那结果是可想而知的。
二、搭建起设备驱动的框架
理解了datasheet之后，先不要急着去编写代码，你首先应该做的就是给你将要写的驱动程序设计一个框架。
那么这里的框架应该依据什么搭建呢？具体怎么搭建呢？
一般的，从USB驱动到I2C驱动，从SPI驱动到串口驱动，从PCI驱动到DMA驱动，等等，不管是什么类型的驱动，它总有一种或者几种基本固定的套路供你选择。如果你打算写一个touch驱动，而这个touch挂接在I2C上，那么你就依据I2C设备编写的一一种固定套路先搭建框架。具体如何搭建，这里就给出I2C设备驱动编写的一种固定套路给大家。
I2C设备驱动的新式编写方法为probe方法，这里就讲编写I2C设备驱动的probe方法的框架的搭建。
l 创建一个i2c_driver
static struct i2c_driver XXXX_driver = {
.driver = {
.name= "XXXX"，
}，
.probe = XXXX_probe， /* 当存在i2c_client和i2c_driver匹配时调用 */
.remove = XXXX_remove，
.id_table = XXXX_id，/* 匹配规则 */
};
l 注册i2c_driver
static int __init XXXX_init（void）
{
return i2c_add_driver（&XXXX_driver）;
}
module_init（XXXX_init）;
注册i2c_driver的过程，实际上是将driver注册到i2c_bus_type的总线上。此总线的匹配规则是：
static const struct i2c_device_id *i2c_match_id（const struct i2c_device_id *id，
const struct i2c_client *client）
{
while （id->name[0]） {
if （strcmp（client->name， id->name） == 0）
return id;
id++;
}
return NULL;
}
上面代码实际上是利用i2c_client的名称和id_table中的名称做匹配的。这里的id_table为：
static const struct i2c_device_id XXXX_id[] = {
{ "XXXX346"， 8， }，
{ "XXXX353"， 16， }，
{ "XXXX388"， 8， }，
{ "XXXX399"， 16， }，
{ "XXXX542"， 8， }，
{ "XXXX551"， 16， }，
{ "XXXX572"， 8， }，
{ }
};
l 注册i2c_board_info
对于Probe方法，都要在平台代码中要完成i2c_board_info的注册。办法如下：
static struct i2c_board_info __initdata tmp_i2c_devices[] = {
{
I2C_BOARD_INFO（"XXXX9555"， 0x27），//XXXX9555为芯片名称，0x27为芯片地址
.platform_data = &XXXX9555_data，
}，
{
I2C_BOARD_INFO（"mt9v022"， 0x48），
.platform_data = &iclink[0]， /* With extender */
}，
{
I2C_BOARD_INFO（"mt9m001"， 0x5d），
.platform_data = &iclink[0]， /* With extender */
}，
};
i2c_register_board_info（0，tmp_i2c_devices，
ARRAY_SIZE（tmp_i2c_devices））; /* 注册 */
i2c_client是在注册过程中创建的。
l 调用i2c适配器来完成数据传输
int （*master_xfer）（struct i2c_adapter *adap，struct i2c_msg *msgs，int num）;
master_xfer要通过调用i2c_transfer来完成传输。
int i2c_transfer（struct i2c_adapter * adap， struct i2c_msg *msgs， int num）;
l 字符驱动注册
I2C设备驱动的Probe方法，字符驱动的添加位置在XXXX_probe中。
static int __devinit XXXX_probe（struct i2c_client *client，const struct i2c_device_id *id）
{
/* … 省略 …*/
if（XXXX_major）{
Result = register_chrdev_region（XXXX_dev，1，"XXXX"）;
} else {
result = alloc_chrdev_region（&XXXX_dev，0，1，"XXXX"）;
XXXX_major=MAJOR（XXXX_dev）;
}
if （result < 0） {
printk（KERN_NOTICE "Unable to get XXXX region， error ％d\n"， result）;
return result;
}
XXXX_setup_cdev（chip，0）; /* 注册字符设备, 具体的请google一下 */
/* … 省略 …*/
}
l 字符设备驱动的构建
struct file_operations XXXX_fops = {
.owner = THIS_MODULE，
.ioctl = XXXX_ioctl，
.open = XXXX_open，
.release = XXXX_release，
};
l 删除i2c_driver
static void __exit XXXX_exit（void）
{
i2c_del_driver（&XXXX_driver）;
}
module_exit（XXXX_exit）;
l 删除字符设备驱动
static int __devinit XXXX_remove （struct i2c_client *client）
{
/*…省略…*/
}
你看到这里，就应该明白上面讲到的所谓设备驱动程序的框架是什么意思了吧。当然，这里只写出了I2C设备驱动的一种框架，SPI、USB、DMA 驱动编程都有其各自的框架，具体的信息可以从内核文档（kernel顶层目录下的Documentation目录）获得。总之，你要编写什么类型的驱动，首先根据实际情况搭建好框架。
三、填充框架
搭建好设备驱动程序的框架之后，你应该做的就是根据实际情况往框架里面填充内容了。填充内容可以分为两个层次的填充，分别是：
l 和上层应用打交道的内容
主要包括：
? 基于devfs实现文件操作结构体（file_operations）中的函数，目的是给上层提供系统调用（system call）
? 通过procfs或者sysfs给上层应用提供不同种类的接口
? 向虚拟文件系统（VFS）注册或者注销（添加或者删除）设备驱动，等等。
l 和主控以及设备芯片打交道的内容
依据主控、设备芯片的datasheet以及开发板原理图，做以下填充：
? 定义设备驱动的头文件
? 填充系统调用中和设备芯片直接打交道的部分
? 编写设备驱动程序电源管理模块
? 配置好I/O口的功能，等等。
四、开始设备驱动的调试
这里就得回头谈谈我的上一篇博客《设备驱动调试和移植的一般方法》。它详细介绍了调试和移植的几个步骤。
这里的第四步从《设备驱动调试和移植的一般方法》这篇文章里面讲的第一步往下一步一步走，按部就班，外加你不懈的努力，最终你会发现被别人吹的像神一样的设备驱动会一个一个被你征服。
402
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
