1. 为什么要在CoolPi-4B上折腾软实时CoolPi-4B这块板子拿到手的第一感觉就是“接口给得真大方”——RK3588S的SoC四核A76加四核A55的big.LITTLE架构板载LPDDR4XeMMC、SPI NOR、PCIe NVMe、千兆网口、HDMI输出一应俱全。我最初买它其实只是想做个ARM64的编译节点后来因为手头有个运动控制的小项目需要跑在ARM平台上才动了给它打实时补丁的念头。先说清楚一个概念上的分界线。硬实时和软实时不是“好”和“差”的区别而是设计目标不同。硬实时系统要求最坏情况下的响应延迟有严格上界超时就是系统失效典型场景是工业伺服、航空飞控。软实时则允许极低概率的延迟超标只要统计意义上满足要求即可比如音视频流处理、机器人上层调度、数据采集。CoolPi-4B这种消费级ARM板卡硬件本身没有针对确定性延迟做设计中断控制器、内存控制器、电源管理都会引入抖动所以追求硬实时是不现实的但把它调成一块靠谱的软实时平台完全可行。我这次的目标很明确在CoolPi-4B上跑一个打了RT补丁的Linux内核让一个周期性任务的调度抖动控制在百微秒量级同时保留NVMe SSD作为根文件系统的能力。这个需求听起来简单但RK3588S这个平台有几个坑是绕不开的一是主线内核对该SoC的支持还在完善中二是RT补丁和厂商BSP内核的版本匹配问题三是存储方案的选择会直接影响启动流程和内核配置。下面我把整个过程拆开讲包括我踩过的坑和最后跑通的方案。2. 硬件平台与存储方案的选型考量2.1 CoolPi-4B的硬件底子适不适合做实时RK3588S是瑞芯微RK3588的简化版主要砍掉了部分显示接口和PCIe通道但CPU核心、内存控制器、GIC中断控制器这些和实时性直接相关的部分基本一致。八核架构里A76跑实时任务、A55跑普通任务这种非对称分配是ARM平台上做软实时的常见思路。板子的LPDDR4X内存带宽够用但要注意内存控制器的QoS配置在BSP内核里通常没有暴露出来主线内核更是完全没有所以内存访问延迟的抖动只能靠CPU隔离和缓存锁定来缓解。另一个关键点是中断延迟。RK3588S的GIC-600支持中断亲和性设置可以把特定中断绑定到特定CPU核心上。我在实测中发现把定时器中断和网卡中断分开绑核之后周期性任务的抖动明显下降。这个后面会详细说。2.2 SPI NOR存引导、NVMe存系统的混合方案CoolPi-4B板载了一颗SPI NOR Flash容量不大通常16MB或32MB。这个容量装一个完整的Linux系统是不够的但放引导加载程序U-Boot和内核镜像绰绰有余。我的方案是SPI NOR里放U-Boot和内核NVMe SSD上放根文件系统。这样做的理由有三个。第一引导链路的确定性。SPI NOR的读取延迟是确定的不像eMMC或SD卡那样有复杂的FTL层和垃圾回收导致的延迟波动。U-Boot从SPI NOR加载内核镜像整个过程时间可预测这对实时系统的启动一致性有帮助。第二根文件系统放在NVMe上读写性能远超eMMC而且NVMe的队列机制在高负载下表现更稳定。但要注意NVMe的电源管理和热插拔事件会产生中断这些中断如果和实时任务抢CPU就会引入抖动。解决办法是在内核启动参数里禁用NVMe的APSTAutonomous Power State Transition并把NVMe中断绑定到非实时核心上。第三SPI NOR的容量限制反而成了优势——它强迫你把引导和系统分离这种分离在调试阶段特别有用。内核挂了不影响根文件系统重新烧写SPI NOR比重新烧写整个eMMC快得多。具体分区方案我试过两版。第一版是SPI NOR里放U-Boot加内核加DTBNVMe上分两个区一个做根文件系统一个做数据。第二版把内核也挪到了NVMe上SPI NOR只放U-Boot。实测下来第一版的启动时间更短因为U-Boot从SPI NOR读内核比从NVMe读快而且少了一次PCIe枚举的等待。所以最终方案是存储位置内容大小说明SPI NORU-Boot 环境变量前4MB引导加载程序SPI NOR内核Image DTB剩余空间压缩后约8-12MBNVMe分区1根文件系统32GBext4关闭日志或使用datawritebackNVMe分区2数据分区剩余用于日志和采集数据注意SPI NOR的写入寿命有限不要把日志或频繁写入的数据放在上面。内核镜像只在升级时写入所以寿命不是问题。2.3 为什么不用eMMC或SD卡eMMC和SD卡的问题在于它们的FTL层会引入不可预测的延迟。一次垃圾回收可能让读写延迟从几百微秒跳到几十毫秒这对软实时系统来说是灾难性的。NVMe SSD虽然也有FTL但它的并行通道更多队列深度更大在高负载下延迟的尾部表现明显好于eMMC。当然如果你只是做做实验eMMC也能用但一旦跑周期性任务抖动会大很多。3. 内核源码获取与RT补丁的匹配3.1 主线内核还是厂商BSP这是第一个让人纠结的地方。瑞芯微的BSP内核通常是5.10或6.1对RK3588S的支持最完整GPU、VPU、PCIe、USB都有现成驱动。但BSP内核的代码结构和主线差异较大RT补丁的移植工作量不小。主线内核从6.6开始对RK3588S的支持已经相当不错PCIe、NVMe、网卡都能跑但GPU和VPU还不行——不过做实时任务本来也不需要这些。我最终选了主线内核6.6.y原因是RT补丁对主线的支持最好而且主线内核的社区维护更活跃遇到问题更容易找到答案。代价是显示输出只有framebuffer没有GPU加速但我的应用场景是SSH远程操作显示无所谓。3.2 RT补丁版本的选择RT补丁的版本必须和内核版本严格对应。6.6.y内核对应的是patch-6.6.y-rt这个在kernel.org的RT分支上可以找到。我用的具体版本是6.6.30-rt30这个版本在我写这篇文章时已经比较稳定了。下载和打补丁的流程如下# 下载内核源码 wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.30.tar.xz tar xf linux-6.6.30.tar.xz cd linux-6.6.30 # 下载RT补丁 wget https://cdn.kernel.org/pub/linux/kernel/projects/rt/6.6/patch-6.6.30-rt30.patch.xz xz -d patch-6.6.30-rt30.patch.xz # 打补丁 patch -p1 patch-6.6.30-rt30.patch打补丁的时候如果出现reject文件说明内核版本和补丁版本不匹配需要换一个更接近的版本。我试过6.6.28配rt30的补丁有几个文件冲突手动改了之后也能用但不推荐这么做除非你很清楚自己在改什么。3.3 交叉编译工具链的准备在x86主机上交叉编译ARM64内核工具链用Linaro或者ARM官方的GCC都可以。我用的aarch64-linux-gnu-gcc 13.2从ARM开发者网站下载的解压即用版本。export ARCHarm64 export CROSS_COMPILEaarch64-linux-gnu- export PATH$PATH:/opt/gcc-arm-13.2/bin验证工具链是否可用aarch64-linux-gnu-gcc --version输出应该显示GCC版本信息。如果提示找不到命令检查PATH设置。4. 内核配置的关键选项4.1 基础配置与RK3588S支持先从一个基础defconfig开始。主线内核里没有专门的CoolPi-4B defconfig但RK3588的evb配置可以作为起点make defconfig然后手动开启RK3588S相关的选项。或者更省事的办法是找一个现成的RK3588 defconfig比如arch/arm64/configs/下的rockchip相关配置。如果没有就从defconfig开始确保以下选项被启用CONFIG_ARCH_ROCKCHIPyCONFIG_ARM64yCONFIG_PCIyCONFIG_PCIE_ROCKCHIP_HOSTyCONFIG_NVME_COREyCONFIG_BLK_DEV_NVMEyCONFIG_SPI_ROCKCHIPyCONFIG_MTD_SPI_NORy这些是让板子能启动、能识别NVMe和SPI NOR的最小集合。4.2 实时相关配置RT补丁打上之后内核配置里会多出一个“Preemption Model”选项。必须选“Fully Preemptible Kernel (Real-Time)”对应CONFIG_PREEMPT_RTy。这个选项是RT补丁的核心它把内核里大部分自旋锁换成了可睡眠的互斥锁把中断处理线程化从而让高优先级任务能抢占几乎所有的内核代码路径。除了抢占模型还有几个选项对实时性影响很大CONFIG_HIGH_RES_TIMERSy高精度定时器必须开。CONFIG_NO_HZ_FULLy让非实时核心完全停止调度时钟中断减少对实时核心的干扰。CONFIG_CPU_ISOLATIONy允许通过内核参数隔离CPU核心。CONFIG_RCU_NOCB_CPUy把RCU回调从实时核心上移走。CONFIG_PREEMPT_RTyRT补丁的主开关。还有一个容易被忽略的选项是CONFIG_DEBUG_PREEMPT。调试阶段可以开但生产环境一定要关因为它会引入额外的开销和延迟。4.3 存储与文件系统配置NVMe作为根文件系统需要把NVMe驱动编译进内核不是模块否则内核启动时找不到根设备。同时要确保CONFIG_EXT4_FSy因为根文件系统用ext4。SPI NOR方面CONFIG_MTD_SPI_NORy和CONFIG_SPI_ROCKCHIPy是必须的。如果要在U-Boot里读SPI NORU-Boot的配置也要对应打开。文件系统挂载参数对实时性有影响。ext4默认的dataordered模式会在每次写入时先写日志再写数据引入额外延迟。我改成datawriteback牺牲一点崩溃一致性换更低的写入延迟。另外在fstab里加上noatime避免每次读取都更新访问时间。# /etc/fstab 示例 /dev/nvme0n1p1 / ext4 defaults,noatime,datawriteback 0 1注意datawriteback在突然断电时可能导致最近写入的数据丢失但文件系统本身不会损坏。如果你的应用对数据完整性要求高还是用ordered模式然后通过其他手段降低写入频率。5. 编译、部署与启动链路5.1 内核编译配置好之后编译命令很直接make -j$(nproc) Image dtbs modules编译时间取决于主机性能一般x86六核机器上大概15到20分钟。编译完成后产物在arch/arm64/boot/Imagearch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dtb如果dts存在的话模块在编译目录下如果CoolPi-4B的dts在主线内核里还没有需要从厂商的BSP里移植过来。移植dts的工作量取决于板子和参考设计的差异主要是改电源管理、引脚复用和存储控制器节点。5.2 部署到SPI NOR和NVMe部署分两步。第一步是把U-Boot和内核写到SPI NOR第二步是把根文件系统写到NVMe。写SPI NOR可以用板子上的U-Boot通过TFTP或者从SD卡启动一个临时系统来操作。我用的方法是从SD卡启动一个最小的Linux然后用flashcp命令写# 在临时系统里操作 flashcp -v u-boot-rockchip.bin /dev/mtd0 flashcp -v Image /dev/mtd1 flashcp -v rk3588s-coolpi-4b.dtb /dev/mtd2NVMe的根文件系统可以用dd或者rsync部署。我习惯先用分区工具分好区然后mount上去rsyncmkfs.ext4 /dev/nvme0n1p1 mount /dev/nvme0n1p1 /mnt rsync -avx rootfs/ /mnt/5.3 U-Boot的启动参数U-Boot的环境变量决定了内核从哪里加载、根文件系统在哪里。我的bootargs是这样的consolettyS2,1500000n8 root/dev/nvme0n1p1 rootfstypeext4 rootwait rw isolcpus4-7 nohz_full4-7 rcu_nocbs4-7 irqaffinity0-3这里有几个关键参数需要解释。isolcpus4-7把A76的四个核心从调度器的常规负载均衡中隔离出来专门给实时任务用。nohz_full4-7让这四个核心在只有一个任务运行时停止调度时钟中断。rcu_nocbs4-7把RCU回调从这些核心上移走。irqaffinity0-3把所有中断默认绑定到A55核心上避免中断打扰A76上的实时任务。注意isolcpus和nohz_full的配置需要和实际任务分配一致。如果你把实时任务跑在核心0上那这些参数就白设了。6. 实时性能调优与实测6.1 CPU隔离与中断亲和性内核启动参数只是第一步。系统起来之后还需要用taskset或cgroup把实时任务绑定到隔离核心上。我用的方法是写一个systemd服务在ExecStart里用taskset指定核心taskset -c 4 /usr/local/bin/rt_task中断亲和性可以在运行时调整。查看当前中断分布cat /proc/interrupts找到NVMe和网卡的中断号然后设置亲和性echo 0f /proc/irq/123/smp_affinity这里的0f是十六进制掩码表示核心0到3。这样NVMe中断就不会跑到核心4-7上。6.2 用cyclictest测抖动cyclictest是RT社区的标准测试工具。编译安装git clone https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git cd rt-tests make sudo make install测试命令cyclictest -t1 -p99 -n -i1000 -l100000 -a4参数含义-t1一个线程-p99优先级99-n使用clock_nanosleep-i1000间隔1000微秒-l100000循环十万次-a4绑定到核心4。我在CoolPi-4B上跑出来的结果未调优之前最大延迟在300微秒左右调优之后CPU隔离加中断亲和性加RT补丁最大延迟降到80微秒以内平均延迟在15微秒左右。这个水平对于软实时应用是够用的。配置阶段平均延迟最大延迟备注原厂内核45us1200us无RT补丁RT内核未调优20us300us仅打补丁RT内核CPU隔离15us120usisolcpusRT内核隔离中断亲和15us80us最终方案6.3 内存锁定与页面错误实时任务如果发生页面错误延迟会飙升。解决办法是用mlockall把任务的内存锁定在RAM里#include sys/mman.h mlockall(MCL_CURRENT | MCL_FUTURE);这个调用要在任务开始分配内存之前执行。如果任务已经分配了内存MCL_CURRENT会把现有页面锁定MCL_FUTURE会锁定后续分配的页面。还有一个坑是透明大页THP。THP在后台做内存压缩时会引入延迟抖动。建议在实时核心上禁用THPecho never /sys/kernel/mm/transparent_hugepage/enabled7. 踩过的坑与排查记录7.1 内核启动卡在PCIe枚举第一次编译的内核启动时卡在PCIe枚举阶段串口没有任何输出。排查后发现是CONFIG_PCIE_ROCKCHIP_HOST没有开NVMe控制器没有被初始化。打开这个选项后问题解决。另一个相关的问题是PCIe链路训练超时。CoolPi-4B的NVMe接口在板子上是通过一个M.2插槽引出的如果SSD的功耗较大链路训练可能不稳定。我在dts里把PCIe的max-link-speed从Gen3降到Gen2稳定性明显提升。Gen2的带宽对于根文件系统来说完全够用。7.2 RT补丁导致的NVMe驱动报错打上RT补丁之后NVMe驱动在启动时报了一堆“sleeping function called from invalid context”的警告。这是因为RT补丁把自旋锁换成了可睡眠的互斥锁而NVMe驱动里有些代码路径假设自旋锁不会睡眠。这个问题在6.6.y的RT补丁里已经基本修复但如果你的内核版本稍旧可能需要手动打一些修复补丁。临时解决办法是在NVMe驱动里把有问题的自旋锁换回raw_spinlock_t。但这不是长久之计最好还是升级到修复过的内核版本。7.3 SPI NOR写入失败用flashcp写SPI NOR时偶尔会报“Erase failed”。原因是SPI NOR的擦除块大小和flashcp的默认参数不匹配。解决办法是指定擦除块大小flashcp -v -e 0x1000 u-boot-rockchip.bin /dev/mtd0或者用mtd_debug先擦除再写mtd_debug erase /dev/mtd0 0 0x400000 mtd_debug write /dev/mtd0 0 0x400000 u-boot-rockchip.bin7.4 常见问题速查表现象可能原因解决办法启动无输出串口参数错误确认波特率1500000找不到根文件系统NVMe驱动未编译进内核CONFIG_BLK_DEV_NVMEy实时任务抖动大CPU未隔离检查isolcpus参数NVMe中断干扰实时任务中断亲和性未设置设置smp_affinity页面错误导致延迟内存未锁定mlockallSPI NOR写入失败擦除块大小不匹配指定-e参数PCIe链路不稳定Gen3信号完整性降到Gen28. 后续可以继续折腾的方向这套方案跑通之后我又试了几个扩展。一个是在A55核心上跑Docker容器做普通任务A76核心上跑实时任务两者通过共享内存通信。另一个是给内核加上Xenomai的Cobalt内核做双内核实时方案但这个在ARM64上的支持还不如RT补丁成熟折腾了一阵就放弃了。如果你也想在CoolPi-4B上做类似的事情我的建议是从主线内核加RT补丁开始先把基础系统跑起来再逐步调优。不要一上来就追求极致的延迟数字先把功能跑通再根据实际应用的延迟要求做针对性优化。另外SPI NOR加NVMe的混合存储方案在调试阶段特别方便值得一试。