嵌入式Linux驱动开发实战：从字符设备到平台总线源码解析

简介这份资源是华清远见嵌入式培训的驱动源码合集面向具备一定C语言与Linux基础、希望深入理解嵌入式驱动开发的学习者可用于对照课程实验、复现板级驱动案例与梳理内核模块的编写流程。压缩包共286个文件约4.97MB以98个C源文件为核心配合36个Makefile构建脚本、23个readme说明、9个ko内核模块及若干cmd、vsd、docx文档覆盖从源码到编译产物的完整链路。内容涉及字符设备与块设备驱动模型、file_operations接口、中断与DMA处理、设备树配置、GPIO/SPI/I2C/UART外设编程及电源管理等知识点并包含dm9000网卡、按键、e2prom等典型实验代码便于读者按模块拆解学习、调试与二次修改。已有580人学习适合作为驱动开发入门到进阶的实践参考。1. 从一份驱动源码包说起嵌入式入门最容易踩空的那段路很多人学嵌入式卡住的地方不是 C 语言也不是寄存器手册而是从「点亮一个 LED」到「写一个能注册进内核的字符设备驱动」之间那段没人讲清楚的过渡。这份嵌入式学习资料里的驱动源码正好填的就是这段空档它把 Linux 字符设备、平台总线、中断处理、并发控制这些平时散落在各处的知识点落成了一批能编译、能加载、能跑在开发板上的真实模块。适合谁刚学完 C 和 Linux 基础命令、想动手写第一个insmod的在校生也适合做单片机转 Linux、被file_operations和probe函数绕晕的转岗开发者。下面我按「这堆源码是什么 → 怎么跑起来 → 怎么改」的顺序拆一遍中间穿插我踩过的坑。2. 源码包全景目录结构、模块划分与构建体系2.1 拿到包先看什么目录树与模块边界这类培训驱动源码包结构通常不会太花哨但分层是清晰的。我一般拿到手先tree -L 2扫一遍重点看有没有独立的drivers/、include/、scripts/和顶层Makefile。典型布局大致是这样embedded-driver-src/ ├── Makefile # 顶层构建入口负责递归进子目录 ├── Kconfig # 内核配置菜单项决定哪些模块参与编译 ├── include/ │ └── demo_ioctl.h # 用户态与驱动共享的 ioctl 命令定义 ├── drivers/ │ ├── char/ # 字符设备open/read/write/ioctl │ ├── platform/ # 平台总线device 与 driver 匹配 │ ├── interrupt/ # 中断申请、上半部/下半部 │ └── misc/ # 杂项设备注册最简单的一类 ├── apps/ # 配套用户态测试程序 └── scripts/ ├── build.sh # 一键编译脚本 └── load.sh # insmod/rmmod 与设备节点创建这个划分的价值在于每个子目录是一个可以独立编译的.ko互不依赖。你不需要一次性把整个包编过先挑drivers/misc里最简单的那个模块跑通建立信心再往platform走。我见过不少人一上来就啃平台总线结果probe不触发卡两天就放弃了。血泪经验是从 misc 设备起步从字符设备进阶最后碰平台总线和中断这个顺序和内核本身的复杂度递增是一致的。include/里放共享头文件这点很关键。驱动和用户态程序必须对同一套ioctl命令号达成一致如果两边各写各的魔数调试时就是黑匣子——ioctl返回-EINVAL你根本不知道是命令号错了还是参数结构体对不齐。所以看到包里把demo_ioctl.h单独抽出来说明作者是认真考虑过可维护性的。2.2 构建体系Kbuild 与外部模块编译驱动源码不能像普通 C 程序那样gcc xxx.c了事它必须挂在内核的 Kbuild 体系下编译。核心是每个子目录里的Makefile和顶层的递归调用。一个典型的模块 Makefile 长这样# drivers/char/Makefile obj-m demo_chrdev.o demo_chrdev-objs : chrdev_main.o chrdev_fops.o # 指向已编译好的内核源码树或 headers KDIR ? /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) all: $(MAKE) -C $(KDIR) M$(PWD) modules clean: $(MAKE) -C $(KDIR) M$(PWD) clean逐行说清楚obj-m表示这个模块编译成可动态加载的.ko而不是编进内核镜像那是obj-y。demo_chrdev-objs是「多文件合成一个模块」的写法把功能拆到chrdev_main.o和chrdev_fops.o两个目标文件里链接时合成demo_chrdev.ko——这是工程化的关键别把所有逻辑塞一个.c里。KDIR指向内核构建目录M$(PWD)告诉 Kbuild「只编译当前目录这个外部模块」这是外部模块编译的标准姿势。提示KDIR必须指向与目标开发板内核版本一致的源码树或 headers。宿主机uname -r拿到的版本和板子上跑的内核版本对不上编出来的.ko加载时会报invalid module format这是新手第一大坑后面避坑章节细说。顶层Makefile一般就是个递归壳子遍历子目录执行make。scripts/build.sh则把KDIR路径、交叉编译工具链前缀比如arm-linux-gnueabihf-这些变量集中起来避免每个子目录手改。我一般会先打开build.sh看它默认的ARCH和CROSS_COMPILE是什么改成自己板子对应的值再跑比逐个 Makefile 改省事得多。3. 核心模块拆解字符设备从注册到读写的完整链路3.1 模块入口出口与设备号申请字符设备驱动的骨架就三件事拿到设备号、注册file_operations、在/dev下能被打开。先看入口函数#include linux/module.h #include linux/fs.h #include linux/cdev.h static dev_t demo_devno; // 主次设备号合成 static struct cdev demo_cdev; // 字符设备对象 static struct class *demo_class; // 用于自动创建设备节点 static int __init demo_init(void) { int ret; /* 动态申请设备号主设备号由内核分配次设备号从 0 开始共 1 个 */ ret alloc_chrdev_region(demo_devno, 0, 1, demo_chrdev); if (ret 0) { pr_err(alloc_chrdev_region failed: %d\n, ret); return ret; } cdev_init(demo_cdev, demo_fops); // 绑定 file_operations demo_cdev.owner THIS_MODULE; ret cdev_add(demo_cdev, demo_devno, 1); if (ret 0) { pr_err(cdev_add failed: %d\n, ret); goto err_cdev; } /* 创建 /sys/class/demo_chrdev配合 udev/mdev 自动生成 /dev 节点 */ demo_class class_create(THIS_MODULE, demo_chrdev); if (IS_ERR(demo_class)) { ret PTR_ERR(demo_class); goto err_class; } device_create(demo_class, NULL, demo_devno, NULL, demo_chrdev); pr_info(demo_chrdev init ok, major%d\n, MAJOR(demo_devno)); return 0; err_class: cdev_del(demo_cdev); err_cdev: unregister_chrdev_region(demo_devno, 1); return ret; } static void __exit demo_exit(void) { device_destroy(demo_class, demo_devno); class_destroy(demo_class); cdev_del(demo_cdev); unregister_chrdev_region(demo_devno, 1); pr_info(demo_chrdev exit\n); } module_init(demo_init); module_exit(demo_exit); MODULE_LICENSE(GPL);逻辑说明alloc_chrdev_region是动态申请好处是不用手动指定主设备号、避免和系统里已有设备冲突如果你要固定主设备号比如 240换成register_chrdev_region(MKDEV(240,0), 1, demo)。cdev_init把file_operations挂上去cdev_add才真正让这个设备「活」起来。class_createdevice_create这一对是自动建节点的关键——没有它们你得手动mknod /dev/demo_chrdev c 主号 0板子上跑 mdev 的话还得改配置。错误处理用goto逐级回滚这是内核代码的惯例别嫌丑它保证了任何一步失败都不会留下半注册的残局。参数说明alloc_chrdev_region(dev, baseminor, count, name)里baseminor是起始次设备号count是申请几个连续设备号cdev_add(cdev, dev, count)的count要和申请时一致。THIS_MODULE是当前模块指针赋给owner防止模块在使用中被卸载。3.2 file_operations 与用户态读写路径file_operations是用户态系统调用落到驱动里的分发表。最小可用集合是open、release、read、write加上unlocked_ioctl做控制通道static ssize_t demo_read(struct file *filp, char __user *buf, size_t count, loff_t *ppos) { char kbuf[64] hello from kernel; size_t len strlen(kbuf); if (*ppos len) return 0; // 读到末尾返回 0 表示 EOF if (count len - *ppos) count len - *ppos; /* 内核空间到用户空间必须用 copy_to_user不能直接 memcpy */ if (copy_to_user(buf, kbuf *ppos, count)) return -EFAULT; *ppos count; return count; } static ssize_t demo_write(struct file *filp, const char __user *buf, size_t count, loff_t *ppos) { char kbuf[64]; if (count sizeof(kbuf)) return -EINVAL; if (copy_from_user(kbuf, buf, count)) return -EFAULT; kbuf[count] \0; pr_info(demo_write got: %s\n, kbuf); return count; } static const struct file_operations demo_fops { .owner THIS_MODULE, .open demo_open, .release demo_release, .read demo_read, .write demo_write, .unlocked_ioctl demo_ioctl, };逻辑说明read里维护*ppos偏移量这是支持cat多次读、read循环读的基础很多人忘了更新ppos结果cat死循环。copy_to_user/copy_from_user是硬性要求用户态指针不能直接解引用否则在开启SMAP的平台上直接崩。返回值语义也要记牢成功返回实际字节数失败返回负的 errno-EFAULT、-EINVAL返回 0 在read里表示 EOF。参数说明__user是给 sparse 静态检查用的标注提醒你这个指针来自用户空间。count是用户请求的字节数但驱动可以少返回用户态会再调一次。unlocked_ioctl的cmd和arg要和include/demo_ioctl.h里的定义严格对应_IOR/_IOW宏生成的方向位和大小位错一位ioctl就返回-ENOTTY。3.3 平台总线device 与 driver 的匹配过程平台总线是理解 Linux 设备模型的分水岭。核心是「设备」和「驱动」分开注册靠compatible字符串或名字匹配匹配成功才调probe/* 驱动侧 */ static int demo_probe(struct platform_device *pdev) { struct resource *res; void __iomem *base; res platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) return -ENODEV; /* 把物理地址映射成内核虚拟地址之后用 readl/writel 访问寄存器 */ base devm_ioremap_resource(pdev-dev, res); if (IS_ERR(base)) return PTR_ERR(base); platform_set_drvdata(pdev, base); dev_info(pdev-dev, demo_probe matched, reg base mapped\n); return 0; } static const struct of_device_id demo_of_match[] { { .compatible demo,virtual-dev }, { } }; MODULE_DEVICE_TABLE(of, demo_of_match); static struct platform_driver demo_driver { .probe demo_probe, .remove demo_remove, .driver { .name demo_platform, .of_match_table demo_of_match, }, }; module_platform_driver(demo_driver);逻辑说明of_match_table里的compatible必须和设备树.dts里节点的compatible完全一致匹配才会发生。devm_ioremap_resource是「带资源管理」的映射驱动卸载时自动iounmap省掉手动释放这是现代驱动推荐写法。platform_set_drvdata把映射后的基地址存进pdev后续remove或其他回调里用platform_get_drvdata取回来。参数说明platform_get_resource(pdev, IORESOURCE_MEM, 0)的第三个参数是资源索引一个设备有多个内存区间时靠它区分。devm_前缀的函数都绑定到pdev-dev生命周期上设备销毁即释放。调试probe不触发时先cat /sys/bus/platform/drivers/demo_platform/看驱动是否注册成功再ls /sys/bus/platform/devices/看设备在不在两边都在却不匹配九成是compatible拼写或设备树没编进 dtb。4. 跑起来交叉编译、加载与验证的完整步骤4.1 环境准备与内核头文件对齐跑驱动第一步不是写代码是把「编译环境」和「目标板内核」对齐。宿主机上装交叉工具链确认版本# 以 ARM 为例确认工具链可用 arm-linux-gnueabihf-gcc -v # 确认目标板内核版本在板子上执行 uname -r # 输出例如 5.10.0-demo # 宿主机上准备对应版本的内核源码或 headers ls /opt/kernel/linux-5.10.0-demo/ # 必须包含 include/、scripts/、Module.symvers 等关键点Module.symvers文件必须存在它记录了内核导出符号的 CRC 校验值缺了它编译会警告Symbol version dump not found加载时可能报disagrees about version of symbol。如果板子厂商只给了 headers 没给完整源码至少要有Module.symvers和include/目录。我一般会先在板子上cat /proc/version和ls /lib/modules/$(uname -r)/确认有没有现成的build软链有的话直接指过去最省事。4.2 编译、传输与加载验证环境对齐后编译和加载是一条流水线# 1. 指定内核路径和交叉编译前缀编译所有模块 make KDIR/opt/kernel/linux-5.10.0-demo \ ARCHarm CROSS_COMPILEarm-linux-gnueabihf- -j4 # 2. 传输到开发板假设已配好网络或串口 scp drivers/char/demo_chrdev.ko root192.168.1.100:/root/ # 3. 板子上加载模块 insmod /root/demo_chrdev.ko dmesg | tail -20 # 看 init 打印和主设备号 ls -l /dev/demo_chrdev # 确认节点自动生成 # 4. 功能验证 echo test /dev/demo_chrdev cat /dev/demo_chrdev # 5. 卸载 rmmod demo_chrdev每一步的验证点要说清insmod后dmesg里应该看到demo_chrdev init ok, majorxxx没有这行说明module_init没执行或返回了错误ls /dev/demo_chrdev存在说明class_create/device_create生效不存在但dmesg正常多半是板子没跑 mdev/udev手动mknod补上即可。echo写入后dmesg应打印demo_write got: testcat应输出hello from kernel。rmmod后dmesg有exit打印且lsmod里不再有该模块。注意rmmod报Module is in use时先lsof /dev/demo_chrdev看有没有进程占着设备节点再检查demo_cdev.owner是否设成了THIS_MODULE。owner 没设内核不会帮你做引用计数卸载时可能直接崩。5. 避坑与排查驱动加载失败的五种典型现场5.1 invalid module format版本对不上现象insmod直接报invalid module formatdmesg里跟一句disagrees about version of symbol module_layout。原因几乎总是编译用的内核版本和板子运行的内核版本不一致或者Module.symvers缺失导致符号 CRC 对不上。解决用板子uname -r的精确版本重新准备内核树确认KDIR指向它make clean后重编。别试图用modprobe --force绕过强制加载一个版本不匹配的模块轻则功能异常重则内核 oops。5.2 probe 不触发compatible 或设备树没生效现象驱动insmod成功/sys/bus/platform/drivers/下能看到驱动但probe里的打印始终不出现。原因通常是设备树里节点的compatible和of_match_table不一致或者改完.dts没重新编译 dtb、没更新到板子的启动分区。解决cat /proc/device-tree/下对应节点确认compatible实际值逐字符比对改 dtb 后确认板子启动加载的是新文件看启动日志里的 dtb 时间戳或大小。5.3 设备节点不生成class 与 mdev 配置现象dmesg显示 init 成功、主设备号也打印了但/dev下没有节点。原因是class_create/device_create只负责在/sys/class/下建目录真正在/dev建节点要靠用户态的 udev 或 mdev。解决确认板子 rootfs 里 mdev 是否在启动脚本里被调用echo /sbin/mdev /proc/sys/kernel/hotplug没有就手动mknod /dev/demo_chrdev c 主号 0先验证功能再补 mdev 配置。5.4 copy_to_user 返回非零被忽略现象cat设备时偶尔输出乱码或截断dmesg无异常。原因是copy_to_user失败用户缓冲区不可写、跨页边界时返回未拷贝字节数代码里没检查返回值就当成功了。解决所有copy_to_user/copy_from_user的返回值都要判非零返回-EFAULT。这类问题在 x86 上可能不复现换到 ARM 板子上才暴露属于典型的「换平台翻车」。5.5 并发访问没加锁导致数据错乱现象多进程同时读写同一个设备偶发数据错乱或内核警告。原因是read/write共享的全局缓冲区没有保护多个执行流同时进入临界区。解决用mutex或spinlock保护共享数据字符设备场景一般用mutex可能睡眠就够中断上下文里访问共享数据才必须用spinlock。加锁范围要覆盖「读共享变量 → 修改 → 写回」整段别只锁一半。6. 二次开发把示例模块改成自己的设备驱动拿到这套源码真正的价值不是跑通示例而是把它当模板改造成自己板子上的驱动。我的做法是固定一条改造路径先复制drivers/char整个目录改名再按「换设备号 → 换 fops → 加 ioctl → 接硬件寄存器」四步走。第一步把alloc_chrdev_region的name和device_create的节点名换成自己的避免和示例冲突第二步保留open/release骨架把read/write里的假数据换成真实的数据通路第三步在include/里新增自己的ioctl命令头用_IOW/_IOR定义用户态程序#include同一个头文件杜绝魔数对不齐第四步才是接硬件——如果是平台设备把probe里的devm_ioremap_resource拿到的base用readl/writel操作寄存器偏移量对照芯片手册逐个核对。验证方法我习惯分三层第一层纯软件验证不接硬件read/write返回构造的假数据确认 fops 链路通第二层接上硬件但只读不写用devm_ioremap映射后readl打印寄存器复位值和手册比对确认地址映射没错第三层才做读写闭环。这个分层能让你在出问题时快速定位是「驱动框架错」还是「硬件地址错」而不是一锅乱炖。一个具体技巧改造时保留原示例模块不删新模块用不同的name和节点名并存加载。这样一旦新模块把系统搞挂你还能rmmod掉它、用示例模块验证内核本身没坏。我吃过一次亏——把示例模块直接改崩insmod就 panic连排查的立足点都没了只能重新烧固件。从那以后我每次改造驱动都强制保留一个「已知能跑」的基线模块并存出问题先回退到基线确认环境再逐步加改动。希望这个习惯能帮到你少烧几次固件。本文还有配套的精品资源点击获取