企业官网建设流程全解析

最近把一块 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_RT=y，恭喜你，官方镜像已经带了实时内核。如果只有CONFIG_PREEMPT_FULL=y，那还只是普通可抢占内核，离 RT 还有距离。LubanCat 5 这类瑞芯微开发板的官方系统不一定默认包含 RT 内核，所以很多情况下要自己编。自己编译内核并没有想象中难，关键是不要乱用网上老旧的补丁。现代内核版本可以先去 rt.wiki.kernel.org 找对应版本的 PREEMPT_RT patch，或者直接从厂商开源仓库的 RT 分支拉代码。我个人的习惯是先用厂商内核源码编译一版干净的普通内核，确认可以正常启动，再去叠加实时配置，这样排查问题时能明确知道是哪个改动导致的。

编译步骤大致如下：先准备好 aarch64 交叉编译工具链，进入厂商内核源码目录，查看 configs 目录下有没有对应板卡的 defconfig，然后执行编译。

export ARCH=arm64 export CROSS_COMPILE=aarch64-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 是 1ms，tick 越密集，调度决定越快，周期性任务的时间粒度越细。代价是开销略微增加，但在实时场景值得。
• 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 那样普遍用 GRUB，LubanCat 5 这类板子通常使用extlinux.conf或 u-boot 环境来设置内核命令行。

先找到启动配置文件，常见路径是/boot/extlinux/extlinux.conf，内容里有一行append开头或包含root=的字符串，在这一行后面追加实时参数：

# /boot/extlinux/extlinux.conf 的 append 行 append root=... rw console=ttyS0,1500000 isolcpus=4-7 nohz_full=4-7 rcu_nocbs=4-7

这几个参数的含义要记清楚：

• isolcpus=4-7：把 CPU4 到 CPU7 从默认调度器的负载均衡中剔除。普通用户进程不会自动跑上去，只有显式绑定到这些核的任务才会被分配过去。这是"圈地"最关键的一步。
• nohz_full=4-7：在列出的核上关闭周期性 tick，减少时钟中断对实时任务的打扰。前提是内核开了 CONFIG_NO_HZ_FULL。
• rcu_nocbs=4-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_us

Linux 默认有一个保护机制：实时调度策略任务（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_governor

LubanCat 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 模式

准备好需要烧录的镜像文件之后，按下面步骤走：

1. 在电脑上安装 Rockchip USB Driver，然后再安装 RKDevTool。驱动不装好的话，开发板插上去只会显示未知设备。
2. 用 USB Type-C 线把开发板和电脑连接。这里要注意，一定要连板子上的 OTG 烧录口，而不是普通 USB 口，两者在物理上很接近，但功能完全不同。
3. 进入 Loader 模式。比较通用的做法是按住板子上的 Recovery/MaskROM 按键，再给板子上电。如果板子已经进入系统，也可以在终端执行reboot loader命令，很多 RK 平台支持这个命令直接进入烧录模式。
4. 打开 RKDevTool，正常识别后界面会显示发现一个 Loader 设备，并显示 Loader 版本。
5. 切到"升级固件"页签，选择完整的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

看输出里是否包含isolcpus=4-7 nohz_full=4-7 rcu_nocbs=4-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 烧录迭代内核则帮我省了大量重复刷系统的时间，把开发重心从"折腾环境"挪到了"调业务代码"上。如果你现在的板子还没有达到预期的控制稳定性，建议按这套链路把内核、系统配置、应用和烧录依次过一遍，延迟数据会告诉你每一处改动到底值不值。