【系统移植】（六）第三方驱动移植
【系统移植】（六）第三方驱动移植
文章目录
- 【系统移植】（六）第三方驱动移植
- 1.编译驱动进内核
- 方法一：编译makefile
- 方法二：编译kconfig
- 方法三：编译成模块
- 2.字符设备框架
编译驱动进内核
a. 选择驱动存放目录 (或任意目录。源码下的drivers/char目录，同时修改目录下的makefile）
b. 改Makefile
c. 改Kconfig （界面可配置）
编译驱动为独立的模块
a. 配置为模块方式
b. make modules 编译为模块
c. 创建设备节点（应用访问驱动的入口）
d. 运行测试驱动的应用程序
1.编译驱动进内核
一、驱动编译进内核Makefile
1、首先找内核中是否已经支持设备的驱动 选配
2、内核中没有的驱动移植进来 --第三方驱动移植
将第三方驱动代码放到linux源码树中的driver目录中
修改 Makefile Kconfig(界面配置)
修改过的和新添加的代码会重新编译
程序需要在板子上运行 就需要使用交叉编译工具编译
mknod /dev/led c或者b 主设备号 此设备号
方法一：编译makefile
- 选择驱动存放目录，源码下的drivers/char目录，同时修改目录下的makefile
- 仿照其他文件的格式，编写同名文件的.o后缀
-
回到源码顶层目录，执行
make uImage编译内核 -
把生成的uImage传到开发板上面
搞一个应用程序，测试这个LED点灯程序，Linux下一切皆文件，那么访问应用层访问底层的入口就是
/dev/led文件
- 在开发板上生成这个设备号文件
- 通过交叉编译，把应用程序发到板子上面运行监测即可
方法二：编译kconfig
由方法一可知，添加一个驱动还行，如果有n个呢？就很难维护。所以有了此方法
二、make menuconfig、Makefile、Kconfig、.config
三者的关系
Makfile 具体编译文件
Kconfig 选配，生成图形化界面，这个只是配置make menuconfig后的界面，具体编译模块还是看makefile
在Kconfig中添加一个灯的选项
界面修改好了， 还需要再次修改 Makfile
[] 只有两种选项编译(y)或者不编译(n) <> 三种选项 编译(y)、不编译(n)或者编译成模块(m)
obj-y obj-n obj-$(CONFIG_XXX) //编译，不编译，根据kconfig确定
方便驱动管理
如何关联起来kconfig和makefile。（之前直接写的-y就写死了）
方法三：编译成模块
之前编译的都是跟内核原本的驱动目录都在一块呢，如果我们写了很多驱动的话还是很乱，这个部分就是把自己写的驱动与Linux原本驱动分离开来。
这部分的内容放到Linux驱动里面讲，在这里不再详细展示。
换成tristate就可有三种模式选择，可编译不可编译，编译编译成模块
2.字符设备框架
