RK安卓驱动开发入门：设备树、内核分层与调试实战

前面提前说明一下这篇文章是系列里的第 2 篇上一篇主要讲了 RK 开发环境的搭建和刷机流程这篇就把小白真正开始写驱动之前需要补的底层知识一次性讲清楚。文章里没有“快速入门”那种虚话只有你站在一个真实 RK 开发板面前、拿到一份真实源码树的时候必须搞明白的那些事。整套知识走一遍之后你会发现 RK 安卓驱动开发并没有想象中那么玄乎它本质上就是“看懂设备树、找对代码位置、打通一条数据通路、会看日志验证”。把这四件事串起来剩下的就是熟能生巧。1. RK 安卓系统里驱动到底藏在哪几层1.1 从开机到 App 运行驱动出现在两个关键位置很多新人拿到 RK 开发板时都会有个错觉以为安卓驱动开发就是改一堆 C 代码。实际上在安卓系统里“驱动”从来不是一个孤立的东西它是一整套从硬件到 App 的分层协作机制。我们可以把 RK 安卓系统想象成一个餐厅。App 就是坐在外面的客人Framework 是前厅经理HAL 层是传菜窗口Linux 内核是后厨而驱动就是后厨里的灶台和炉具。客人点一道菜前厅经理下单传菜窗口接单后厨根据订单去操作灶台灶台负责把食材变成成品。驱动开发者的工作就是保证灶台好使并且让传菜窗口和后厨之间有正确的沟通方式。具体到 RK 安卓系统的软件栈从上到下大致是这样App 层你的 APK通过标准 Android API 调用硬件能力。Framework 层系统服务负责把 App 的需求翻译成对硬件服务的调用。HAL 层硬件抽象层直接面对硬件服务的具体实现通常表现为 .so 动态库。Linux 内核层真正的设备驱动所在地直接操作寄存器、中断、DMA。BootloaderU-Boot 加 RK 自研的 miniLoader负责最上电的硬件初始化。真正跟驱动开发强相关的也就是两个位置内核里的设备驱动以及 HAL 层里的硬件适配代码。很多时候新人以为自己要从头写一个驱动其实 RK 平台已经把绝大多数外设驱动写好了你只是在 HAL 层补适配、在设备树里改配置而已。搞清楚这个层级遇到问题时你才知道该去哪个目录看代码、该在哪一层加 log而不是一头扎进源码到处翻。1.2 RK SDK 源码目录速查先认路再动手RK 的安卓 SDK 是典型的厂商 BSPBoard Support Package目录结构比纯 AOSP 多了一堆与具体板卡相关的代码。新手第一次打开源码根目录很容易被几十个文件夹吓到。其实你只需要先记住几个最关键的位置。目录作用驱动开发者的关注度kernel/Linux 内核源码驱动代码主要就在这里极高device/rockchip/板级配置dts 设备树源文件、init.rc、SELinux 策略极高hardware/rockchip/瑞芯微自研 HAL 层代码例如显示、媒体、传感器适配高external/第三方库和解码芯片源码中u-boot/U-Boot 引导代码低除非改启动配置out/编译输出目录镜像和 dtb 都在这中我见过不少新人犯的同一个错误拿到需求后直接去 kernel/drivers 里找i2c-foo.c这个要写的驱动文件结果发现根本找不到再去论坛一问才知道这类驱动通常在hardware/rockchip或者外设厂商提供的 SDK 里。所以我的习惯是拿到一份 SDK 后先花半天时间把上面表格里的目录各自打开看一眼知道什么东西大概在哪个位置。等真出了问题grep -rn才能有目标的搜而不是全盘乱搜。2. 瑞芯微平台凭什么跟“普通 Linux 驱动开发”不一样2.1 厂商 BSP 内核版本看着旧是有原因的很多新人第一次启动 RK 的内核编译时会惊讶地发现内核版本停在 4.19 或者 5.10而网上主线 Linux 已经出到 6.x 了。这时候千万别着急怀疑自己下载了一份过时的源码这是厂商 BSP 的正常形态。BSP 的含义是“让板子最快跑起来”的一套软件包它不需要跟随主线内核的更新节奏。瑞芯微的工程师会选定一个稳定的 LTS 内核版本然后在此基础上打入 GPU、NPU、视频编解码、显示控制器等一大堆深度定制的补丁这些补丁一旦跟随主线升级往往要重新适配底层改动工作量和踩坑风险都太大了。类似的情况在安卓版本和内核版本的搭配上也存在。某一条 RK 芯片的产品线安卓 11 通常配 kernel 4.19安卓 12 以上配 kernel 5.10这种组合在出厂 SDK 里是验证过的。你没拿到板子的全部资料自己瞎升级内核版本是极其危险的行为轻则启动失败重则直接点不亮屏幕。理解这一点你就能明白为什么 RK 平台的驱动尤其是显示、GPU、视频编解码这类复杂外设基本都以内核内置模块的形式存在极少会让你从外面去加载一个通用驱动。2.2 树内驱动和树外驱动RK 默认喜欢哪种接触 Linux 驱动开发的人一定听说过“树内”和“树外”这两个说法。树内驱动就是代码已经放在内核源码树里面编译内核的时候一并编进 zImage 或者作为模块一起产出。树外驱动则是源码放在内核源码树之外用内核的模块编译机制单独编译成 .ko 文件再手动加载。RK 平台整体上极度偏向树内驱动。原因很好理解瑞芯微是卖给整机厂家的芯片方案商客户拿到的板子如果连基本外设都点不亮要自己去下载网卡驱动、触摸屏驱动、传感器驱动这个产品基本没法交付。所以 RK 出厂 SDK 里板载外设的驱动比如以太网、WiFi、蓝牙、EMMC、显示接口、USB PHY几乎全都在内核源码树里。这对新人是个很好的消息你其实很少需要从零写一个驱动。更多的工作形态是外设芯片是新的厂商给了一份参考驱动你把它挪进 RK 的内核树按照 RK 的设备树规范改兼容属性和资源配置再编译烧录验证。基于这种形态我建议新人养成一个习惯遇到驱动问题先在 kernel 源码树里全局搜索芯片型号比如grep -rn 型号 kernel/drivers/八成以上情况能找到可用的参考代码改一改就完事比闭门造车高效得多。2.3 交叉编译环境别在源码层面内耗RK SDK 自带了一套已经配置好的交叉编译工具链通常在 SDK 根目录的prebuilts/下不太需要你像纯 Linux 环境那样下载一个 arm-linux-gnueabihf-gcc 再手动配置。新人在这一步踩的坑一般是两个。一是直接用 PC 的 gcc 去编内核镜像结果编出来的产物没法在 ARM 平台运行。这种情况在终端输出错误信息时其实很显眼但新人容易忽略以为报错是源码问题。二是选错了编译脚本。RK 的 SDK 在外层一般有一个build.sh或者make.sh来编译完整镜像内核独自编译则要进到 kernel 目录里找一个 RK 封装好的编译脚本不同时期的 SDK 脚本名字略有差异需要先看README或者脚本头部注释再执行。拿我自己调试的阶段来说我会优先单独编内核和 dtb而不是每次都整套镜像一起编。整套镜像动辄二三十分钟起步单编内核很多时候五分钟内就出结果调试效率差了一个量级。这个心得很值得你在前期就建立。3. 设备树就是 RK 驱动的第一道门槛绕不开3.1 设备树是干什么的硬件版“货架标签”设备树Device Tree这个概念对很多安卓转行过来的开发者很陌生它是从 Linux 社区自然长出来的机制。在很早以前Linux 内核每支持一款板子就要在源码里面加一堆关于这块板子硬件型号、内存大小、外设挂在哪个控制器上的硬编码代码。任何板级差异都得重新改内核源码非常痛苦。设备树的做法是把这些硬件描述全部抽离出来变成一份独立于内核代码的文本文件——设备树源文件即 .dts 文件。你可以把设备树想象成超市货架上的标签。货架本身是内核里的通用框架代码插座、灯光、传感器之类的硬件是货物设备树标签上写清楚了每个货物放在哪个位置、需要多少电压、用什么方式接入。内核看到标签后就知道该怎么把对应驱动和硬件配对起来。RK 平台对设备树的依赖比其他平台更重因为 RK 芯片管脚复用功能异常复杂一个引脚可能要同时兼容 I2C、GPIO、UART、PWM 好几套功能具体用哪个全靠设备树里的pinctrl配置来决定。不会读设备树你在 RK 平台上就寸步难行。3.2 RK 的 dts/dtsi 组织方式公共部分和板级部分分开RK 平台的设备树文件结构上遵循一套很清晰的约定。板级配置里最常见的就是rk3399-evb.dts这种以板卡名命名的文件它是最终被编译出来的对象。但新人改设备树时经常会被#include rk3399.dtsi这类语句搞迷糊。简单解释一下.dtsi文件是头文件性质描述某个 SoC 上所有型号通用的硬件资源比如 CPU 有几个核、中断控制器在哪个地址、I2C 控制器挂在哪里。这个文件不该由你去乱动它是芯片原厂定义好的..dts文件则是具体的板级描述它的内容是在继承.dtsi的基础上进行裁剪或者追加。比如同一颗 RK 芯片A 板用触摸屏B 板不用那触摸屏节点就应该写在各自的.dts里而不是写在公用的.dtsi里。实际改驱动时我总结下来只需要重点关注几个属性。第一是compatible它是驱动与硬件匹配的“钥匙”。驱动代码里会声明自己支持的设备名字符串设备树里也有一份对应字符串两者对上驱动才会 probe 执行。第二是status它决定这个节点是否启用。默认一段节点可以写disabled板级文件里再覆盖成okay。新人经常遇到的现象就是节点写得没问题但忘了把状态从disabled改成okay导致驱动完全没跑。第三是pinctrl它控制引脚的复用功能和数据方向。RK 的 GPIO 配置基本上都体现在这里随便少写一个配置轻则信号方向不对重则直接把某个控制器搞死。下面是一个非常典型的 I2C 外设节点写法你在 RK 的板级 dts 里会经常见到i2c3 { status okay; clock-frequency 400000; touchscreen38 { compatible goodix,gt911; reg 0x38; interrupt-parent gpio1; interrupts RK_PB4 IRQ_TYPE_EDGE_FALLING; pinctrl-names default; pinctrl-0 gt911_int_gpio; reset-gpios gpio1 RK_PB5 GPIO_ACTIVE_LOW; }; };初次看一眼这个片段不用全部理解你只需要记住触摸屏在哪个 I2C 控制器下、挂在哪个地址、中断脚和复位脚分别占用哪颗 GPIO全部由这一小段文字描述。驱动代码里读到的硬件信息都来自于这段描述。3.3 改完设备树之后编译和打包才是成败关键许多新人都有过这种经历dts 节点改得信心满满烧进板子后却发现硬件完全没反应折腾两小时最后发现是设备树根本没有被更新进去。RK 平台的设备树不像某些平台那样独立成一个 dtb 分区那么单纯。不同时期、不同芯片的方案dtb 的存放位置五花八门有些放在 boot.img 里有些放在单独的资源分区里还有些会在编译时被封装进 kernel 镜像里。这就导致“编译成功”和“烧录成功”是两个必须同时满足的条件缺一不可。一个比较通用的操作流程大概是# 进入内核目录先配置环境 cd kernel # 执行 RK 内核编译脚本通常会自动生成 dtb ./make.sh rk3399-evb编译结束后在kernel/的输出目录里找到 dtb 文件然后看 SDK 打包脚本的规则将其复制到boot.img或者 RK 的资源镜像里再执行整包打包。这一套流程不同 SDK 版本差别不小我的建议是看你拿到的那份 SDK 里的打包脚本以它实际处理了什么为准。验证设备树是否真正生效有一个很直接的命令。板子启动后执行cat /proc/device-tree/model cat /proc/device-tree/path/to/node/status如果读到的内容和你在 dts 里写的保持一致说明设备树已经成功生效。如果读出来还是旧状态那就是打包或者烧录环节出了问题不要犹豫直接回去检查流程。4. 跟着一次“点灯到读传感器”的完整旅程打通数据通路4.1 最小驱动长什么样认识 file_operations不管 RK 平台怎么封装Linux 字符设备驱动的基本骨架是一致的。一个最简单的驱动本质上就是给用户空间打开一个可以操作的文件节点。#include linux/module.h #include linux/fs.h #include linux/miscdevice.h static int demo_open(struct inode *inode, struct file *file) { return 0; } static ssize_t demo_read(struct file *file, char __user *buf, size_t count, loff_t *pos) { // 这里把内核态数据拷贝回用户空间 return 0; } static const struct file_operations demo_fops { .owner THIS_MODULE, .open demo_open, .read demo_read, }; static struct miscdevice demo_dev { .minor MISC_DYNAMIC_MINOR, .name demo, .fops demo_fops, }; static int __init demo_init(void) { return misc_register(demo_dev); } static void __exit demo_exit(void) { misc_deregister(demo_dev); } module_init(demo_init); module_exit(demo_exit); MODULE_LICENSE(GPL);这个骨架虽然简单但信息量很足。它告诉你驱动开发最核心的概念驱动在内核里注册后会在/dev下生成一个节点应用程序对节点执行 open、read、write 时最终都会调用到驱动里对应的回调函数。RK 平台上大量外设驱动本质上就是在这些回调函数里写寄存器、读寄存器、处理中断、上报数据。4.2 内核态到用户态的数据交换不止 read/write 一条路很多新手学了字符设备就以为驱动数据只能通过 read/write 传实际上 RK 项目里常用到的数据通路至少有下面这几种。第一种是 read/write适合简单、低速的数据传输比如读取某个传感器的原始值。第二种是 ioctl适合传递复杂的控制命令比如设置触摸屏的报点率、设置 PWM 的占空比这类命令用 read/write 表达起来很别扭ioctl 可以直接传结构体。第三种是 sysfs 属性文件在/sys/class/xxx/下暴露一个文件读它得到一个值写它设置一个值适合调试场景非常方便。第四种是内核的 input 子系统专门给触摸屏、按键、手柄这类输入设备准备的驱动上报事件后上层无论 Android 还是纯 Linux 都能收到标准输入事件。实际项目里一个外设驱动可能会同时用上几种方式。比如我调试一个光线传感器时用 sysfs 查看当前照度值快速定位硬件问题确认硬件通路没问题后再接入 HAL走标准的读取接口上报给 Android 系统。清楚每种通路的适用场景会省掉你很多无效调试时间。4.3 用触摸屏把整条链路串起来我每次带新人走这条链路都习惯拿触摸屏举例因为它最贴近日常体验又能覆盖完整的驱动开发流程。触摸屏的触控芯片挂在 I2C 总线上。SoC 是 I2C 控制器的主机触控芯片是从机设备树里要写上它的 I2C 地址。触控芯片的中断引脚连到 SoC 的一个 GPIO 上一旦有人触摸屏幕触控芯片会拉低这个引脚SoC 收到中断后通过 I2C 总线去读取触摸坐标数据。内核驱动的工作是初始化时申请中断注册一个 input 设备触摸事件发生时去读回坐标数据然后调用上报接口把这些数据送进内核的输入子系统。上层 Android 系统会有读线程打开/dev/input/eventX节点拿到标准输入事件后分发给应用。这条链路看起来很长但核心驱动开发者真正要保证的只有两件事一是驱动能成功 probe也就是设备树匹配成功、资源申请成功二是中断来了之后能正确读取坐标并上报。至于 Android 上层怎么处理这些坐标那是 framework 的事不用你操心。新人最容易卡壳的部位恰恰是第一件事设备树匹配失败驱动根本没跑起来。所以在学这套通路时请务必先学会看内核日志dmesg里有没有驱动 probe 的打印。5. 初学阶段最该掌握的三把调试钥匙日志、节点、寄存器5.1 内核日志printk 和串口是开发者的眼睛在 RK 平台开发驱动没有一套趁手的日志查看手段基本等于盲修。最常用的就是内核的printk它可以在驱动代码里直接打印调试信息。但 printk 分级别默认情况下优先级低于控制台那个级别的日志不会在串口上显示所以调试期你会经常看到这段经典操作。printk(KERN_DEBUG gpio state: %d\n, state);开发阶段为了看到更多调试日志可以把内核启动参数里的 loglevel 调低比如loglevel8这样几乎所有内核打印都会往串口吐。等你确认问题点在哪儿再把级别调回去否则日志刷屏会严重影响系统实时性。串口日志在 RK 板上是标配调试手段一般是通过调试串口转 USB 接到电脑波特率常见 1500000具体看你的 SDK 文档。如果你手头没有串口只用dmesg也能查看内核环形缓冲区里的日志但dmesg只能看开机以后到当前时刻的滚动日志某些早期启动阶段的细节会丢失不利于排查启动早期的驱动问题。所以我给你的建议是早期调试尽量接串口把 loglevel 放开这是所有后续排查的基础设施。5.2 设备节点和 sysfs驱动活了没有这里看得清清楚楚驱动是否成功注册设备节点是最直接的证据。比如你写了一个 misc 字符设备名字叫 demo正常情况下系统起来后执行ls /dev/demo能看到这个文件说明驱动已经注册成功节点已经创建。如果看不到那基本可以断定驱动没有走到设备创建那一步。sysfs 是另一个非常有用的观测入口。RK 驱动和设备树结合的紧密程度很高设备树节点在运行时也会在/sys下有对应表现。想知道某个 I2C 设备是否被内核枚举到执行ls /sys/bus/i2c/devices/能看到类似3-0038这样的目录代表 I2C 总线上检测到了地址 0x38 的设备。如果这个目录都没有说明硬件侧或者设备树侧还有问题压根没达到驱动的探测阶段。这些命令都很轻量却能把问题快速分片设备有没有被识别、驱动有没有绑定、节点有没有创建三件事分开验证排查效率极高。5.3 寄存器视角直接和硬件对话的最后一招驱动开发的底层其实就是配置寄存器。RK 芯片的数据手册里有大量寄存器地址和位域定义驱动代码无论写得多么花哨最终都会落到“读某个地址、改某个位、再写回去”这样的操作上。有时你需要快速验证一个 GPIO 输出能不能正常拉高拉低或者某个 I2C 控制器有没有工作与其重新编译一个驱动不如直接在命令行里操作寄存器。在 RK 的板子上如果有 root 权限可以尝试用 devmem 工具直接读写物理地址devmem 0xFF010000 32 0x12345678这个命令代表往物理地址0xFF010000写一个 32 位的值。但请牢记这只是一个示例具体地址和值必须严格参考你手上这块 RK 芯片的用户手册不同芯片地址完全不同。随意写寄存器很容易把某个外设搞挂甚至引起系统死机。我一般只把它当作最后验证手段。比如确认某颗 GPIO 对应的寄存器地址后直接写值观察电平变化几秒钟就能判断硬件通路是否正常比跑一遍完整驱动快得多。不过这种操作不适合作业长期使用定位问题后还是要回到驱动代码里去实现一个正式的接口。6. 新手最容易踩的五个坑自查顺序和解决思路6.1 驱动根本没 probe先查设备树匹配链路“我明明把节点加上了为什么驱动没执行 probe”这是我在各种 RK 技术群里看到最高频的问题没有之一。排查思路要按固定顺序走。先确认设备树节点本身编译进了最终的 dtb用上一节说的cat /proc/device-tree/...验证。再确认节点 status 是okay而不是disabled。然后确认驱动里的compatible字符串和设备树里的字符串完全一致注意大小写和下划线都算不同字符。最后确认节点挂在正确的父控制器下比如 I2C 外设的节点要放在i2c3这种引用块里面而不是与它平级。这个顺序我建议你背下来每次排查都从第一步走起而不是一上来就怀疑驱动代码逻辑否则很容易陷入反复看代码却找不到问题的死循环。6.2 编译错误扎堆先解决环境再解决代码RK 内核编译错误有一大半其实和环境相关。比如工具链路径不对、缓存残留、SDK 目录不是解压在纯英文路径下之类。新人最容易忽略的坑是把 SDK 解压在带空格的 Windows 目录下又通过共享目录传到 Linux 去编译结果一堆路径解析错误。这种问题会以千奇百怪的编译报错形式出现非常打击信心。我的建议是 SDK 务必放在 Linux 的原生文件系统上路径里尽量别有空格和非 ASCII 字符。真正属于源码本身的编译错误通常报错文件和数据类型的线索密切相关比如函数参数类型不匹配、头文件没包含、结构体成员名写错了。这类问题多做几次编译就能找到感觉不用慌。6.3 节点存在但上层操作失败权限和 SELinux 的锅在 RK 安卓系统里设备节点即使创建成功上层应用不一定有权限访问。Android 的 SELinux 机制对设备节点的访问做了严格管控。现象往往是这样ls /dev/demo能看到节点但 adb shell 里 echo 写入一个值直接报 permission denied。这时第一反应不是怀疑驱动而是看看 SELinux 策略里有没有给对应进程放行对demo节点的访问。RK SDK 的 SELinux 策略文件分散在device/rockchip下的sepolicy目录里新人可以先找到目标服务的 te 文件查看是否允许它的权限。实在图省事很多开发者会在调试阶段把 SELinux 设为 permissive 模式但这绝对不能带进量产版本环境差异极易造成线上诡异故障。我见过多个项目因为 SELinux 权限没放开导致整个新功能在 demo 板上正常、在完整系统上失灵的现象最后耗费好几天定位。所以这条坑前期就要有意识地绕开。6.4 烧录后没变化多半是没打对包如果你经历过“花了两个小时编内核烧进去完全没有效果”的绝望下面这句话请刻在脑子里RK 平台烧录的往往不是 zImage 或者 dtb 本身而是一个整合过的镜像文件。有的平台把设备树打包进boot.img有的平台单独有一个resource.img存放相关资源不同芯片方案差异不小。如果你只编译了 dtb但没有把它放进最终烧录的镜像里那烧进去的东西对你来说毫无意义。针对这个问题我的建议是找一个你熟悉的 RK 板卡完整走一遍“修改 dts、编内核、打包、烧录、验证”全链路把每一层产物都摸清楚。只要这一遍走通之后所有驱动调试的路径就都顺了这一环是值得花时间投资的。6.5 系统起不来优先看上电时序和 boot logRK 板子系统起不来不要急着怀疑驱动改动你要先判断问题出在哪个阶段。如果是 Bootloader 阶段就挂了多半是内存初始化或启动参数有问题。如果 U-Boot 能起来但内核起不来那才轮到内核驱动背锅。上电时序这个因素在 RK 平台上特别容易被新手忽略。RK 的芯片对电源、时钟、复位信号的要求很严上电顺序不对会导致系统直接挂在早期阶段连 log 都不输出。这时如果你有示波器可以看各电源轨的建立顺序如果没有尽量对照官方 EVB 板原理图来检查。另一个基础操作是第一时间抓全串口 boot log从按下电源键那一刻开始记录。看不到任何 log 和能看到 log 但卡在某个位置是两种完全不同的排查路线前者先查硬件电源后者先在 log 附近找内核崩溃信息。写驱动的路上前面几章的知识你可能会快速掌握但这五个坑可能会反复横跳。遇到时不用慌按上面的顺序一步步排查大概率能找到一个具体的因果链而不是玄学问题。最后分享一点我自己的体会。我每次带新人上手 RK 驱动开发都会建议他们不要一开始就啃全篇源码而是先拿一块自己的板子按照“改设备树点亮一颗 LED - 给现有 I2C 传感器驱动加一个新参数 - 自己从零写一个最简单的 GPIO 驱动”这个路线走一遍。走完这三步你对设备树、驱动骨架、数据通路、打包验证这四件事就有了肌肉记忆。前置知识这本书永远是边做边查最有效把这篇文章当作你的字典动手时遇到哪个问题翻到哪一节比一口气背完再用要实用得多。