1. 从零开始认识RK312X平台与ACM功能大家好我是老张一个在嵌入式圈子里摸爬滚打了十多年的老码农。今天想和大家深入聊聊一个在RK312X平台上搞Android 7.1开发时几乎人人都会踩的坑ACM驱动的配置和那个让人头疼的内核崩溃问题。如果你正在用瑞芯微的RK312X芯片做智能盒子、工控平板或者其它嵌入式设备并且需要让设备通过USB模拟成一个串口CDC ACM和电脑通信那这篇文章可能就是为你准备的“避坑指南”。先简单说说ACM是啥。你可以把它理解成一种“USB转串口”的虚拟技术。你的RK312X设备通过USB线连上电脑后电脑上会多出一个COM口Windows或者ttyACM设备Linux/Mac就像插了一个USB转串口的线一样。这样你就可以通过这个虚拟的串口用串口调试工具和你的设备进行通信了传点调试日志、发个控制命令什么的非常方便。这在嵌入式开发里尤其是前期调试阶段是个高频需求。那为什么偏偏是RK312X和Android 7.1呢因为这个组合在不少存量项目和特定领域比如一些需要稳定老版本系统的商显设备里还挺常见。瑞芯微提供的SDK框架比较成熟但正因为是“成熟”很多默认配置和隐藏的逻辑如果你不深究一旦出问题就会像掉进迷宫。我当初接手一个老项目就为了调通这个ACM功能花了整整两天时间跟内核崩溃日志“搏斗”最后才揪出那个不起眼的instances变量。下面我就把从环境准备、配置、测试到崩溃分析、修复的完整过程掰开揉碎了讲给你听。2. 手把手配置让ACM功能跑起来配置ACM功能说白了就是告诉系统两件事第一内核要支持这个功能第二Android系统层要知道怎么启用它。很多新手觉得配驱动很难其实按步骤来就跟搭积木差不多。2.1 内核配置检查打好地基首先我们得确认内核编译选项已经打开了ACM相关的支持。瑞芯微原厂SDK在这方面通常做得不错大部分配置已经预设好了。但我们不能想当然最好自己检查一下。进入你的内核源码目录比如kernel/使用make menuconfig命令需要先配置好交叉编译环境来查看。关键是要找到以下几个配置项确保它们被设置为y编译进内核而不是m编译为模块或空着CONFIG_USB_GADGETy这是USB设备端Gadget功能的总开关必须打开。CONFIG_USB_GADGET_DEBUG_FILESy这个建议打开它会在/sys/class/android_usb/下生成很多调试节点方便我们排查问题。CONFIG_USB_G_ANDROIDy这是Android专用的USB Gadget驱动框架我们的ACM功能是基于这个框架的。更直接的方法是查看内核的默认配置文件defconfig。对于RK312X这个文件通常是arch/arm/configs/rockchip_defconfig或者类似的名字。你可以用grep命令快速过滤grep -E CONFIG_USB_GADGET|CONFIG_USB_G_ANDROID|CONFIG_USB_F_ACM .config你应该能看到类似下面的输出确认它们的存在CONFIG_USB_GADGETy CONFIG_USB_GADGET_DEBUG_FILESy CONFIG_USB_GADGET_VBUS_DRAW500 CONFIG_USB_G_ANDROIDy这里你可能没看到直接的CONFIG_USB_F_ACM这是因为ACM作为一种“function”功能是被CONFIG_USB_G_ANDROID所包含和管理的它通常不是一个独立的内核模块选项。只要上面几项是y内核层面的支持就基本没问题了。2.2 Android系统配置设置触发条件内核准备好了接下来要告诉Android系统“当用户想切换成ACM模式时你该做什么”。这个配置是通过一个叫init.rc的脚本文件完成的。在瑞芯微的SDK里USB相关的配置通常放在device/rockchip/common/init.rk30board.usb.rc这个文件里。这个文件里定义了一些“触发器”trigger当系统属性sys.usb.config发生变化时就会执行对应的命令块。我们重点看acm和acm,adb这两个触发器。原厂配置可能已经有了但我们还是来理解一下每一行命令的意思on property:sys.usb.configacm # 先禁用USB功能 write /sys/class/android_usb/android0/enable 0 # 设置USB厂商ID和产品ID2207:0005是瑞芯微常用的测试ID write /sys/class/android_usb/android0/idVendor 2207 write /sys/class/android_usb/android0/idProduct 0005 # 设置要启用的功能为“acm” write /sys/class/android_usb/android0/functions ${sys.usb.config} # 重新使能USB功能 write /sys/class/android_usb/android0/enable 1 # 更新系统状态属性 setprop sys.usb.state ${sys.usb.config}看到这里你可能觉得配置已经很完整了。我一开始也这么想按照这个配置编译烧录然后在设备的adb shell里执行setprop sys.usb.config acm设备重启USB枚举电脑也“叮咚”一声发现了新硬件。但问题来了在Windows设备管理器里它没有出现在预期的“端口(COM和LPT)”下面而是被识别为一个“通用串行总线设备”并且叹号提示驱动有问题。手动指定驱动或者卸载重装都没用。这说明设备虽然响应了但ACM功能并没有被正确初始化和暴露给主机。这就是第一个坑的入口。3. 深入坑底instances变量与第一次尝试遇到电脑识别异常第一反应就是看内核日志dmesg或cat /proc/kmsg。但奇怪的是切换过程的内核日志非常“干净”没有明显的错误Error或者警告Warning。这说明流程在框架层面走通了但功能内部出了岔子。这时候就需要去啃代码了。3.1 代码追踪发现关键变量ACM功能的实现代码一般在drivers/usb/gadget/android.c文件中不同内核版本路径可能略有差异。我们需要关注两个核心函数acm_function_bind_config绑定配置即启用ACM时调用和acm_function_unbind_config解绑配置即关闭ACM时调用。仔细看acm_function_bind_config函数我发现了问题所在。为了让你更清楚我把关键代码逻辑摘出来static int acm_function_bind_config(struct android_usb_function *f, struct usb_configuration *c) { int i; int ret 0; struct acm_function_config *config f-config; config-instances_on config-instances; // 关键行 for (i 0; i config-instances_on; i) { ret usb_add_function(c, config-f_acm[i]); if (ret) { pr_err(Could not bind acm%u config\n, i); goto err_usb_add_function; } } return 0; // ... 错误处理代码 }看第7行config-instances_on config-instances;。这行代码的意思是将准备启动的ACM实例数量instances_on设置为配置中设定的总实例数量instances。那么config-instances这个值是从哪来的呢它通常是通过sysfs文件系统从用户空间也就是Android层设置的对应的节点路径是/sys/class/android_usb/android0/f_acm/instances。坑点来了在标准的Android切换流程中比如通过setprop系统只会去写functions节点而不会主动去写f_acm/instances这个节点这就导致config-instances的值默认是0。因此config-instances_on 0后面的for循环根本不会执行usb_add_function一次都没被调用。ACM功能实际上没有被添加到USB配置中这就是为什么电脑识别不到虚拟串口的原因。3.2 第一次修复尝试简单粗暴的修改找到原因修复思路就很直接了在Android的rc脚本里切换模式时手动给instances节点写入一个值通常是1表示启用一个ACM实例。于是我把rc脚本修改成了这样on property:sys.usb.configacm write /sys/class/android_usb/android0/enable 0 write /sys/class/android_usb/android0/idVendor 2207 write /sys/class/android_usb/android0/idProduct 0005 # 新增设置ACM实例数为1 write /sys/class/android_usb/android0/f_acm/instances 1 write /sys/class/android_usb/android0/functions ${sys.usb.config} write /sys/class/android_usb/android0/enable 1 setprop sys.usb.state ${sys.usb.config}满怀期待地编译、烧录、测试。执行setprop sys.usb.config acm后电脑果然正确识别出了COM口我兴奋地打开串口调试助手准备测试通信。然而就在我尝试把模式切换回adb或者mtp时设备突然卡住紧接着串口控制台开始疯狂打印内核崩溃日志Kernel Panic Oops。第一次修复成功地把一个“功能失效”的问题升级成了一个“系统崩溃”的问题。这感觉就像修水管结果把承重墙给敲了。4. 崩溃分析与根源定位面对红彤彤的内核崩溃日志千万别慌。这种Oops日志是内核给我们的“死亡现场报告”里面包含了破案的关键线索。我们把关键信息摘出来看[ 70.552704] Unable to handle kernel NULL pointer dereference at virtual address 00000104 [ 70.578967] PC is at usb_remove_function0x30/0x64 ... [ 71.451882] [c04a3d04] (usb_remove_function0x30/0x64) from [c04b0ef0] (acm_function_unbind_config0x30/0x50)第一行是最重要的内核空指针解引用。地址00000104非常小这通常意味着程序试图访问一个结构体指针的成员但这个指针本身是NULL。第二行告诉我们错误发生在usb_remove_function函数内部。再看下面的调用栈回溯backtrace它清晰地展示了函数调用链enable_store-unbind_config-android_unbind_config-acm_function_unbind_config-usb_remove_function(在这里崩溃)。这说明崩溃发生在解除ACM功能绑定的过程中。我们回头看看acm_function_unbind_config的原始代码static void acm_function_unbind_config(struct android_usb_function *f, struct usb_configuration *c) { int i; struct acm_function_config *config f-config; for (i 0; i config-instances_on; i) // 注意这里 usb_remove_function(c, config-f_acm[i]); }问题变得清晰了。在bind函数里我们通过写sysfs节点把config-instances设为了1。然后bind函数执行config-instances_on config-instances;所以instances_on也等于1。这没问题循环执行一次成功添加了一个function。但是当我们切换模式触发unbind时unbind函数里的for循环条件i config-instances_on这个instances_on的值是多少它仍然是1因为没有任何代码在解绑后去减少它。于是unbind函数试图去移除一个function。然而这里有一个致命的逻辑漏洞config-f_acm这个指针数组可能并没有被正确初始化到拥有一个有效元素的状态。更可能的情况是驱动内部的状态机在bind和unbind过程中config-f_acm[0]这个指针在unbind时已经变成了NULL或者它指向的内存已经被释放。而usb_remove_function函数没有对传入的指针做严格的NULL检查直接对其进行访问操作比如访问偏移0x104处的成员导致了空指针解引用内核就此崩溃。所以根源在于instances_on这个状态变量没有被当作一个真正的“状态”来管理。它在bind时被一次性赋值之后就不再变化无法正确反映ACM功能当前的活跃实例数。这属于驱动代码的一个设计缺陷。5. 终极解决方案内核驱动层修复在Android层写instances节点这条路因为会触发内核崩溃被证明是行不通的。那我们能不能从内核驱动层面修复这个状态管理的问题呢当然可以而且这才是根本解决之道。我们的目标是让instances_on真实地反映当前“已启用”的ACM实例数量。思路很简单在bind时增加计数在unbind时减少计数。这样instances_on就变成了一个动态的“引用计数”。我们需要修改drivers/usb/gadget/android.c中的两个函数。修改后的acm_function_bind_config函数static int acm_function_bind_config(struct android_usb_function *f, struct usb_configuration *c) { int i; int ret 0; struct acm_function_config *config f-config; // 原代码config-instances_on config-instances; // 修改为增加一个活跃实例 config-instances_on; // 关键修改处 for (i 0; i config-instances_on; i) { ret usb_add_function(c, config-f_acm[i]); if (ret) { pr_err(Could not bind acm%u config\n, i); goto err_usb_add_function; } } return 0; err_usb_add_function: while (i-- 0) usb_remove_function(c, config-f_acm[i]); // 如果添加失败应该回滚增加的计数实际项目需考虑此处简化 // config-instances_on--; return ret; }修改后的acm_function_unbind_config函数static void acm_function_unbind_config(struct android_usb_function *f, struct usb_configuration *c) { int i; struct acm_function_config *config f-config; // 先减少实例计数 config-instances_on--; // 关键修改处 // 然后移除对应数量的function for (i 0; i config-instances_on; i) usb_remove_function(c, config-f_acm[i]); }这里有一个非常重要的细节注意看unbind函数修改后的循环for (i 0; i config-instances_on; i)。我们在循环开始前已经执行了config-instances_on--。假设bind之后instances_on是1那么--之后它就变成了0。循环条件i 0根本不成立所以循环体usb_remove_function一次都不会执行这看起来有点反直觉但其实是正确的。因为在我们修改后的逻辑里instances_on表示的是“当前活跃的、需要被管理的实例数”。在bind函数中我们先instances_on从0变成1然后为这一个活跃实例调用usb_add_function。在unbind时我们应该做相反的操作先instances_on--从1变回0这意味着已经没有活跃实例需要处理了所以不需要调用usb_remove_function。原来内核崩溃正是因为unbind试图去移除一个已经不存在的实例。当然这个修改方案是经过简化的核心逻辑。在实际的工程代码中你需要考虑更多边界情况比如初始状态instances_on应该为0。可能存在多个ACM实例config-instances 1的情况我们的修改逻辑是否依然成立bind失败时的回滚逻辑需要更完善比如注释掉的那行。并发操作下的保护可能需要加锁。不过对于最常见的单实例ACM需求上面的修改已经足够。我按照这个思路修改了内核代码重新编译内核并烧录。测试流程如下设备启动默认模式如adb。执行setprop sys.usb.config acm。设备重启USB电脑成功识别COM口。使用串口工具通信一切正常。执行setprop sys.usb.config adb。设备再次重启USB成功切换回ADB模式系统稳定没有任何崩溃。多次在acm、acm,adb、adb、mtp等模式间反复切换系统均表现正常。至此这个由instances节点引发的内核空指针崩溃问题算是被彻底解决了。这个坑踩得有点深但回过头看其实就是对驱动框架状态机理解不够透彻。希望我的这次踩坑经历和解决方案能帮你节省大量调试时间。嵌入式开发就是这样有时候一个不起眼的变量背后牵连着整个系统的稳定。