做机器人运动控制或者高精度数据采集的朋友应该都遇到过这种情况板子明明跑得挺快但任务总会出现几十毫秒的卡顿。如果你手里拿到的是LubanCat 5也就是基于瑞芯微RK3576平台的这块开发板想让它承担一些对时序敏感的工作默认的内核调度策略大概率会让你抓狂。这篇文章想聊的就是我给LubanCat 5做软实时化改造的全过程顺带把RKDevTool这个官方烧录工具的使用细节一并讲透。文章适合刚接触嵌入式Linux实时性优化、或者正在折腾RK3576平台开发板的开发者读了之后你能少走不少弯路。1. 为什么说软实时化是RK3576开发板的第一站很多人一上来就问软实时是不是就是打上PREEMPT_RT补丁这么说对了一半。真正理解这件事之前得先把实时这个概念放在实际场景里过一遍。1.1 软实时与硬实时的边界在哪儿硬实时的典型代表是飞控、医疗器械、工业PLC这类系统任务响应一旦超过某个时间上限系统直接算失败可能带来物理上的损坏或安全事故。软实时的标准则宽松得多它允许偶发的超时但要求绝大多数情况下延迟保持在一个可接受的范围内比如控制周期2ms那么99.9%以上的调度延迟要低于这个值。开发板上的Linux之所以能做软实时靠的是内核的抢占机制优化而不是换一套RTOS。LubanCat 5这颗RK3576跑Linux做软实时本质上是用它那4个Cortex-A72大核扛住复杂计算再用Cortex-A53小核配合实时调度策略处理周期性任务。相比在STM32这类MCU上做硬实时开发板的优势是算力充足、生态完善你可以在同一个系统里跑视觉算法、神经网络推理和运动控制劣势则是延迟的下限远不如MCU稳定所以如果项目真的到了微秒级必须满足的环节别纠结软实时直接上MCU加实时核的方案更靠谱。1.2 哪些场景配得上软实时别硬上我实际测试下来LubanCat 5做软实时化之后在以下这些场景里有明显的收益机器人关节控制通过CAN或者EtherCAT下发指令周期2ms到10ms需要稳定的调度节拍。高速数据采集ADC采样、传感器数据读取配合时间戳处理延迟抖动直接影响数据对齐。音频处理与软件无线电数据流需要持续以固定周期搬运和计算偶发几十毫秒卡顿会造成明显爆音或丢包。自动化测试设备需要按精确时序触发外部仪器动作。反过来如果只是跑跑Web服务、做做图像分类推理那软实时化带来的收益几乎感知不到反而可能因为内核配置变化引入兼容性问题。还有一类情况别硬上你必须依赖某个闭源内核模块而这个模块没有适配PREEMPT_RT补丁后的内核API这种情况下强行改造会让驱动加载直接失败项目进度被拖死。2. LubanCat 5硬件平台的实时性瓶颈想优化延迟得先知道延迟是从哪里来的。RK3576这颗SoC本身性能不弱但Linux默认把它当普通服务器用自然就会出现各种抖动源。2.1 RK3576芯片底子A72大核与A53小核的调度博弈RK3576采用了4个Cortex-A72加4个Cortex-A53的big.LITTLE架构。这种异构设计在功耗上有优势但调度器如果频繁把任务在大核和小核之间迁移缓存亲和性就被破坏了任务每次跑到新核上都要重新加载指令和数据延迟自然飙升。默认的Linux调度器会基于负载均衡机制时不时把进程搬来搬去。对实时任务来说CPU迁移是最大的敌人。我在配置软实时内核时第一件事就是把实时任务绑死在某个性能核上并且通过内核启动参数把其他核隔离出调度器的负载均衡范围。这个后面会详细说操作。2.2 影响实时性的三座大山调度延迟、中断延迟、频率切换调度延迟一个进程进入就绪状态后要等多久才能被调度器选中运行。普通内核里如果当前CPU上有其他进程持锁或者长时间运行这个等待时间是不可控的。中断延迟硬件中断产生后内核要完成中断响应和处理中断处理过程中如果关闭了本地中断local_irq_disable实时任务只能干等。频率切换与电源管理DVFS导致CPU运行频率动态变化如果任务正跑到一半频率被降下去执行时间立刻拉长更深的问题是频率切换过程本身会暂停CPU几十微秒到上百微秒。这三座大山在默认Linux系统里都存在而PREEMPT_RT补丁主要解决的是前两个问题通过让内核几乎所有路径都可被抢占把调度延迟和中断延迟压缩到几十微秒级别。频率切换的问题则需要靠CPU调频策略和隔离参数来规避我会优先把所有实时核心固定在最高频率运行。3. 动手配置PREEMPT_RT内核从源码到启动一次过现在进入正题。我给LubanCat 5做软实时化的方案核心是重新编译一个带PREEMPT_RT支持的内核再配合启动参数和系统配置把抖动压下去。3.1 准备编译环境和内核源码LubanCat 5的Linux源码可以从野火官方的Gitee仓库下载分支一般对应Linux 6.1或5.10取决于SDK版本。我建议先确认一下你的板子出厂固件内核版本再找对应版本的源码和RT补丁。# 以Ubuntu 22.04主机为例安装交叉编译工具链和依赖 sudo apt update sudo apt install -y gcc-aarch64-linux-gnu make flex bison libssl-dev libncurses-dev然后下载内核源码git clone https://gitee.com/LubanCat/LubanCat5-Kernel.git -b linux-6.1-rt确认分支名的时候留意仓库说明不同批次的板子分支命名可能不同。如果没有现成的rt分支就需要自己下载对应版本的内核源码和RT补丁。3.2 打补丁与内核配置的关键选项内核版本与RT补丁版本是一一对应的比如内核6.1.x有对应的patch-6.1.y-rt{z}.patch.xz。我在编译时踩过一次版本不匹配的坑补丁打上去直接报错所以这一步必须查准。cd LubanCat5-Kernel # 假设内核版本是6.1.75RT补丁是6.1.75-rt18 xzcat patch-6.1.75-rt18.patch.xz | patch -p1 --dry-run # 确认无冲突后去掉--dry-run正式执行打完补丁后生成默认配置。LubanCat的SDK里一般带了一份rockchip_linux_defconfig需要在此基础上做调整make ARCHarm64 rockchip_linux_defconfig make ARCHarm64 menuconfigmenuconfig里必须确认以下选项配置项路径推荐值CONFIG_PREEMPT_RTKernel Features - Preemption ModelFully Preemptible Kernel (Real-Time)CONFIG_HZ_1000Kernel Features - Timer frequency1000 HzCONFIG_RCU_NOCB_CPUGeneral setup - RCU Subsystem建议启用并设置no-callback CPUsCONFIG_NO_HZ_FULLGeneral setup - Timers subsystem建议启用配合isolcpus使用如果menuconfig里看不到Fully Preemptible Kernel选项说明RT补丁没有打进Kernel Features的Kconfig选择项需要退回上一步确认补丁状态。这是我复现过无数次的经验补丁没打进去时一切都白搭。3.3 编译得到boot.img并部署配置好之后开始编译make ARCHarm64 CROSS_COMPILEaarch64-linux-gnu- -j$(nproc)编译完成后重点产物是arch/arm64/boot/Image然后还需要做两件事一是生成设备树文件LubanCat 5的设备树我遇到的是rk3576-lubancat-5.dtb二是用内核打包脚本生成boot.img因为Rockchip平台的引导机制要求内核和dtb打包成Android boot格式的镜像。LubanCat SDK里一般有打包脚本如果找不到可以参考Rockchip官方提供的mkbootimg./mkbootimg --kernel arch/arm64/boot/Image --dtb arch/arm64/boot/dts/rockchip/rk3576-lubancat-5.dtb --ramdisk ramdisk.img -o boot.imgramdisk这边我图省事直接从原厂boot.img里解包提取。生成boot.img后会放在RKDevTool烧录里用跟第四部分正好衔接上。3.4 启动参数与CPU隔离的调优组合编译好内核只是第一步真正让软实时生效的是启动参数。我的建议组合是这样isolcpus4,5,6,7 nohz_full4,5,6,7 rcu_nocbs4,5,6,7含义解释isolcpus把4到7号CPU从调度器的负载均衡范围里剔除普通进程不会跑上去把空间腾给实时任务。nohz_full让这些CPU在只有一个运行队列任务时完全关闭周期时钟节拍减少无谓的定时器中断。rcu_nocbs把这些CPU上的RCU回调处理offload到其他CPU避免RCU机制打断实时任务。实际修改时可以在U-Boot环境变量里追加bootargs也可以在RKDevTool烧录的parameter分区里设置。我建议直接在U-Boot的bootargs变量里改这样不用重新烧录分区调试效率高。启动后把实时任务的CPU亲和性绑定到隔离核上可以用Linux提供的工具taskset -c 6 ./your_realtime_task同时把实时任务的调度策略切换到SCHED_FIFO并设置高优先级chrt -f -p 80 PID最后不要忘了把隔离核的CPU调频策略固定到最高性能档位。这一步很关键否则频率切换带来的延迟抖动会让前面所有努力白费cpufreq-set -c 6 -g performance4. RKDevTool的完整工作流程从驱动安装到分区烧录编译出的boot.img总归要烧进板子。瑞芯微平台的烧录工具RKDevTool是Windows下的标准方案整个流程有几个容易出问题的地方我拆开讲。4.1 驱动安装与设备识别RKDevTool运行依赖Rockchip USB驱动。驱动和工具可以在野火的资料包或者瑞芯微官网下载到下载后先运行DriverInstall.exe选择驱动安装按钮。这一步如果没右键管理员身份运行大概率安装失败。驱动装好后把LubanCat 5断电用Type-C数据线连接电脑和板子上的烧录口。然后按住板子上的BOOT按键不放给板子上电电脑端会听到USB设备插入提示音。打开RKDevTool主界面正常的话会看到一个设备行显示LOADER设备说明驱动识别成功。4.2 Loader模式和MaskROM模式的区别这是新手最容易混淆的两个概念Loader模式板子的BootROM发现eMMC或SD卡里存在可用的U-Boot于是加载U-Boot进入烧录等待状态。这种模式下你只能烧写部分分区不能动Loader相关的引导链。MaskROM模式板子的eMMC/SD里的引导链已经损坏或者完全没有BootROM只能进入内置的MaskROM模式。这个模式是最底层的烧录保险可以把你所有分区重新刷干净。实际操作中正常软硬件下按住BOOT上电进的是Loader模式。如果板子已经被你折腾得无法开机也不要慌按住BOOT键配合上电通常还是会进入Loader模式只有极少数情况才需要短接MaskROM触点强制进入MaskROM。我建议尽量不要轻易触发MaskROM因为MaskROM模式下烧错镜像会直接把引导链覆盖风险更大。4.3 烧录前备份原厂固件我强烈建议拿到新板子、还没折腾之前先用RKDevTool把原厂固件完整读出来。备份方式有两种在RKDevTool选中设备后点击导出镜像把整个Flash内容导出生成一个大文件。进入高级功能页按分区逐个导出比如uboot、resource、boot、rootfs等。单独备份分区的好处是之后每次实验只需要回滚某个分区就行。我习惯备份成镜像文件后立即复制一份到外部存储防止误操作覆盖。4.4 分区镜像烧录的具体操作用RKDevTool烧录分区的操作比想象中简单但注意细节主界面左侧是烧录分区列表格式是分区名镜像路径。默认烧录配置可能带了一个完整固件包如果你只想更新boot.img就把地址列表中boot那行右侧的镜像路径改成自己编译好的boot.img其余分区保持空白。点击执行升级开始烧录。烧录过程中千万不要拔线断电。烧录完成后设备会自动重启进入系统。如果执行烧录时提示设备识别失败或者卡在准备设备大概率是驱动问题。我遇到过一次很诡异的情况换了根Type-C线就好了原因是不合格的数据线只有充电能力没有数据通道。所以如果识别不稳定先换线再说。5. 实测数据说话延迟对比与性能评估配置做完了性能到底怎么样不能靠感觉。我用了rt-tests里的cyclictest做了延迟测试在改造前后分别跑了一组数据来对比。5.1 cyclictest的安装与其参数含义在板子终端上安装rt-testssudo apt install rt-tests然后运行以下测试参数cyclictest -t 1 -p 80 -i 1000 -l 100000 -q -h 1000参数解释-t 1只跑一个测试线程避免线程调度造成的干扰测的是极限调度延迟。-p 80SCHED_FIFO优先级80让测试线程优先于普通进程。-i 1000采样周期1000微秒。-l 100000采样10万个周期大约100秒。-h 1000打印延迟直方图范围到1000微秒。为了更接近真实场景我又跑了一个多线程压力测试版本在后台用stress-ng --cpu 8 --io 4压满其他核再测实时任务受到的干扰。5.2 改造前后的数据对比我整理了改造前后、以及是否附加CPU压力的四组数据列出Max和Avg两个关键指标单位微秒测试场景平均延迟最大延迟超过500us次数默认内核无压力458903默认内核CPU压力120230045RT内核隔离核无压力19880RT内核隔离核CPU压力221700数据说明了两件事第一默认内核在空闲状态下最大延迟已经到了890微秒这对周期2ms的控制任务来说虽然勉强能跑但风险很高第二一旦系统负载上来默认内核的最大延迟飙到2.3毫秒直接任务超时。而软实时化后的系统即便CPU全压满最大延迟也只有170微秒左右这个数据基本可以覆盖10ms以下的周期控制任务。5.3 实际场景里的附加收益除了cyclictest我还跑了一遍LubanCat 5自带的NPU推理测试加了RT内核之后推理耗时反而比默认内核稍慢一点这是因为PREEMPT_RT内核本身会增加一些锁和上下文切换开销。所以如果你只是纯算力场景软实时化反而有点负优化。这也印证了我开头说的软实时化要围绕你需要哪些实时任务来设计而不是无脑全系统开启。6. 实操中绕不开的那些坑与处理方案这部分我按自己踩过的真实顺序列出几个高频坑基本覆盖了从编译到烧录再到运行的完整链路。6.1 编译RT内核时.config残留导致的玄学报错症状在已有内核源码上切到RT分支后直接编译报一堆莫名其妙的undefined reference错误。原因之前的构建产物和.config没有清理干净新旧配置混在一起尤其是CONFIG_SECURITY、CONFIG_DEBUG_INFO这类选项的状态会影响大量模块构建。解决办法不要省时间直接全清make distclean # 重新从defconfig开始配置 make ARCHarm64 rockchip_linux_defconfig # 然后再menconfig修改RT相关选项6.2 RT内核起来之后网卡或WiFi消失症状新内核能进系统终端有输出但网络接口没了。原因内核配置里把Boardcom或者Rockchip网卡对应的驱动模块没勾选上或者RT补丁下某驱动编译失败模块根本没生成。办法先在menuconfig里确认Device Drivers - Network device support里对应平台网卡的驱动状态。我遇到的LubanCat 5的千兆网卡和WiFi模块都需要手动确认默认defconfig在全清之后有些模块由于depends条件变化没有被重新选上。解决后重新编译module并安装或者直接编进内核确保CONFIG_*_GETHERNET、CONFIG_MT76*这类选项为y。6.3 U-Boot引导新内核时卡在Starting kernel症状按RKDevTool烧录完boot.img重启后串口输出停在Starting kernel屏幕黑屏。原因大概率是boot.img里的ramdisk和设备树搭配不对。我的踩坑经验是如果不需要initramfs可以在boot.img打包时传一个空的ramdisk并从U-Boot bootargs里去掉root依赖initramfs的设备。更省事的做法是直接用SDK脚本重新打包整个update.img不做单分区boot.img烧录这样版本一致性由SDK保证。6.4 实时任务总是被打断的隐性凶手现象cyclictest的数据看起来不错但实际应用里某个高频任务还是偶尔出现几百微秒的尖峰。隐秘原因除了CPU隔离还要检查中断亲和性。默认情况下网卡中断、定时器中断会均匀分配在多个CPU上如果网卡中断落在你绑定的实时CPU上哪怕只有一次中断风暴也会造成尖峰。解决办法是把这些设备中断的亲和性设置到非隔离核# 查看网络中断号 cat /proc/interrupts # 把eth0对应的中断亲和性改到CPU0 echo 1 /proc/irq/IRQ_NUMBER/smp_affinity另一个隐形凶手是内核的watchdog。lockup检测相关的watchdog线程可能会在隔离核上唤醒虽然频率不高但每次唤醒都会引入抖动。建议在内核配置里关闭CONFIG_LOCKUP_DETECTOR或者在启动参数里加nowatchdog。6.5 RKDevTool烧录到一半失败后板子变砖的抢救流程如果烧录过程中途断电或者烧错了固件导致引导链损坏板子还是能救的前提是BootROM没坏。抢救流程断电按住BOOT键上电电脑端识别出LOADER设备如果识别出MaskROM设备那就是引导链彻底没了。在RKDevTool里选择完整固件包建议用SDK编译的update.img执行升级。如果连LOADER都进不去需要进入MaskROM模式找到板上预留的MaskROM触点或按钮短接后上电。这种情况能识别到MASKROM设备后烧正常固件板子就回来了。这里再强调一次拿到板子先备份原厂固件这句话价值千金。别等到砖了才想起备份。7. 个人使用心得与延伸建议软实时化改造完成后我把LubanCat 5部署在了一个小型四轴机械臂的控制系统里跑的是2ms周期的位置环底层通过CANopen跟伺服驱动器通信上位机同时还在跑一个轻量级的YOLO目标检测。连续运行三天后观察位置环的最大超期次数是0这在我之前的树莓派4B上是完全做不到的。关于这套方案的延伸方向有三条路值得继续探索配合实时网络协议LubanCat 5目前没有原生EtherCAT主站但可以外接USB转EtherCAT模块RT内核下EtherCAT主站协议栈的抖动表现会更好这是做多轴同步控制很香的方案。内核RCU与中断线程化的进一步调优PREEMPT_RT内核里中断线程化默认开启可以针对高频外设自行调整中断线程的优先级把最关键的外设中断拉到RT优先级之上。认真考虑异构核分配RK3576的A72和A53在软实时场景里可以做明确分工A53核跑实时控制任务功耗低、发热低、频率稳定A72核跑重型计算配合内存带宽预留效果比全部绑在大核上更好。最后分享一个我在实际过程中领悟到的小技巧软实时化不要只盯着内核配置整个系统链路上的每个环节都可能成为延迟来源。比如你的实时任务如果是Python写的GIL和垃圾回收带来的停顿就足以毁掉一次控制周期再比如存储设备采用SD卡时偶发的写卡回刷会让任务卡顿几十毫秒。所以做软实时之前先把用户态数据结构用环形缓冲、把任务逻辑用编译型语言重写、把日志写入放到独立线程这些事情做扎实了再配上RT内核整个系统的延迟表现才能真正稳定下来。这块板子加上这套配置目前是我在RK3576平台上做低延迟应用的首选组合。
LubanCat 5软实时化实战：RK3576内核编译与烧录全记录
做机器人运动控制或者高精度数据采集的朋友应该都遇到过这种情况板子明明跑得挺快但任务总会出现几十毫秒的卡顿。如果你手里拿到的是LubanCat 5也就是基于瑞芯微RK3576平台的这块开发板想让它承担一些对时序敏感的工作默认的内核调度策略大概率会让你抓狂。这篇文章想聊的就是我给LubanCat 5做软实时化改造的全过程顺带把RKDevTool这个官方烧录工具的使用细节一并讲透。文章适合刚接触嵌入式Linux实时性优化、或者正在折腾RK3576平台开发板的开发者读了之后你能少走不少弯路。1. 为什么说软实时化是RK3576开发板的第一站很多人一上来就问软实时是不是就是打上PREEMPT_RT补丁这么说对了一半。真正理解这件事之前得先把实时这个概念放在实际场景里过一遍。1.1 软实时与硬实时的边界在哪儿硬实时的典型代表是飞控、医疗器械、工业PLC这类系统任务响应一旦超过某个时间上限系统直接算失败可能带来物理上的损坏或安全事故。软实时的标准则宽松得多它允许偶发的超时但要求绝大多数情况下延迟保持在一个可接受的范围内比如控制周期2ms那么99.9%以上的调度延迟要低于这个值。开发板上的Linux之所以能做软实时靠的是内核的抢占机制优化而不是换一套RTOS。LubanCat 5这颗RK3576跑Linux做软实时本质上是用它那4个Cortex-A72大核扛住复杂计算再用Cortex-A53小核配合实时调度策略处理周期性任务。相比在STM32这类MCU上做硬实时开发板的优势是算力充足、生态完善你可以在同一个系统里跑视觉算法、神经网络推理和运动控制劣势则是延迟的下限远不如MCU稳定所以如果项目真的到了微秒级必须满足的环节别纠结软实时直接上MCU加实时核的方案更靠谱。1.2 哪些场景配得上软实时别硬上我实际测试下来LubanCat 5做软实时化之后在以下这些场景里有明显的收益机器人关节控制通过CAN或者EtherCAT下发指令周期2ms到10ms需要稳定的调度节拍。高速数据采集ADC采样、传感器数据读取配合时间戳处理延迟抖动直接影响数据对齐。音频处理与软件无线电数据流需要持续以固定周期搬运和计算偶发几十毫秒卡顿会造成明显爆音或丢包。自动化测试设备需要按精确时序触发外部仪器动作。反过来如果只是跑跑Web服务、做做图像分类推理那软实时化带来的收益几乎感知不到反而可能因为内核配置变化引入兼容性问题。还有一类情况别硬上你必须依赖某个闭源内核模块而这个模块没有适配PREEMPT_RT补丁后的内核API这种情况下强行改造会让驱动加载直接失败项目进度被拖死。2. LubanCat 5硬件平台的实时性瓶颈想优化延迟得先知道延迟是从哪里来的。RK3576这颗SoC本身性能不弱但Linux默认把它当普通服务器用自然就会出现各种抖动源。2.1 RK3576芯片底子A72大核与A53小核的调度博弈RK3576采用了4个Cortex-A72加4个Cortex-A53的big.LITTLE架构。这种异构设计在功耗上有优势但调度器如果频繁把任务在大核和小核之间迁移缓存亲和性就被破坏了任务每次跑到新核上都要重新加载指令和数据延迟自然飙升。默认的Linux调度器会基于负载均衡机制时不时把进程搬来搬去。对实时任务来说CPU迁移是最大的敌人。我在配置软实时内核时第一件事就是把实时任务绑死在某个性能核上并且通过内核启动参数把其他核隔离出调度器的负载均衡范围。这个后面会详细说操作。2.2 影响实时性的三座大山调度延迟、中断延迟、频率切换调度延迟一个进程进入就绪状态后要等多久才能被调度器选中运行。普通内核里如果当前CPU上有其他进程持锁或者长时间运行这个等待时间是不可控的。中断延迟硬件中断产生后内核要完成中断响应和处理中断处理过程中如果关闭了本地中断local_irq_disable实时任务只能干等。频率切换与电源管理DVFS导致CPU运行频率动态变化如果任务正跑到一半频率被降下去执行时间立刻拉长更深的问题是频率切换过程本身会暂停CPU几十微秒到上百微秒。这三座大山在默认Linux系统里都存在而PREEMPT_RT补丁主要解决的是前两个问题通过让内核几乎所有路径都可被抢占把调度延迟和中断延迟压缩到几十微秒级别。频率切换的问题则需要靠CPU调频策略和隔离参数来规避我会优先把所有实时核心固定在最高频率运行。3. 动手配置PREEMPT_RT内核从源码到启动一次过现在进入正题。我给LubanCat 5做软实时化的方案核心是重新编译一个带PREEMPT_RT支持的内核再配合启动参数和系统配置把抖动压下去。3.1 准备编译环境和内核源码LubanCat 5的Linux源码可以从野火官方的Gitee仓库下载分支一般对应Linux 6.1或5.10取决于SDK版本。我建议先确认一下你的板子出厂固件内核版本再找对应版本的源码和RT补丁。# 以Ubuntu 22.04主机为例安装交叉编译工具链和依赖 sudo apt update sudo apt install -y gcc-aarch64-linux-gnu make flex bison libssl-dev libncurses-dev然后下载内核源码git clone https://gitee.com/LubanCat/LubanCat5-Kernel.git -b linux-6.1-rt确认分支名的时候留意仓库说明不同批次的板子分支命名可能不同。如果没有现成的rt分支就需要自己下载对应版本的内核源码和RT补丁。3.2 打补丁与内核配置的关键选项内核版本与RT补丁版本是一一对应的比如内核6.1.x有对应的patch-6.1.y-rt{z}.patch.xz。我在编译时踩过一次版本不匹配的坑补丁打上去直接报错所以这一步必须查准。cd LubanCat5-Kernel # 假设内核版本是6.1.75RT补丁是6.1.75-rt18 xzcat patch-6.1.75-rt18.patch.xz | patch -p1 --dry-run # 确认无冲突后去掉--dry-run正式执行打完补丁后生成默认配置。LubanCat的SDK里一般带了一份rockchip_linux_defconfig需要在此基础上做调整make ARCHarm64 rockchip_linux_defconfig make ARCHarm64 menuconfigmenuconfig里必须确认以下选项配置项路径推荐值CONFIG_PREEMPT_RTKernel Features - Preemption ModelFully Preemptible Kernel (Real-Time)CONFIG_HZ_1000Kernel Features - Timer frequency1000 HzCONFIG_RCU_NOCB_CPUGeneral setup - RCU Subsystem建议启用并设置no-callback CPUsCONFIG_NO_HZ_FULLGeneral setup - Timers subsystem建议启用配合isolcpus使用如果menuconfig里看不到Fully Preemptible Kernel选项说明RT补丁没有打进Kernel Features的Kconfig选择项需要退回上一步确认补丁状态。这是我复现过无数次的经验补丁没打进去时一切都白搭。3.3 编译得到boot.img并部署配置好之后开始编译make ARCHarm64 CROSS_COMPILEaarch64-linux-gnu- -j$(nproc)编译完成后重点产物是arch/arm64/boot/Image然后还需要做两件事一是生成设备树文件LubanCat 5的设备树我遇到的是rk3576-lubancat-5.dtb二是用内核打包脚本生成boot.img因为Rockchip平台的引导机制要求内核和dtb打包成Android boot格式的镜像。LubanCat SDK里一般有打包脚本如果找不到可以参考Rockchip官方提供的mkbootimg./mkbootimg --kernel arch/arm64/boot/Image --dtb arch/arm64/boot/dts/rockchip/rk3576-lubancat-5.dtb --ramdisk ramdisk.img -o boot.imgramdisk这边我图省事直接从原厂boot.img里解包提取。生成boot.img后会放在RKDevTool烧录里用跟第四部分正好衔接上。3.4 启动参数与CPU隔离的调优组合编译好内核只是第一步真正让软实时生效的是启动参数。我的建议组合是这样isolcpus4,5,6,7 nohz_full4,5,6,7 rcu_nocbs4,5,6,7含义解释isolcpus把4到7号CPU从调度器的负载均衡范围里剔除普通进程不会跑上去把空间腾给实时任务。nohz_full让这些CPU在只有一个运行队列任务时完全关闭周期时钟节拍减少无谓的定时器中断。rcu_nocbs把这些CPU上的RCU回调处理offload到其他CPU避免RCU机制打断实时任务。实际修改时可以在U-Boot环境变量里追加bootargs也可以在RKDevTool烧录的parameter分区里设置。我建议直接在U-Boot的bootargs变量里改这样不用重新烧录分区调试效率高。启动后把实时任务的CPU亲和性绑定到隔离核上可以用Linux提供的工具taskset -c 6 ./your_realtime_task同时把实时任务的调度策略切换到SCHED_FIFO并设置高优先级chrt -f -p 80 PID最后不要忘了把隔离核的CPU调频策略固定到最高性能档位。这一步很关键否则频率切换带来的延迟抖动会让前面所有努力白费cpufreq-set -c 6 -g performance4. RKDevTool的完整工作流程从驱动安装到分区烧录编译出的boot.img总归要烧进板子。瑞芯微平台的烧录工具RKDevTool是Windows下的标准方案整个流程有几个容易出问题的地方我拆开讲。4.1 驱动安装与设备识别RKDevTool运行依赖Rockchip USB驱动。驱动和工具可以在野火的资料包或者瑞芯微官网下载到下载后先运行DriverInstall.exe选择驱动安装按钮。这一步如果没右键管理员身份运行大概率安装失败。驱动装好后把LubanCat 5断电用Type-C数据线连接电脑和板子上的烧录口。然后按住板子上的BOOT按键不放给板子上电电脑端会听到USB设备插入提示音。打开RKDevTool主界面正常的话会看到一个设备行显示LOADER设备说明驱动识别成功。4.2 Loader模式和MaskROM模式的区别这是新手最容易混淆的两个概念Loader模式板子的BootROM发现eMMC或SD卡里存在可用的U-Boot于是加载U-Boot进入烧录等待状态。这种模式下你只能烧写部分分区不能动Loader相关的引导链。MaskROM模式板子的eMMC/SD里的引导链已经损坏或者完全没有BootROM只能进入内置的MaskROM模式。这个模式是最底层的烧录保险可以把你所有分区重新刷干净。实际操作中正常软硬件下按住BOOT上电进的是Loader模式。如果板子已经被你折腾得无法开机也不要慌按住BOOT键配合上电通常还是会进入Loader模式只有极少数情况才需要短接MaskROM触点强制进入MaskROM。我建议尽量不要轻易触发MaskROM因为MaskROM模式下烧错镜像会直接把引导链覆盖风险更大。4.3 烧录前备份原厂固件我强烈建议拿到新板子、还没折腾之前先用RKDevTool把原厂固件完整读出来。备份方式有两种在RKDevTool选中设备后点击导出镜像把整个Flash内容导出生成一个大文件。进入高级功能页按分区逐个导出比如uboot、resource、boot、rootfs等。单独备份分区的好处是之后每次实验只需要回滚某个分区就行。我习惯备份成镜像文件后立即复制一份到外部存储防止误操作覆盖。4.4 分区镜像烧录的具体操作用RKDevTool烧录分区的操作比想象中简单但注意细节主界面左侧是烧录分区列表格式是分区名镜像路径。默认烧录配置可能带了一个完整固件包如果你只想更新boot.img就把地址列表中boot那行右侧的镜像路径改成自己编译好的boot.img其余分区保持空白。点击执行升级开始烧录。烧录过程中千万不要拔线断电。烧录完成后设备会自动重启进入系统。如果执行烧录时提示设备识别失败或者卡在准备设备大概率是驱动问题。我遇到过一次很诡异的情况换了根Type-C线就好了原因是不合格的数据线只有充电能力没有数据通道。所以如果识别不稳定先换线再说。5. 实测数据说话延迟对比与性能评估配置做完了性能到底怎么样不能靠感觉。我用了rt-tests里的cyclictest做了延迟测试在改造前后分别跑了一组数据来对比。5.1 cyclictest的安装与其参数含义在板子终端上安装rt-testssudo apt install rt-tests然后运行以下测试参数cyclictest -t 1 -p 80 -i 1000 -l 100000 -q -h 1000参数解释-t 1只跑一个测试线程避免线程调度造成的干扰测的是极限调度延迟。-p 80SCHED_FIFO优先级80让测试线程优先于普通进程。-i 1000采样周期1000微秒。-l 100000采样10万个周期大约100秒。-h 1000打印延迟直方图范围到1000微秒。为了更接近真实场景我又跑了一个多线程压力测试版本在后台用stress-ng --cpu 8 --io 4压满其他核再测实时任务受到的干扰。5.2 改造前后的数据对比我整理了改造前后、以及是否附加CPU压力的四组数据列出Max和Avg两个关键指标单位微秒测试场景平均延迟最大延迟超过500us次数默认内核无压力458903默认内核CPU压力120230045RT内核隔离核无压力19880RT内核隔离核CPU压力221700数据说明了两件事第一默认内核在空闲状态下最大延迟已经到了890微秒这对周期2ms的控制任务来说虽然勉强能跑但风险很高第二一旦系统负载上来默认内核的最大延迟飙到2.3毫秒直接任务超时。而软实时化后的系统即便CPU全压满最大延迟也只有170微秒左右这个数据基本可以覆盖10ms以下的周期控制任务。5.3 实际场景里的附加收益除了cyclictest我还跑了一遍LubanCat 5自带的NPU推理测试加了RT内核之后推理耗时反而比默认内核稍慢一点这是因为PREEMPT_RT内核本身会增加一些锁和上下文切换开销。所以如果你只是纯算力场景软实时化反而有点负优化。这也印证了我开头说的软实时化要围绕你需要哪些实时任务来设计而不是无脑全系统开启。6. 实操中绕不开的那些坑与处理方案这部分我按自己踩过的真实顺序列出几个高频坑基本覆盖了从编译到烧录再到运行的完整链路。6.1 编译RT内核时.config残留导致的玄学报错症状在已有内核源码上切到RT分支后直接编译报一堆莫名其妙的undefined reference错误。原因之前的构建产物和.config没有清理干净新旧配置混在一起尤其是CONFIG_SECURITY、CONFIG_DEBUG_INFO这类选项的状态会影响大量模块构建。解决办法不要省时间直接全清make distclean # 重新从defconfig开始配置 make ARCHarm64 rockchip_linux_defconfig # 然后再menconfig修改RT相关选项6.2 RT内核起来之后网卡或WiFi消失症状新内核能进系统终端有输出但网络接口没了。原因内核配置里把Boardcom或者Rockchip网卡对应的驱动模块没勾选上或者RT补丁下某驱动编译失败模块根本没生成。办法先在menuconfig里确认Device Drivers - Network device support里对应平台网卡的驱动状态。我遇到的LubanCat 5的千兆网卡和WiFi模块都需要手动确认默认defconfig在全清之后有些模块由于depends条件变化没有被重新选上。解决后重新编译module并安装或者直接编进内核确保CONFIG_*_GETHERNET、CONFIG_MT76*这类选项为y。6.3 U-Boot引导新内核时卡在Starting kernel症状按RKDevTool烧录完boot.img重启后串口输出停在Starting kernel屏幕黑屏。原因大概率是boot.img里的ramdisk和设备树搭配不对。我的踩坑经验是如果不需要initramfs可以在boot.img打包时传一个空的ramdisk并从U-Boot bootargs里去掉root依赖initramfs的设备。更省事的做法是直接用SDK脚本重新打包整个update.img不做单分区boot.img烧录这样版本一致性由SDK保证。6.4 实时任务总是被打断的隐性凶手现象cyclictest的数据看起来不错但实际应用里某个高频任务还是偶尔出现几百微秒的尖峰。隐秘原因除了CPU隔离还要检查中断亲和性。默认情况下网卡中断、定时器中断会均匀分配在多个CPU上如果网卡中断落在你绑定的实时CPU上哪怕只有一次中断风暴也会造成尖峰。解决办法是把这些设备中断的亲和性设置到非隔离核# 查看网络中断号 cat /proc/interrupts # 把eth0对应的中断亲和性改到CPU0 echo 1 /proc/irq/IRQ_NUMBER/smp_affinity另一个隐形凶手是内核的watchdog。lockup检测相关的watchdog线程可能会在隔离核上唤醒虽然频率不高但每次唤醒都会引入抖动。建议在内核配置里关闭CONFIG_LOCKUP_DETECTOR或者在启动参数里加nowatchdog。6.5 RKDevTool烧录到一半失败后板子变砖的抢救流程如果烧录过程中途断电或者烧错了固件导致引导链损坏板子还是能救的前提是BootROM没坏。抢救流程断电按住BOOT键上电电脑端识别出LOADER设备如果识别出MaskROM设备那就是引导链彻底没了。在RKDevTool里选择完整固件包建议用SDK编译的update.img执行升级。如果连LOADER都进不去需要进入MaskROM模式找到板上预留的MaskROM触点或按钮短接后上电。这种情况能识别到MASKROM设备后烧正常固件板子就回来了。这里再强调一次拿到板子先备份原厂固件这句话价值千金。别等到砖了才想起备份。7. 个人使用心得与延伸建议软实时化改造完成后我把LubanCat 5部署在了一个小型四轴机械臂的控制系统里跑的是2ms周期的位置环底层通过CANopen跟伺服驱动器通信上位机同时还在跑一个轻量级的YOLO目标检测。连续运行三天后观察位置环的最大超期次数是0这在我之前的树莓派4B上是完全做不到的。关于这套方案的延伸方向有三条路值得继续探索配合实时网络协议LubanCat 5目前没有原生EtherCAT主站但可以外接USB转EtherCAT模块RT内核下EtherCAT主站协议栈的抖动表现会更好这是做多轴同步控制很香的方案。内核RCU与中断线程化的进一步调优PREEMPT_RT内核里中断线程化默认开启可以针对高频外设自行调整中断线程的优先级把最关键的外设中断拉到RT优先级之上。认真考虑异构核分配RK3576的A72和A53在软实时场景里可以做明确分工A53核跑实时控制任务功耗低、发热低、频率稳定A72核跑重型计算配合内存带宽预留效果比全部绑在大核上更好。最后分享一个我在实际过程中领悟到的小技巧软实时化不要只盯着内核配置整个系统链路上的每个环节都可能成为延迟来源。比如你的实时任务如果是Python写的GIL和垃圾回收带来的停顿就足以毁掉一次控制周期再比如存储设备采用SD卡时偶发的写卡回刷会让任务卡顿几十毫秒。所以做软实时之前先把用户态数据结构用环形缓冲、把任务逻辑用编译型语言重写、把日志写入放到独立线程这些事情做扎实了再配上RT内核整个系统的延迟表现才能真正稳定下来。这块板子加上这套配置目前是我在RK3576平台上做低延迟应用的首选组合。
