【i.MX6ULL】驱动开发1--字符设备开发模板
之前的几篇文章(从i.MX6ULL嵌入式Linux开发1-uboot移植初探起),介绍了嵌入式了Linux的系统移植(uboot、内核与根文件系统)以及使用MfgTool工具将系统烧写到板子的EMMC中。
本篇开始介绍嵌入式Linux驱动开发。
内容较多,先看目录:
[TOC]
1 Linux驱动分类
Linux中的外设驱动可以分为三大类:字符设备驱动、块设备驱动和网络设备驱动。
- 字符设备驱动:字符设备是能够按照字节流(比如文件)进行读写操作的设备。字符设备最常见,从最简单的点灯到I2C、SPI、音频等都属于字符设备驱动
- 块设备驱动:以存储块为基础的设备驱动,如EMMC、NAND、SD卡等。对用户而言,字符设备与块设备的访问方式没有差别。
- 网络设备驱动:即网络驱动,它同时具有字符设备和块设备的特点,因为它是输入输出是有结构块的(报文,包,帧),但它的块的大小又不是固定的。
2 Linux驱动基本原理
在Linux中一切皆文件,驱动加载成功以后会在“**/dev”目录下生成一个相应的文件,应用程序通过对这个名为“/dev/xxx**”的文件进行相应的操作即可实现对硬件的操作。
比如最简单的点灯功能,会有/dev/led这样的驱动文件,应用程序使用open函数来打开文件/dev/led,如果要点亮或关闭led,那么就使用write函数写入开关值,如果要获取led的状态,就用read函数从驱动中读取相应的状态,使用完成以后使用close函数关闭/dev/led这个文件。
2.1 Linux软件分层结构
Linux软件从上到下可以分层4层结构,以控制LED为例:
应用层:应用程序使用库提供的open函数打开LED设备
库:库根据open函数传入的参数执行“swi”指令,进而引起CPU异常,进入内核
内核:内核的异常处理函数根据传入的参数找到对应的驱动程序,返回文件句柄给库,进而返回给应用层
应用层得到文件句柄后,使用库提供的write或ioctl发出控制指令
库根据write或ioctl函数传入的参数执行“swi”指令,进入内核
内核的异常处理函数根据传入的参数找到对应的驱动程序
驱动:驱动程序控制硬件,点亮LED
应用程序运行在用户空间,而Linux驱动属于内核的一部分,因此驱动运行于内核空间。当应用层通过open函数打开/dev/led 这个驱动时,因用户空间不能直接操作内核,因此会使用“系统调用”的方法来从用户空间“陷入”到内核空间,实现对底层驱动的操作。
比如应用程序调用了open这个函数,则在驱动程序中也应有一个对应的open的函数。
2.2 Linux内核驱动操作函数
每一个系统调用,在驱动中都有与之对应的一个驱动函数,在Linux内核文件include/linux/fs.h中有个file_operations结构体,就是Linux内核驱动操作函数集合:
1 | struct file_operations { |
其中有关字符设备驱动开发中常用的函数有:
- owner:拥有该结构体的模块的指针,一般设置为THIS_MODULE。
- llseek函数:用于修改文件当前的读写位置。
- read函数:用于读取设备文件。
- write函数:用于向设备文件写入(发送)数据。
- poll函数:是个轮询函数,用于查询设备是否可以进行非阻塞的读写。
- unlocked_ioctl函数:提供对于设备的控制功能, 与应用程序中的 ioctl 函数对应。
- compat_ioctl函数:与 unlocked_ioctl功能一样,区别在于在 64 位系统上,32 位的应用程序调用将会使用此函数。在 32 位的系统上运行 32 位的应用程序调用的是unlocked_ioctl。
- mmap函数:用于将将设备的内存映射到进程空间中(也就是用户空间),一般帧缓冲设备会使用此函数, 比如 LCD 驱动的显存,将帧缓冲(LCD 显存)映射到用户空间中以后应用程序就可以直接操作显存了,这样就不用在用户空间和内核空间之间来回复制。
- open函数:用于打开设备文件。
- release函数:用于释放(关闭)设备文件,与应用程序中的 close 函数对应。
- fasync函数:用于刷新待处理的数据,用于将缓冲区中的数据刷新到磁盘中。
- aio_fsync函数:与fasync功能类似,只是 aio_fsync 是异步刷新待处理的
2.3 Linux驱动运行方式
Linux 驱动有两种运行方式:
- 将驱动编译进Linux内核中, 这样当Linux内核启动的时候就会自动运行驱动程序。
- 将驱动编译成模块(扩展名为 .ko), 在Linux内核启动以后使用“insmod”命令加载驱动模块。
在驱动开发阶段一般都将其编译为模块,不需要编译整个Linux代码,方便调试驱动程序。当驱动开发完成后,根据实际需要,可以选择是否将驱动编译进Linux内核中。
2.4 Linux设备号
2.4.1 设备号的组成
Linux中每个设备都有一个设备号,设备号由主设备号和次设备号两部分组成。
- 主设备号:表示某一个具体的驱动
- 次设备号:表示使用这个驱动的各个设备
Linux 提供了名为dev_t的数据类型表示设备号,其本质是32位的unsigned int数据类型,其中高12位为主设备号,低2 位为次设备号,因此Linux中主设备号范围为0~4095。
在文件include/linux/kdev_t.h中提供了几个关于设备号操作的宏定义:
1 |
- MINORBITS:表示次设备号位数,一共20位
- MINORMASK:表示次设备号掩码
- MAJOR:用于从dev_t中获取主设备号,将dev_t右移20位即可
- MINOR:用于从dev_t中获取次设备号,取dev_t的低20位的值即可
- MKDEV:用于将给定的主设备号和次设备号的值组合成dev_t类型的设备号
2.4.2 主设备号的分配
主设备号的分配包括静态分配和动态分配
- 静态分配需要手动指定设备号,并且要注意不能与已有的重复,一些常用的设备号已经被Linux内核开发者给分配掉了,使用“cat /proc/devices”命令可查看当前系统中所有已经使用了的设备号。
- 动态分配是在注册字符设备之前先申请一个设备号,系统会自动分配一个没有被使用的设备号, 这样就避免了冲突。在卸载驱动的时候释放掉这个设备号即可。
设备号的申请函数:
1 | /* |
设备号的释放函数:
1 | /* |
3 字符设备驱动开发模板
3.1 加载与卸载
在编写驱动的时候需要注册模块加载和卸载这两种函数:
1 | module_init(xxx_init); //注册模块加载函数 |
module_init()
用来向Linux内核注册一个模块加载函数,参数xxx_init就是需要注册的具体函数,当使用 “insmod” 命令加载驱动的时候,xxx_init这个函数就会被调用。module_exit()
用来向Linux内核注册一个模块卸载函数,参数xxx_exit就是需要注册的具体函数,当使
用“rmmod”命令卸载具体驱动的时候 xxx_exit函数就会被调用。
字符设备驱动模块加载和卸载模板如下所示:
1 | /* 驱动入口函数 */ |
驱动编译完成以后扩展名为.ko, 有两种命令可以加载驱动模块:
insmod
:最简单的模块加载命令,用于加载指定的.ko模块,此命令不能解决模块的依赖关系modprobe
:该命令会分析模块的依赖关系,将所有的依赖模块都加载到内核中,因此更智能modprobe 命令默认会去
/lib/modules/<kernel-version>
目录中查找模块(自制的根文件系统没有这个目录,需要手动创建)
卸载驱动也有两种命令:
rmmod
:例如使用rmmod drv.ko
来卸载 drv.ko这一个模块modprobe -r
:该命令除了卸载指定的驱动,还卸载其所依赖的其他模块,若这些依赖模块还在被其它模块使用,就不能使用 modprobe来卸载驱动模块!!!
3.2 注册与注销
对于字符设备驱动而言,当驱动模块加载成功以后需要注册字符设备,同样,卸载驱动模块的时候也需要注销掉字符设备。
字符设备的注册函数原型如下所示:
1 | /* func: register_chrdev 注册字符设备 |
字符设备的注销函数原型如下所示:
1 | /* func: unregister_chrdev 注销字符设备 |
一般字符设备的注册在驱动模块的入口函数 xxx_init 中进行,字符设备的注销在驱动模块的出口函数 xxx_exit 中进行。
1 | static struct file_operations test_fops; |
注:选择没有被使用的主设备号,可输入命令“cat /proc/devices”来查看当前已经被使用掉的设备号
3.3 实现设备的具体操作函数
file_operations 结构体就是设备的具体操作函数。
假设对chrtest这个设备有如下两个要求:
- 能够实现打开和关闭操作:需要实现 file_operations 中的open和release这两个函数
- 能够实现进行读写操作:需要实现 file_operations 中的read和write这两个函数
首先是 打开(open)、读取(read)、写入(write)、释放(release) 4个基本操作
1 | /*打开设备*/ |
然后是 驱动的入口(init)和出口(exit) 函数:
1 | /*文件操作结构体*/ |
3.4 添加LICENSE和作者信息
LICENSE是必须添加的,否则编译时会报错,作者信息可加可不加。
1 | MODULE_LICENSE() //添加模块 LICENSE 信息 |
总结一下:
4 字符设备驱动开发实验
下面以正点原子提供的教程中的chrdevbase这个虚拟设备为例,完整的编写一个字符设备驱动模块。chrdevbase不是实际存在的一个设备,只是为了学习字符设备的开发的流程。
4.1 程序编写
需要分别编写驱动程序和应用程序。
注:为了区分两个程序的打印信息,在驱动程序的打印前都添加“[BSP]”标识,在应用程序的打印前都添加”[APP]“标识。
4.1.1 编写驱动程序
- 一些定义
1 |
|
- 打开、关闭、读取、写入
1 | /* |
- 驱动加载与注销
1 | /* |
- 最后的LIENSE与作者
1 | /*LICENSE和作者信息*/ |
4.1.2 编写应用程序
这里把程序截取为3段分析,首先看开头:
1 |
|
主要是一些头文件和main函数入口,调用main函数时需要传入2个参数(实际是3个参数,函数名本身是默认的第0个参数,不需要手动指定),具体作用为:
- 参数0:argv[0],函数名本身,这里不作用途
- 参数1:argv[1],filename,这里不作用途
- 参数2:argv[2],自定义的操作参数,下面函数会讲到,1为从驱动文件中读取,2为向驱动文件中写入数据
再来看具体操作:
1 | //【2】从驱动文件读取数据 |
最后是关闭设备:
1 | //【4】关闭设备 |
关闭即表示不再使用该设备了(若要再使用则重新打开即可),通过关闭驱动文件来实现字符设备驱动的关闭。
4.2 程序编译
4.2.1 编译驱动程序
编译驱动,即编译chrdevbase.c这个文件为.ko 模块,使用Makefile来编译,先创建Makefile:
1 | KERNELDIR := /home/xxpcb/myTest/imx6ull/kernel/nxp_kernel/linux-imx-rel_imx_4.1.15_2.1.0_ga |
各行含义:
- KERNELDIR:开发板所使用的Linux内核源码目录
- CURRENT_PATH:当前路径,通过运行“pwd”命令获取
- obj-m:将 chrdevbase.c 这个文件编译为chrdevbase.ko模块
- 具体的编译命令:后面的modules表示编译模块,-C 表示切换工作目录到KERNERLDIR目录,M表示模块源码目录
输入“make”命令即可编译,编译后会出现许多编译文件
注:若直接make编译报如下错误,是因为kernel中没有指定编译器和架构,使用了默认的x86平台编译报错。
修改Kernel工程的顶层Makefile,直接定义ARCH和CROSS_COMPILE 这两个的变量值为 arm 和 arm-linux-gnueabihf-
(内核篇的介绍见:i.MX6ULL嵌入式Linux开发3-Kernel移植)
4.2.2 编译应用程序
编译应用程序不需要内核文件参与,只有一个文件就能编译,因此直接输入指令进行编译:
1 | arm-linux-gnueabihf-gcc chrdevbaseApp.c -o chrdevbaseApp |
编译会生chrdevbaseApp,它是32位LSB格式的ARM版本可执行文件
4.3 测试
上一篇文章(i.MX6ULL嵌入式Linux开发6-系统烧写到eMMC与遇到的坑!)已经实现了系统移植的打包烧录工作,系统已经烧录的EMMC中了。这次我们就直接在这个基础上进行实验。
4.3.1 创建驱动模块目录
加载驱动模块,使用的modprobe命令,会从特定的目录下寻找文件。比如开发板使用的是4.1.15版的Linux内核 ,则是“/lib/modules/4.1.15”这个目录,这个目录一般是没有的,需要根据Linux内核的版本自己创建。
注意这是开发板的文件系统中的路径,可以通过串口连接进入开发板,通过linux指令创建该目录。
4.3.2 发送文件到开发板(TFTP传输)
此次测试首先需要将ubuntu中编译的文件传输到板子中运行,怎么传输呢?可以使用TFTP传输服务。
在之前的文章(i.MX6ULL嵌入式Linux开发2-uboot移植实践)中已经介绍了如何在ubuntu中搭建TFTP服务器。
搭建好TFTP服务后,开始传输文件到开发板具体的传输步骤为:
开发板连接网线,与ubuntu虚拟机处于同一局域网内
确保ubuntu已安装的TFTP服务,并设置了TFTP服务文件夹
将ubuntu中编译好的文件复制到ubuntu的TFTP服务文件夹中!!!
1
2mv chrdevbaseApp ~/myTest/tftpboot/
mv chrdevbase.ko ~/myTest/tftpboot/注:编译完程序,在传输到板子之前,一定要记得把文件先复制到TFTP文件夹中,否则板子获取到的可能是TFTP文件夹中的旧文件。
开发板的串口中通过如下指令来将ubuntu中的文件传输到开发板中
1
2
3cd /lib/modules/4.1.15 /*确保在要下载文件的目录中,若已在,则忽略*/
tftp -g -r chrdevbaseApp 192.168.5.101 /*获取chrdevbaseApp文件*/
tftp -g -r chrdevbase.ko 192.168.5.101 /*获取chrdevbase.ko文件*/这里的
-g
代表get,即下载文件,-r
代表remote file,即远程主机的文件名,然后是要下载的文件名,最后的远程主机ubuntu的IP地址。输入该指令后,可以看到文件传输进度,如下图:
4.3.3 开始测试
驱动文件chrdevbase.ko和应用文件chrdevbaseApp传输到板子中的/lib/modules/4.1.15目录后,就可以测试了。
首先使用insmod
命令来加载驱动,然后使用lsmod
查看当前的驱动(只有一个我们刚加载的字符驱动),再使用使用cat
指令查看devices 信息,确认系统中是否已经列举了该设备,3条指令如下:
1 | insmod chrdevbase.ko |
具体是输出信息:
可以看出,系统中存在chrdevbase设备,主设备号为程序中设定的200。
驱动加载后,还要在/dev目录下创建一个对应的设备节点文件(应用程序就是通过该节点文件实现对设备的操作)。
输入如下2条命令创建/dev/chrdevbase这个设备节点文件,并查看结果:
1 | mknod /dev/chrdevbase c 200 0 |
至此,字符设备驱动已经加载完成,可以测试我们的应用程序了,也就是读和写:
按照上面程序的设定,1是读,2是写:
1 | ./chrdevbaseApp /dev/chrdevbase 1 |
- 先来看“读测试”,注意要给chrdevbaseApp可执行的权限,否则无法运行。
图中下部是程序输出信息,但似乎只有BSP驱动程序的的输出,没有APP应用程序的输出,应该是内核打印printk与应用的打印printf冲突了,导致APP的打印被挤掉了。
- 再来看“写测试’’,同样也是只有BSP的打印
4.3.4 打印冲突问题规避
对于打印冲突问题,我们可以先在每个printf前后加个sleep(1)的1秒延时,这样可以先避免打印冲突。
增加延时后再次测试,打印正常:
测试完,最后是rmmod命令卸载模块:
5 总结
本篇介绍了嵌入式Linux驱动开发中的基础驱动——字符驱动开发的基本模式,使用了一个虚拟的字符设备驱动进行测试,了解驱动程序与应用程序之间的调用关系。