简介面向嵌入式Linux与Android底层驱动开发者的Quectel EC20模块CMUX驱动资源包版本为V2.0.1对应ec20cmux与gsm0701标准。该驱动采用通道复用技术将单个UART物理通道按时分复用拆分为多个逻辑子通道使数据、语音、短信等业务可在同一链路上并发传输既提升接口利用率又降低外围硬件成本是车载信息娱乐、工业路由器和物联网网关等多业务场景的关键支撑。压缩包共3个文件包括驱动核心源码gsm0710muxd_bp.c、用于构建的Makefile编译脚本以及PDF版用户指南整体大小354KB结构紧凑便于快速定位和交叉编译。目前已有349人学习下载适合具备Linux内核或Android HAL开发基础的驱动工程师。通过该资源可系统掌握EC20在Linux与Android双平台下的驱动框架、CMUX通道初始化与数据收发细节了解内核态与硬件抽象层的适配差异并基于自带脚本直接完成移植与验证省去从零梳理协议栈的时间成本显著提升项目落地效率。1. 当串口不够用Quectel CMUX 驱动到底在解决什么问题做车载网关或者工业 LTE 路由器的人大概率都被同一个问题卡住过模组的物理串口只有一个可应用层要同时跑 PPP 拨号、AT 指令、GPS 上报和日志通道四个业务抢一个 /dev/ttyUSB0谁也说不清哪条 AT 指令是被谁吃掉的。Quectel 这套 LinuxAndroid 的 CMUX 驱动本质就是用 GSM 07.10 标准把一路物理串口拆成多路虚拟串口让每个业务独占一条通道。V2.0.1 这个版本在移远官方维护序列里属于较新的补丁级发布主要面向 EC20、EC200、EG25 等移远模组在 Linux 内核态做完端口拆分Android 侧则通过 HAL 层透传给 RIL。这套方案最直接的价值倒不是“多路并发”这个听起来很玄乎的能力而是它能让模组厂商驱动的行为保持一致不管底层是 USB 还是 UART用户态看到的都是 /dev/ttyGSM0、/dev/ttyGSM1 这类稳定节点业务代码不用跟着模组换而改串口路径。想用 CMUX 方案的通常是三类人做车机 T-Box 需要同时保持网络和通话通道的做 DTU 要用一个串口跑多路 TCP 链路的还有做 RTK 基准站要把 NMEA 和配置指令分开的。看完这篇你能知道这个驱动怎么编译进内核、modem 侧怎么开 CMUX、以及最坑的 RTS/CTS 流控问题。2. 协议与代码结构在 Linux 和 Android 里拆串口的两种姿势2.1 GSM 07.10 的“多路复用”语义以及为什么移远要自己写驱动GSM 07.10 是欧洲电信标准协会制定的串口多路复用协议它做的事情概括成一句话就是在一条物理链路上通过类似 TDM 的帧划分方式建立最多几十条逻辑通道。每一条逻辑通道都有自己的流控状态、参数协商和数据类型标记看起来就像独立的串口。但标准只是规定了帧格式和状态机具体怎么做驱动各家模组厂的实现差异很大。移远的这套 CMUX 驱动并不是简单的内核 n_gsm 模块换皮。n_gsm 是 Linux 内核自带的 GSM 0710 实现但它在处理某些移远模组特有的 AT 命令序列和电源管理唤醒时会出现通道挂死。移远的驱动在源码里把gsm0710的 ldisc 层重新实现并且增加了ec20cmux这个针对 EC20 模组时序的适配层主要修正了 DLC数据链路连接标识符建立时的协商顺序以及休眠时对 RTS 信号的处理。V2.0.1 这个版本的变更记录里虽然是“Follow_ec20cmux_gsm0701”这种描述实质是指它的配置流程必须配合 EC20 的固件版本和 AT 命令集合来用。内核对 CMUX 的支持有两种一种是把 n_gsm 编进去用户态用gsmld工具去做链路初始化和 DLC 建立另一种就是移远这种直接改动线路规程line discipline的方式。这两种方式在概念上不冲突但实现上有本质区别。n_gsm 是纯内核态modem 的 AT 命令需要你手动通过TIOCSETD去设置移远的驱动则把初始化逻辑封装在了内核模块里用户在 modprobe 之后只需要一个echo命令写节点就能触发拨号流程。对做产品的团队来说后者接入成本低很多。2.2 源码目录里那几个关键目录分别是什么角色一套来自模组厂家的驱动源码包拿到手第一件事别急着编译先把目录结构读明白。通常 CMUX 驱动会按平台分目录kernel目录放内核补丁或者独立模块源码Android目录放 RIL 和 HAL 的适配层tools目录放测试程序和脚本。V2.0.1 这个版本在kernel目录下能看到quectel_cmux.c这是核心模块文件大约 3000 行左右实现了ldisc操作函数集和 TTY 设备注册逻辑。Linux 侧比较重要的是cmux_util这个用户态工具因为光加载内核驱动只是准备了一个“容器”真正让模组进入 CMUX 模式还需要通过 AT 指令下发ATCMUX命令然后切换 ldisc。驱动源码里的quectel_cmux.h头文件会定义默认的通道数量和工作模式比如CONFIG_QUECTEL_CMUX_USE_ASYNC这种宏控制是不是采用异步通知机制这直接决定了上层应用能不能用poll()来监听串口事件。Android 侧则是另一套逻辑驱动源码里一般会附带一份libqcmux的动态库源码它运行在 user space通过open(/dev/quectel_cmux)去和内核模块通信。注意这个设备节点不是标准 TTY而是一个 misc 设备这是移远为了屏蔽内核版本差异在驱动里做了个中转层。所以在 Android 项目里集成时要特别小心别把它当成普通串口去用经典 termios 接口否则默认波特率协商那步会失败表现为打开设备成功但读不到任何数据。2.3 驱动和内核版本之间那些说不清的兼容边界内核版本对 CMUX 驱动的影响比大多数人想象的都大。移远官方的发布说明里会写上测试过的内核版本比如 3.18、4.4 和 4.19但很多项目实际用的是 BSP 里改过的内核未必正好落在官方验证序列里。这里最容易翻车的是tty_ldisc相关 API 的变化内核 4.10 里把n_tty的receive_buf函数签名加了一个参数老的驱动源代码在 4.14 上编译会报错。你说驱动源码不是带了适配宏吗确实带了比如在quectel_cmux.c里会有#if LINUX_VERSION_CODE KERNEL_VERSION(4, 11, 0)这样的条件编译但实际测试中发现 5.4 以上的内核里tty_port结构体的字段又变了这层适配就不够用了。所以遇到编译报错不用慌先看是不是struct tty_port的client字段访问不到这是 5.x 内核的常见坑。解决方案通常是把源码里的tty_port-client改成tty_port-client NULL之前先判断port-ops是否存在或者干脆用官方补丁去升级 ldisc 注册方式。如果你的项目平台比较新比如用高通 SM8250 或者瑞芯微 RK3588 这一代跑的是 Android 13 配 kernel 5.10那就不要直接拿 V2.0.1 的内核模块去硬编建议优先做“用户态 CMUX 协议栈”把 GSM 07.10 的帧解析放在应用层。原因是你内核里其他驱动可能已经用了n_gsm再加载移远驱动会导致 ldisc 编号冲突两个驱动同时监听同一个串口数据会被随机吃掉。3. 在 Linux 上把 EC20 的 CMUX 通道跑起来的完整流程3.1 准备内核配置选项与编译驱动的三个前置条件在开始编译之前先检查内核源码里有没有打开必要的选项。CMUX 驱动本身不是从标准内核代码树拉下来的它是以外部模块形式提供的所以它依赖的符号必须在内核里存在。三个必须检查的配置项是CONFIG_TTY、CONFIG_LDISC_AUTOLOAD和CONFIG_PROC_FS。其中CONFIG_LDISC_AUTOLOAD特别关键如果这个没开驱动加载时注册的线路规程编号不会自动关联到/proc/tty/ldiscs文件里你后续用ldattach命令会报无法加载模块的错误。确认完之后可以按照下面的步骤来编译。# 假设源码已经放到 kernel/drivers/quectel_cmux/ cd kernel/drivers/quectel_cmux make -C /lib/modules/$(uname -r)/build M$(pwd) modules执行完这条命令之后在目录下会生成quectel_cmux.ko。然后需要手动把模块复制到系统模块目录并加载cp quectel_cmux.ko /lib/modules/$(uname -r)/extra/ depmod -a modprobe quectel_cmuxdepmod -a是为了刷新模块依赖关系否则 modprobe 可能提示找不到模块。加载成功以后检查一下dmesg | grep quectel正常情况下能看到一行注册了 ldisc 编号的日志比如quectel_cmux: registered line discipline 16。如果没看到大概率是内核配置里CONFIG_LDISC_AUTOLOAD没开回到内核 config 重新配置后重编。加载完模块只是让系统具备了这个能力此时你还没和模组建立任何关系。下一步要解锁物理串口把它从默认的 termios 状态切换到 CMUX 模式这里有一个常见误区很多人误以为直接打开设备写 ATCMUX 就够了其实还需要先装上一个“中间层”线路规程。移远驱动的设计是驱动加载后自动把协议处理逻辑挂到某个 ldisc 上应用层只需要把串口的 ldisc 切换过去。3.2 进入 CMUX 模式的完整命令序列和参数含义先说结论整个序列分为四步缺一不可。第一步配置串口第二步切 ldisc第三步发 CMUX 命令第四步验证 DLC 是否建立。下面是一段实测可用的完整脚本注意其中的参数不是随便填的# 1. 配置物理串口以 /dev/ttyUSB2 为 EC20 的 AT 口为例波特率 115200 stty -F /dev/ttyUSB2 115200 raw -echo # 2. 把该串口的线路规程切换到 quectel_cmux 注册的 ldisc这里是 16 ldattach 16 /dev/ttyUSB2 # 3. AT 命令让模组进入 CMUX 模式注意一定要有 IFS 和 \\r echo -e ATCMUX0,0,5,115200,23,0,0,0\\r /dev/ttyUSB2 # 4. 等待模组回 OK然后查看新生成的虚拟串口 sleep 2 ls /dev/ttyGSM*这里解释一下参数ATCMUX后面的第一个0表示基本模式第二个0表示不启用错误恢复5是每帧的最大消息长度115200表示物理链路上的线速中间的23是复用模式编号对应 GSM 07.10 的“帧类型 2”协议栈最后三个0是窗口大小、DLC 最大数量和起始 DLCI。这套参数是移远模组默认支持的组合如果你自己乱填比如把第三个参数改为 31模组虽然会回 OK但后续建立通道时会出现丢帧。脚本执行后ls /dev/ttyGSM*正常会看到ttyGSM0到ttyGSM3这四个节点对应 DLCI 从 2 到 8 的偶数编号通道。如果只看到ttyGSM0而其他节点没出现别急着重建先用 cat 命令读一下/dev/ttyGSM1看看会不会自动触发通道建立因为移远的驱动是“按需拨号”的某些 DLC 要等到用户态 open 才会去发 SABM 帧。3.3 让多路通道同时跑数据PPP 拨号和 AT 通道隔离的组合CMUX 驱动最核心的应用场景就是一路 PPP一路 AT有时候再加一路 GPS。在已经建立四个 DLC 的基础上要给不同业务分配不同通道原则是 DLCI 越小优先级越高。一般情况下DLCI 2 对应的 ttyGSM0 给 AT 指令用DLCI 3 对应的 ttyGSM1 给 PPP 拨号因为拨号数据量大会占带宽放后面一点的位置比较合理。配置流程用一段脚本来说明# 在 ttyGSM1 上拨号先用 AT 命令把模组切到数据模式 echo -e ATCGDCONT1,\IP\,\cmnet\\\r /dev/ttyGSM0 sleep 1 # 然后选定拨号串口执行 pppd注意调制解调器参数用 locked 模式 pppd call quectel-ppp quectel-ppp这个拨号脚本放在/etc/ppp/peers/目录下文件内容重点是这几行/dev/ttyGSM1作为设备名115200作为波特率crtscts打开硬件流控noauth不校验对端认证debug打开日志方便排查。这里crtscts必须加上因为 CMUX 的复用帧本身需要 RTS/CTS 来做链路级别的停止和重启如果不开大流量 PPP 传输时虚拟通道之间会互相踩踏。跑起来之后怎么验证是干净的你可以同时在 ttyGSM2 上发一条ATCSQ看 ttyGSM1 的ifconfig ppp0的丢包率是不是还是 0。CMUX 协议有个特性是帧交错传输理论上不会丢但如果驱动实现有问题高负载时会表现为 AT 通道超时。此时用cat /sys/kernel/debug/quectel_cmux/stats能看到每个通道的 rx 和 tx 帧计数重点看有没有full_queue这个计数在增长如果增长就是驱动内部缓冲队列不够需要调CONFIG_QUECTEL_CMUX_TTY_BUFFER_SIZE重新编。4. Android 侧适配从内核模块到 RIL 能认串口的最后一公里4.1 Android 系统里 CMUX 的两种接入路径选哪种由项目阶段决定Android 设备上接入移远 CMUX 驱动和 Linux 有本质区别Android 的init进程负责设备节点的权限和 SELinux 上下文这些不搞定驱动就算创建了 /dev/ttyGSM* 节点RIL 进程也没有权限打开。V2.0.1 驱动在 Android 侧的代码本质上是一个带 JNI 封装的用户态守护进程它把移远的私有协议封装成标准 RIL 接口。这里的抉择点是如果你的模组是直接挂在应用处理器AP的 UART 上那么内核模块方式是唯一选择如果模组是挂在一个独立的通信处理器上那可以考虑纯用户态 CMUX 模拟把主处理器只当作一根管道。常见做法是这么分配的内核侧用移远的quectel_cmux.ko创建虚拟串口Android HAL 层的rild直接打开/dev/ttyGSM0作为主 AT 通道。而ttyGSM1到ttyGSM3这些辅通道则交给 framework 层的QuectelCMUXService去管理它会维护一个 channel 映射表把上层请求映射到对应串口。这个设计的坑在于rild启动时机在zygote之前而 quectel 的 CMUX 服务是一个 Java 服务它依赖system_server。所以你的init.rc里必须设定好先后顺序——先让rild起来它 open 设备的时候会触发驱动去建立 DLCI 2等 system_server 起来后服务再去建立 DLCI 3 到 8。如果你反过来两边同时 open 一个还没建立的 DLC驱动会返回EAGAIN上层看到的是“打开串口超时”。4.2 用 Android 10 以上系统的要求适配 v2.0.1 的 SELinux 与 ueventd这一步可以说是 Android 适配里最难完全照抄的部分因为不同厂家的 SELinux 策略差别很大尤其是v2.0.1引入的misc设备节点路径改变之后原来写在ueventd.rc里的规则可能就失效了。# 在 device/vendor/board/ueventd.rc 中添加 /dev/quectel_cmux 0660 radio radio /dev/ttyGSM* 0660 radio radio这里第二行的ttyGSM*必须用通配符而且注意是设备节点名带星号不能指定单个节点否则后加入的 DLC 通道会变成root:root权限RIL 进程直接 open 失败。但光改 ueventd 还不够SELinux 下得加 file_contexts/dev/quectel_cmux u:object_r:radio_device:s0 /dev/ttyGSM.* u:object_r:radio_device:s0这里有个容易忽略的细节ttyGSM节点在内核里注册的实际名字是ttyGSM0它属于tty类设备但我们在file_contexts里必须把它标注为radio_device不能标成tty_device否则rild进程即使有radio的domain也会因为tty_device的entrypoint权限没给足而被拒绝。报错信息在logcat里通常是avc: denied { open } for pid... commrild namettyGSM0 scontextu:r:radio:s0 tcontextu:object_r:tty_device:s0。看到这个就说明 context 串了。SELinux 的 te 规则还需要单独加一条允许 radio 进程对 radio_device 的 ioctl 权限因为移远的驱动在open之后还会通过 ioctl 做TIOCSETD操作。有些安卓项目的rild跑在untrusted_appdomain 里这种非标准做法会导致更复杂的权限配置我的建议是老老实实把 rild 跑在radiodomain别为了省事用 root 权限运行毕竟这是要过生产环境的东西。4.3 RIL 层如何分配数据通道主动上报和被动轮询模式取舍RIL 拿到多路串口之后数据通道的分发策略决定用户体验。移远驱动在 Android 的适配里提供了两种模式一种是“主动上报”每次 GPS 数据到了就把字符串通过 socket 发给 RILJ另一种是“被动轮询”由上层定时去 read。现实项目的血泪经验是GPS 和电话这类实时性要求高的必须走主动上报否则会有几百毫秒的延迟而文件传输这种不敏感的轮询模式反而更稳因为它不会因为接收缓冲满而丢帧。在 v2.0.1 的驱动实现里主动上报依赖一个内核线程quectel_cmux_rx_thread但问题是这个线程在系统 suspend 时会停掉导致唤醒后第一包 GPS 数据丢失。我们的解决办法是用一个wake_lock在 CMUX 驱动里保护 RX 线程当还有 DLC 处于open状态时不允许 CPU 进入 deep sleep。配好了通道模式之后快速验证一下多通道是否从 RIL 到应用层全链路打通可以这样测用移远官方 AT 工具在 ttyGSM0 上发ATQUIMODE?正常返回QUIMODE: 1表示模组运行在 CMUX 模式下然后在 ttyGSM1 上用过pppd或rild的拨号接口触发网络连接最后看logcat -s RILC确认 log 里出现DLCI 3: opened字样这就说明 RIL 到内核的数据通道已经闭合。5. 避坑排查CMUX 通道挂死、丢帧和不稳定背后的五个真实案例5.1 案例一DLC 建立成功但打开虚拟串口卡死现象是cat /dev/ttyGSM1一直阻塞不出数据这个问题的根子通常不是驱动而是对端 DLC 还没进入MUX_ESTABLISHED状态或者更干脆一点sabm帧根本没发出去。排查方法是先看/proc/quectel_cmux/dlc_table这个文件把每个 DLC 的状态列得很清楚。如果某个 DLC 的状态显示为INACTIVE而你的应用明明 open 过它那多半是物理链路上的流控信号没收好。此时把/dev/ttyUSB2的-crtscts模式和crtscts模式各试一次看哪个能正常建链。注意移远模组的 CMUX 驱动非常依赖 CTS 信号模组在没拨号前CTS 是不拉高的这就会导致驱动认为链路忙不发 SABM。解决办法就是在这个 DLC 上不做 PPP 而先发一个 AT 指令让模组把串口状态切换一下然后再 open 就不会卡了。5.2 案例二跑大流量 PPP 时另外一个 AT 通道出现周期性几十秒的假死这个现象我在两个不同平台的项目里都遇到过。表面看是 ttyGSM2 发ATCSQ不响应但 ppp0 网络还在走。原因基本可以锁定是驱动内部的tx_alloc优先级倒置PPP 通道占满了发送队列AT 通道的帧排在后面出不去。linux 内核的 tty 层对多路复用 ldisc 是没有 QoS 概念的所有虚拟通道在底层共享同一个tty_buffer这就需要一个用户态策略来规避。我们的做法是给 AT 指令通道的病态行为加一个看门狗在应用层起一个 30 秒定时器如果 ttyGSM2 上发出的 AT 指令在 10 秒内没有收到任何字节就对这个 fd 执行一次tcflush并把它的 ldisc 临时切换成 N_TTY 发一个空字节再切回来相当于把它从假死状态踹醒。这个操作在软件上比重新初始化整个 CMUX 轻量太多实测对业务无感。需要注意的是tcflush会把接收缓冲里排队的合法响应也冲掉所以执行后需要重新发一次AT确认链路是否恢复。5.3 案例三系统休眠唤醒后第一包 GPS NMEA 数据长度被截断成几段这个属于 Linux 内核驱动的经典时序问题。调查路径是先在quectel_cmux.c里的gsm0710_receive函数入口加一个printk_ratelimited打印收到的字节长度和 DLCI然后做一次休眠唤醒看 log 里收包情况。你会发现唤醒后的第一个包长度小于正常 NMEA 语句长度因为驱动的 RX 线程唤醒速度跟不上 UART 控制器 FIFO 到达速度数据发生了半包读取。这个问题发生在驱动层修复点也在驱动层。你可以在rx_thread函数里加一个while循环让它在tty_flip_buffer_push之后额外等待 10ms 让数据稳定再查一次端口是否有未读数据。但调参要小心加长了等待会让正常流程下每个包延迟 10ms不能接受。更好的办法是用tty_insert_flip_char和tty_schedule_flip的组合来手动搬运数据而不是依赖tty_ldisc_receive_buf自动转发。这个修改在 v2.0.1 基础上要改动 20 行左右建议只对 GPS 通道对应的 ttyGSM2 使能新路径保留其他通道走原逻辑以降低风险。5.4 案例四Android 上 rild 能起来但无法注册到网络logcat 里反复打印ATCOPS?这种问题往往被误认为模组天线没接好实际上要检查 CMUX 驱动给 RIL 的串口是不是真的ttyGSM0。Android 的 RIL 在初始化时会先发AT命令探测串口如果挂的不是主控制通道或者端口虽然打开了但是是在 CMUX 帧还没建立好时就 open 的那 RIL 发的第一条AT命令就被丢到帧外去了。你可以做一个快速判断用超级终端连到 ttyGSM0 上手动输入AT如果回显AT之后才是OK说明这个端口工作在 echo 模式RIL 是可以识别的如果输入后没有任何命令回显哪怕有 OK说明 LCMUX 帧还没有对齐此时发数据是无效的。解决方法是把 RIL 的启动流程里加一个“预热”步骤在rild启动前用 shell 向/dev/ttyGSM0写一个空字符比如echo -e \\r /dev/ttyGSM0再依次 open。这个动作会触发驱动补发 SABM 帧将 DLC 启起来。对于 Android 10 以上版本还需要判断selinux是否阻止了 shell 对 ttyGSM0 的写入尽管 ueventd 里已经把节点划给 radio但 shell 进程还是没权限所以建议在 init.rc 里加一个exec阶段的操作而不是在 adb 命令行里做验证。这一条要小心是否为了测试方便而破坏了生产权限模型还有个思路是直接用 Java 层的FileOutputStream从system_server进程来写。5.5 案例五同一份驱动在 ARM32 平台编译通过但运行时段错误定位到__get_free_pages失败这是 v2.0.1 相对早期的版本在内存紧张时的问题。quectel_cmux驱动为每一个 DLC 分配一个 4KB 的 DMA buffer采用__get_free_pages(GFP_KERNEL | __GFP_ZERO, 0)。在 512MB 内存的老旧平台长时间 4G 拨号后内存碎片化严重get_free_pages会偶发失败而驱动的代码里没有对返回指针做非空检查于是后续的memset直接踩空地址。虽然 v2.0.1 应该已经打了补丁但如果你是从比较老的 BSP 升级过来的还是要重新确认因为 BSP 源码不一定被完整同步。规避方案是打开内核的CMA配置把驱动所用 DMA buffer 挪到dma_alloc_coherent接口里去分配但这需要改一版驱动源码对于已经过定制维护的内核来说工作量和风险都在可承受范围。另一种做法是直接把驱动卸载重载让所有 DLC 重新建立也就是做一次软复位这在无人值守的工业设备上实现成本低得多比如你的设备有mcu监控进程可以直接触发一次echo 1 /sys/module/quectel_cmux/parameters/reset来重置所有通道实测能恢复但会掉网 3 秒作为兜底方案足够。6. 进阶用法把 CMUX 驱动参数调成适合你产品形态的样子6.1 调整最大 DLC 数与内存占用让它适配你的业务通道数量移远 CMUX 驱动默认创建的 DLC 数量是 4 个分别对应 ttyGSM0 到 ttyGSM3。如果你有 6 路业务要跑比如同时挂 4 路 Socket 透传、1 路 NMEA 输出、1 路 FOTA 升级指令就得上调 DLC 数量上限。这个参数在quectel_cmux.h里定义具体是#define CMUX_MAX_DLCI 4改成 8 再重新编内存占用会线性上涨因为每个 DLC 有独立的收发包队列和 4KB 缓冲区。所以不建议盲目调到 324 个通道应对 90% 的场景都够了。调大后 AT 命令也要配合改ATCMUX里的第七个参数最大 DLC 数要跟着调整比如你期望 DLCI 到 12就把这个参数改成 6代表 DLCI 数除以 2。6.2 通过 sysfs 节点实时查看每个通道的收发帧计数驱动除了生成串口节点还在 sysfs 里暴露了统计信息。/sys/class/quectel_cmux/下面每个 DLC 都有一个目录里面两个文件比较关键rx_frames和tx_frames。调试大流量丢包时观察方法很有讲究应该在一个固定时间窗口内连续读两次用差值去对应业务层收到的数据包数。如果rx_frames的增量远大于应用层收到的read()次数说明驱动内部发生了帧重传这通常是因为底层串口的硬件流控没开或者后端某个通道的数据处理不过来导致丢帧后触发 GSM 07.10 的层二重传机制。还有sysfs里那个mtu文件可以改默认是 127 字节。如果上层业务一个 AT 命令特别长比如超过 127 字节的短信 PDU会被驱动强制按 127 字节分帧这对接收方来说是透明的但如果对端是个简单的parse脚本很容易因为没有做粘包处理而误判。所以建议把mtu调大到 255不仅减少分帧次数还能直观降低 CPU 占用率因为每帧都有 2 字节的地址和控制字段开销大帧摊薄了这些开销。6.3 模拟异常断电场景来验证驱动稳定性这才是量产前的最后一道关落地到具体产品最后一步往往是做异常断电测试。这里有一个很容易被忽略的细节CMUX 驱动在链路建立后如果突然断电模组侧还在维持 DLC 状态但 AP 侧已经重启了。这时候 AP 重新初始化驱动再去发ATCMUX模组可能不回复因为它在等待上一轮链路的断开确认帧。为避免这个问题主控侧需要先发ATCFUN0让模组射频关闭但串口保持等OK返回后再切换到 CMUX 模式这样模组会清除所有 DLC 状态。另一个验证技巧是修改驱动参数里的hard_flow_control为 0强制关闭硬件流控然后连续跑 72 小时 ping 业务看 PPP 是否断。如果不关流控时反而会断说明链路时序在这个平台和 Uboot 之间的电平配置有冲突大概率是 RTS 线被其他外设占用了。这块我踩过的坑是平台自带的蓝牙芯片和 LTE 模组共享了同一路 RTS导致模组的 CTS 永远拉不高CMUX 驱动自认为链路忙所有 DLC 的建立请求都被无限期挂起。最后无论怎么调别迷信厂家默认参数。我自己的习惯是每次拿到新版驱动在开发板上做一轮ATCMUX参数扫描把115200换成460800看 DLC 建立时间是不是从 500ms 缩短到 120ms如果以太高的线频率导致误码率上升建链时间反而变长就果断用 230400这档线速对大多数移远模组是最平衡的。希望这套排查和调整思路能帮你在新项目上少熬夜。本文还有配套的精品资源点击获取