LubanCat 5软实时化实战：PREEMPT_RT内核编译与RKDevTool烧录全流程

最近把一块 LubanCat 5 从送来的默认状态折腾成了能稳定跑实时任务的软实时平台中间还绕不开 RKDevTool 这个烧录工具。这篇文章不是官方教程是我从编译 RT 内核、改启动参数、写应用实时线程到最后用 RKDevTool 把内核烧进板子的完整实操记录。适合在瑞芯微开发板上做运动控制、数据采集、机器人控制这类工作的同学直接参考。软实时化的核心目标不是让 Linux 变成 RTOS而是把任务延迟从不可控的毫秒级抖动压缩到可预测、可测量的微秒级波动。整个链路可以拆成三块内核具备实时抢占能力、系统把 CPU 资源隔离出来、应用线程按实时调度规则运行最后再用 RKDevTool 把成品内核刷进去。1. 先搞清楚你想要的软实时到底长什么样1.1 软实时不是玄学三个可以量化的指标很多人一说实时性就想到 FreeRTOS、想到硬实时但 Linux 上做的软实时通常指的是另一种承诺绝大多数情况下延迟有界极端情况可以被测量和解释而不是像普通桌面系统那样完全随机。做控制类项目的同学往往更关心三个数字最小延迟、平均延迟、最大延迟。这三个数字不是独立存在的它们共同刻画一个任务从某事件发生到你的业务代码开始执行之间到底有多少不可控时间。拿常见的运动控制来说如果控制周期是 1kHz那任务必须每毫秒醒来一次理想的调度误差要远小于一个毫秒周期漂移和抖动越小越好。数据采集场景更夸张有些传感器要求 10kHz 采样那任务周期只有 100 微秒留给调度系统和业务代码的时间窗口非常窄。软实时化就是把最大延迟尽量压下去同时让抖动范围变小。我在 LubanCat 5 上做测试时会用 cyclictest 这类工具输出 min/avg/max 延迟而不是只看任务能不能跑起来。判断标准很简单如果 max 延迟一直飘在几百微秒甚至毫秒级那你的控制周期再短也没用。1.2 延迟都是从哪来的一次普通中断唤醒任务的全过程纸上谈兵没用得知道延迟从哪来。假设一个外设引脚电平变化需要触发一次采集任务完整链路大致是外设先产生硬件中断CPU 在中断上下文执行一段驱动代码这部分无法被普通任务抢占中断里可能触发 softirq 或者唤醒一个内核线程内核线程被调度器加入就绪队列然后调度器才决定把你的用户态任务切换进来。这中间每一步都有隐藏成本。普通内核默认情况下调度器是 CFS你的任务即使设置很高的 nice 值也没有严格的延迟保证。更麻烦的是中断处理、内核临界区、关闭本地中断等操作随时可能打断调度导致任务迟迟得不到执行。在非实时内核上一个设备驱动如果写得不讲究在 spinlock 里死等一片大内存所有核都可能被拖住。了解这个过程你才能明白软实时化不是在用户态调高优先级这么简单真正的瓶颈大部分在内核响应路径上。1.3 路线对比为什么我选了 PREEMPT_RT 而不是 Xenomai常见方案有三条普通内核加 CPU 隔离、Xenomai 这类双内核方案、PREEMPT_RT 实时内核。我直接选了 PREEMPT_RT原因很现实。Xenomai 能提供更强的实时性但需要独立的实时内核与 Linux 内核共存驱动和应用要用它的接口重写维护成本高得多。如果你只是跑一个控制回路其他大部分业务仍然依赖 Linux 生态用 Xenomai 会非常割裂。普通内核加 isolcpus 隔离的方案倒是改动小但中断线程化和内核抢占能力不足延迟还是会时不时飘起来。PREEMPT_RT 基于主线 Linux 内核把自旋锁替换成可睡眠的 rt_mutex、把中断线程化应用层基本还是标准 POSIX 接口移植成本低很多。软实时场景下它的性能也足够配合隔离核几十微秒级别的延迟是可以预期的。2. 内核级软实时把 PREEMPT_RT 真正用起来2.1 RT 内核从哪来先翻官方内核配置再考虑自己编先别急着编译先确认手上板子用的内核到底是不是实时内核。在 LubanCat 5 上最简单的方法是用uname -a看内核版本再检查配置文件。如果内核开启了/proc/config.gz可以直接解压查看没有的话就翻/boot目录下的 config 文件。zcat /proc/config.gz | grep -E CONFIG_PREEMPT|CONFIG_HZ|CONFIG_RCU_NOCB 2/dev/null # 如果 /proc/config.gz 不存在 cat /boot/config-$(uname -r) | grep -E CONFIG_PREEMPT|CONFIG_HZ|CONFIG_RCU_NOCB如果输出里看到CONFIG_PREEMPT_RTy恭喜你官方镜像已经带了实时内核。如果只有CONFIG_PREEMPT_FULLy那还只是普通可抢占内核离 RT 还有距离。LubanCat 5 这类瑞芯微开发板的官方系统不一定默认包含 RT 内核所以很多情况下要自己编。自己编译内核并没有想象中难关键是不要乱用网上老旧的补丁。现代内核版本可以先去 rt.wiki.kernel.org 找对应版本的 PREEMPT_RT patch或者直接从厂商开源仓库的 RT 分支拉代码。我个人的习惯是先用厂商内核源码编译一版干净的普通内核确认可以正常启动再去叠加实时配置这样排查问题时能明确知道是哪个改动导致的。编译步骤大致如下先准备好 aarch64 交叉编译工具链进入厂商内核源码目录查看 configs 目录下有没有对应板卡的 defconfig然后执行编译。export ARCHarm64 export CROSS_COMPILEaarch64-linux-gnu- make 厂商提供的板卡defconfig make -j$(nproc) Image dtbs编译完成后生成的Image和 dtb 文件就是后续要烧录的内容。如果你不清楚厂商 defconfig 的具体名字直接看 README 或者arch/arm64/configs下带板卡型号的配置文件即可。这一步一定要仔细搞错文件后面的启动必然会黑屏。2.2 与实时性直接相关的内核开关有哪些拿内核源码配置界面举例make menuconfig里能看到几个关键选项。CONFIG_PREEMPT_RT完全抢占模式是软实时化的核心。它让内核几乎所有临界区都可被更高优先级任务抢占中断也会被线程化。CONFIG_HZ_1000把系统时钟频率从默认的 100Hz 或 250Hz 提到 1000Hz。简单理解调度器每个 tick 是 1mstick 越密集调度决定越快周期性任务的时间粒度越细。代价是开销略微增加但在实时场景值得。CONFIG_RCU_NOCB_CPU这个选项允许把 RCU 回调强制迁移到指定的 CPU避免 RCU 处理频繁打断实时核。搭配启动参数rcu_nocbs使用。CONFIG_NO_HZ_FULL启用 adaptive tick在 nohz_full 指定的 CPU 上空闲时彻底停掉周期 tick减少无谓的中断。CONFIG_IRQ_FORCED_THREADING在 RT 内核里基本是默认开启的所有中断都会变成一个可调度的内核线程这样实时任务才能打断中断处理流程。很多人只开 PREEMPT_RT 就以为完事了实际上 HZ、RCU、NO_HZ_FULL 这几个选项对最终延迟的影响同样明显。我实测过一个没有开 RCU_NOCB 的配置实时核上会周期性地被 RCU 唤醒打断最大延迟直接多了几十微秒。这种细节不跑测试很难发现。2.3 为什么不能只靠普通内核调优先级的骚操作有人会问我在普通内核上用chrt -f 90把任务设为实时调度策略再把 nice 调到很低是不是就够了答案是不够。调度策略只能影响任务在就绪队列上的排序但无法解决两个问题一是内核自身的临界区可能长时间关闭抢占任务根本没机会被调度二是中断处理会直接抢占一切实时任务只能干等。普通内核上中断没有任何线程化可言网卡或存储设备一忙延迟必然飙升。PREEMPT_RT 的关键改动在于把内核态的大量自旋锁替换成可睡眠的 rt_mutex当实时任务想进入某个临界区时如果持有锁的低优先级线程在运行高优先级任务可以促使其尽快释放甚至可以发生优先级继承。这就把不可控的内核抢占延迟变成了可调度、可抢占的用户态行为。软实时项目里这种内核层面的确定性比任何应用层奇技淫巧都重要。3. 系统引导与运行参数把实时核圈出来并打扫干净3.1 改启动参数LubanCat 5 上最容易踩的 extlinux.conf 坑内核编译好只是第一步要让软实时真正落地还得让系统在启动阶段就把 CPU 资源隔离出来。ARM 平台不像 x86 那样普遍用 GRUBLubanCat 5 这类板子通常使用extlinux.conf或 u-boot 环境来设置内核命令行。先找到启动配置文件常见路径是/boot/extlinux/extlinux.conf内容里有一行append开头或包含root的字符串在这一行后面追加实时参数# /boot/extlinux/extlinux.conf 的 append 行 append root... rw consolettyS0,1500000 isolcpus4-7 nohz_full4-7 rcu_nocbs4-7这几个参数的含义要记清楚isolcpus4-7把 CPU4 到 CPU7 从默认调度器的负载均衡中剔除。普通用户进程不会自动跑上去只有显式绑定到这些核的任务才会被分配过去。这是圈地最关键的一步。nohz_full4-7在列出的核上关闭周期性 tick减少时钟中断对实时任务的打扰。前提是内核开了 CONFIG_NO_HZ_FULL。rcu_nocbs4-7把 RCU 回调从这些核上移走避免 RCU 相关任务周期性出现。前提是内核开了 CONFIG_RCU_NOCB_CPU。我当时在这里卡了整整一个晚上改完 extlinux.conf 重启后用cat /proc/cmdline查看发现我加的参数根本没生效。后来排查才发现板子的 u-boot 环境变量里存着另一份 bootargs启动时 u-boot 会重新组装内核参数把 extlinux.conf 里的内容覆盖掉了。解决方法是进入 u-boot 命令行修改bootargs环境变量或者找到厂商提供的脚本里负责拼接参数的逻辑。修改完一定要用cat /proc/cmdline验证不要想当然。3.2 中断亲和性别让网卡和磁盘打断实时核圈出实时核之后接下来要把设备中断从这些核上请走。中断处理器会抢占实时任务哪怕只是微秒级别的处理时间如果频率很高也会让控制任务的延迟抖动明显变大。具体做法是先看现在中断都落在哪些 CPU 上cat /proc/interrupts这个文件会显示每个中断号的名称以及各 CPU 上的触发次数。找到网卡、USB、存储相关的中断号然后通过 smp_affinity 把它们固定到非实时核上。我用的是smp_affinity_list写起来更直观# 假设实时核是 4-7非实时核是 0-3 echo 0-3 /proc/irq/31/smp_affinity_list如果没有权限需要先确认你是否以 root 运行。持久化可以写一个 systemd service 或 udev 规则在启动时自动设置。注意网卡的 RSS 队列如果有多个中断号要全部处理否则看起来中断转移了实际上还有部分队列留在实时核上。这块很容易忽略我一开始只处理了 eth0 的 Rx 中断结果另一组 irq 还在实时核上跳延迟一直下不去。3.3 允许实时任务占用全部 CPU 时间sched_rt_runtime_usLinux 默认有一个保护机制实时调度策略任务SCHED_FIFO/SCHED_RR最多只能占用 CPU 带宽的 95%剩下 5% 强制留给普通任务。这个机制的实现就是kernel.sched_rt_period_us和kernel.sched_rt_runtime_us默认周期是 1 秒实时任务最多跑 0.95 秒然后会被 throttle 一小段时间。如果实时任务总是周期性到来这个 throttle 会直接打断你的控制周期。把限制去掉的方法sysctl -w kernel.sched_rt_runtime_us-1写成永久生效的话在/etc/sysctl.conf或/etc/sysctl.d/下加一行kernel.sched_rt_runtime_us-1。这个参数要慎重因为一旦放开一个写死循环的实时线程可以让整个系统完全失去响应。所以我只在隔离出来的实时核上使用这个配置同时保证实时核上的应用代码经过了足够的压力测试。此外CPU 调频 governor 默认很可能在 ondemand 或 conservative频繁变频也会造成延迟抖动。用 performance governor 锁定最高频率cpupower frequency-set -g performance # 或者手动写 echo performance /sys/devices/system/cpu/cpu4/cpufreq/scaling_governorLubanCat 5 这类处理器有大核小核实时任务最好跑在大核上。先通过lscpu或/sys/devices/system/cpu/下的信息确认大核编号范围再决定 isolcpus 具体写哪几个核。不同板子的大核编号差异挺大千万不要照抄别人的参数。4. 应用层配合让任务真的跑在圈出来的核上4.1 线程绑核与实时调度的最小代码系统层面的隔离完成后应用也要主动配合。最常见的做法是创建实时线程设置 SCHED_FIFO 策略和优先级然后绑定到 isolcpus 指定的核上。以 C 语言为例核心代码是这样的#include pthread.h #include sched.h #include stdio.h #include string.h void *rt_task(void *arg) { while (1) { // 周期任务主体 } } int main(void) { pthread_t th; pthread_attr_t attr; struct sched_param param; cpu_set_t cpuset; pthread_attr_init(attr); // 设置实时调度策略与优先级 memset(param, 0, sizeof(param)); param.sched_priority 80; pthread_attr_setschedpolicy(attr, SCHED_FIFO); pthread_attr_setschedparam(attr, param); pthread_attr_setinheritsched(attr, PTHREAD_EXPLICIT_SCHED); // 绑定到第 4 号 CPU CPU_ZERO(cpuset); CPU_SET(4, cpuset); pthread_attr_setaffinity_np(attr, sizeof(cpu_set_t), cpuset); pthread_create(th, attr, rt_task, NULL); pthread_join(th, NULL); return 0; }这段代码最关键的是PTHREAD_EXPLICIT_SCHED它表示线程自己使用指定的调度策略而不是继承创建者的属性。很多人漏了这一步结果 pthread_create 后线程依然按默认 CFS 调度跑实时性完全没生效。另外sched_priority的取值范围是 1 到 99数值越大优先级越高。在 ARM Linux 下 SCHED_FIFO 的优先级不要乱设到 99除非你真的需要最高优先级否则和内核关键线程抢时间会发生不可预期的问题。还有一个容易被忽略的周期同步问题。如果你在实时线程里用usleep()或nanosleep()做周期控制每次 sleep 的起始点都会漂移因为睡眠是基于当前时间加减时间间隔而不是基于绝对的周期起点。正确做法是用clock_nanosleep()的绝对时间模式以固定周期累加唤醒时间点才能把抖动控制住。struct timespec ts; clock_gettime(CLOCK_MONOTONIC, ts); while (1) { ts.tv_nsec 1000000; // 1ms 周期 if (ts.tv_nsec 1000000000) { ts.tv_nsec - 1000000000; ts.tv_sec; } clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, ts, NULL); // 业务代码 }4.2 在实时线程里千万不要做的事软实时做到最后很多问题不是内核造成的而是应用自己制造了延迟。实时线程里最忌惮的操作依次是调用malloc或free。堆内存分配可能触发内存锁、缺页中断甚至 brk 系统调用延迟完全不可控。要在初始化阶段先分配好所有内存运行期不再动态分配。打印日志。printf、cout这类操作经常涉及锁和系统调用串口或控制台输出在调试时尤其危险。我之前在实时线程里留了一句调试日志结果串口波特率只有 115200日志一多整个控制周期被拉长到好几毫秒。日志应该通过无锁环形缓冲交给一个非实时线程去处理。直接调用未知延迟的阻塞函数比如文件 I/O、网络 read、互斥锁竞争。如果和其他非实时线程共享锁实时线程会被低优先级线程拖住。触发缺页。一个进程刚启动时代码段和数据段并没有全部装载到物理内存第一次访问会产生 page fault这个开销可能达到几十微秒甚至更多。解决方法是初始化阶段用mlockall(MCL_CURRENT | MCL_FUTURE)锁定内存防止发生 swap 和页面换入换出。#include sys/mman.h mlockall(MCL_CURRENT | MCL_FUTURE);这段代码要在创建实时线程之前调用。锁内存的代价是系统中被锁定的内存不能被换出所以不要在一台内存紧张的板子上锁住几个 GB 内存够用就好。4.3 多核实时任务怎么排布大小核、独占核数LubanCat 5 这类处理器通常同时包含高性能核心和低功耗核心。为了最大化实时性实时任务应该绑定到高性能大核上并且锁定主频。同时要空出足够的内存带宽因为多核同时访问内存时会有带宽争抢实时核被饿到的概率不是零。如果你需要多个实时任务并行建议要么全部放在隔离核内但隔离核数量不要超过需求要么严格按照优先级划分让最关键的任务独占一个核次要任务放在另一个隔离核上。最忌讳的是把实时任务和非实时任务混跑在同一个核上哪怕实时任务优先级再高它也得被系统节拍和其他普通线程牵连。非实时业务尽量放到隔离范围之外让它们随便折腾。5. RKDevTool 烧录把 RT 内核送进 LubanCat 5 的最稳妥路径5.1 为什么用 RKDevTool 而不是直接 dd内核和系统配置都准备好之后下一步就是烧录。RKDevTool 是瑞芯微官方的 USB 烧录工具支持分区表管理、镜像烧写、Loader 更新。为什么不直接dd到存储卡因为 LubanCat 5 上的系统是写在 eMMC 或 NVMe 里的直接覆盖分区偏移量的风险很高尤其parameter分区里的地址信息如果和镜像不匹配板子可能直接变砖。RKDevTool 的好处是有完整的烧录协议会按厂商分区表替你处理好地址映射不容易搞坏 Loader。另外用 RKDevTool 单独更新某个分区很方便。软实时化过程中需要反复迭代内核如果每次都刷完整镜像浪费时间而且容易出错。只烧 boot 分区或内核所在分区启动过程可以保留 u-boot 和根文件系统排查问题更高效。5.2 第一次烧录驱动、识别、Loader 模式准备好需要烧录的镜像文件之后按下面步骤走在电脑上安装 Rockchip USB Driver然后再安装 RKDevTool。驱动不装好的话开发板插上去只会显示未知设备。用 USB Type-C 线把开发板和电脑连接。这里要注意一定要连板子上的 OTG 烧录口而不是普通 USB 口两者在物理上很接近但功能完全不同。进入 Loader 模式。比较通用的做法是按住板子上的 Recovery/MaskROM 按键再给板子上电。如果板子已经进入系统也可以在终端执行reboot loader命令很多 RK 平台支持这个命令直接进入烧录模式。打开 RKDevTool正常识别后界面会显示发现一个 Loader 设备并显示 Loader 版本。切到升级固件页签选择完整的update.img烧录整个系统或者切到先进功能/分区烧录页签逐个指定分区镜像。识别不到设备是最常见的开局问题。我遇到的情况有三种USB 线质量差导致协议不稳定插错了 USB 口驱动被旧版本覆盖。优先换一根能传数据的短线再检查设备管理器里有没有 Rockchip 设备最后确认按键是否按得够久。按 Recovery 键上电后保持按住大约 5 秒再松开不要按一下就松手。5.3 只烧 boot 分区快速迭代内核的具体操作如果你只想更新内核用分区烧录模式。RK 平台的内核通常位于 boot 分区有的方案还会把 dtb 单独放在 resource 分区。先确认厂商镜像包里 boot.img 的格式如果官方发布的是独立 boot.img直接在 RKDevTool 里找到 boot 分区那一行路径选成你的 boot.img点击执行。如果是从内核源码编译出来的Image和 dtb你可能需要先按厂商的打包脚本生成 boot.img或者用工具手动把 Image 和 dtb 合成 boot 镜像。执行时 RKDevTool 会提示擦除分区并写入写入完成后板子自动重启。如果你之前已经成功启动过系统只更新 boot 分区不会影响根文件系统里的配置开机速度也很快。要注意的是不要在烧录过程中拔掉 USB 线或断电否则可能留下一个写了一半的内核镜像虽然可以重新烧录修复但没必要折腾自己。完整烧录 update.img 的操作逻辑类似区别在于要保证镜像本身是针对当前板卡型号和存储配置生成的。如果你手上只有官方发布的标准镜像那就直接用升级固件模式等待工具写入完整镜像即可。这个方法最稳妥只是耗时稍长。6. 验证效果与踩坑延迟到底降了多少6.1 cyclictest 的正确跑法系统启动后第一件事是确认实时配置真的生效了。老规矩cat /proc/cmdline看输出里是否包含isolcpus4-7 nohz_full4-7 rcu_nocbs4-7。然后确认内核配置grep -E CONFIG_PREEMPT_RT /boot/config-$(uname -r)一切正常后安装 rt-tests 里的 cyclictest 工具。Debian/Ubuntu 系统可以直接apt install rt-tests然后跑一轮测试。我习惯把测试线程绑定到隔离核并且用实时优先级和绝对时钟模式cyclictest -t 1 -p 95 -i 1000 -l 100000 -m -n -q -a 4解释一下-t 1表示一个测试线程-p 95是 SCHED_FIFO 优先级 95-i 1000是间隔 1000 微秒也就是 1ms-l 100000是循环 100000 次-m锁定内存-n使用 clock_nanosleep-a 4绑定到 CPU4。跑完后会输出 min/avg/max 三个延迟值。在 LubanCat 5 这类平台上如果一个系统完成了 PREEMPT_RT isolcpus performance governor 中断亲和性调整1ms 测试周期下 max 延迟通常能稳定在几十微秒到一百多微秒范围内。如果没有 RT 内核只靠普通内核加隔离max 延迟往往还在几百微秒以上。你可以用同一个命令在不同配置下跑对比数字会非常直观。6.2 不要只看峰值我踩过的三个大坑测试结果不理想的时候先别急着怪内核检查下面这几个坑。第一个坑是 CPU 调频没锁。默认 governor 为了省电会动态调整频率当实时任务突然来临时CPU 可能刚好处于低频率状态唤醒后还要等待频率提升延迟就爆了。解决方法已经说过performance governor 锁频。第二个坑是网卡中断。我测试时一直开着网口想着不过是一点控制流流量影响应该很小。结果 eth0 的收包中断频繁触发每个包都会抢占实时内核线程几百纳秒到几微秒看起来不多但累计的抖动很可观。把网卡中断全部迁移到非实时核后max 延迟立刻降了大概三分之一。第三个坑是内核调试功能没关。如果内核打开了 ftrace、kprobe、debugfs并且系统里还有大量 trace 事件这些机制会在调度、中断路径上增加额外开销。测试软实时性能时要关闭不必要的调试追踪通过echo 0 /sys/kernel/debug/tracing/tracing_on或直接编译时关掉 CONFIG_FTRACE。还有个更隐蔽的问题是printk。内核的 printk 路径在控制台输出时往往很慢普通日志流量大时同样会拖慢整个系统。如果板子上跑着系统服务在疯狂写内核日志你的 cyclictest 结果一定会被污染。6.3 一个务实建议先量化需求再决定要不要上全套路软实时化做完整套之后控制周期的稳定性确实提升明显但它是个系统工程不是一个命令就能解决的。如果你只是想让某个任务别被桌面环境卡得太狠其实先在标准内核上用 isolcpus 隔离一个核再把任务优先级调高就能解决一半问题。测一轮延迟如果 max 值能接受就没必要上 PREEMPT_RT。毕竟 RT 内核也有兼容性成本有些显卡驱动、闭源库在 RT 内核下会工作不正常。我在 LubanCat 5 上最终保留的是 PREEMPT_RT 内核加隔离核的方案因为我的控制回路要求比普通软实时更严。整个配置流程走下来最耗时间的是启动参数的生效确认和中断亲和性的逐个排查而不是内核编译本身。用 RKDevTool 烧录迭代内核则帮我省了大量重复刷系统的时间把开发重心从折腾环境挪到了调业务代码上。如果你现在的板子还没有达到预期的控制稳定性建议按这套链路把内核、系统配置、应用和烧录依次过一遍延迟数据会告诉你每一处改动到底值不值。