企业官网建设流程全解析

1. 从"能跑"到"跑得稳"：RK3568 上 OpenBMC 的性能瓶颈到底出在哪

把 OpenBMC 在 RK3568 上点亮，只是万里长征第一步。真正让人头疼的，是系统起来之后那一连串"能用但不好用"的问题：Web 界面点一下卡三秒、传感器数据刷新慢半拍、风扇控制策略响应迟钝、日志写入偶尔把 eMMC 拖到 IO 满载。这些现象背后，往往不是单一原因，而是 CPU 调度、内存带宽、存储 IO、GPU 渲染、网络协议栈几个层面叠加的结果。

RK3568 这颗芯片的定位很清晰：四核 Cortex-A55，主频最高 2.0GHz，集成 Mali-G52 2EE GPU，内置 1T 算力的 NPU，支持双千兆以太网、PCIe 3.0、USB 3.0、SATA 等一堆接口。放在 BMC 场景里，它的算力其实相当充裕——要知道很多传统 BMC 用的还是 ARM11 或者 Cortex-A7 级别的核心。但"算力充裕"和"系统流畅"之间隔着一条鸿沟，问题就出在 OpenBMC 这套软件栈本身是围绕服务器管理场景设计的，它的默认配置并没有针对嵌入式 ARM 平台做深度调优。

我在实际项目里遇到过最典型的一个场景：设备上电后 OpenBMC 的 Web 控制台（基于 bmcweb + React 前端）首次加载要等将近 8 秒，传感器页面每秒刷新一次时 CPU 占用率直接飙到 60% 以上。用top一看，bmcweb进程和phosphor-hwmon进程轮流抢占 CPU，而dbus-daemon的消息总线流量居高不下。这就是典型的"软件架构没适配硬件特性"导致的性能问题。

所以这一篇的核心，不是教你如何把 OpenBMC 编译出来烧进去——那是上一篇的事。这里要解决的是：当 OpenBMC 已经在 RK3568 上跑起来之后，怎么让它跑得跟原生嵌入式系统一样利索。我会从 CPU 调度、内存管理、存储 IO、GPU 加速、网络栈、DBus 通信六个维度拆解优化思路，同时给出几条"如果优化到头了还是不够用"的替代方案路线。适合已经完成基础移植、正在做产品化打磨的嵌入式工程师，也适合正在评估 RK3568 能不能扛住 BMC 负载的架构选型人员。

2. 先定位再动手：用数据找出真正的性能短板

优化最忌讳的就是"凭感觉调参"。我见过太多人一上来就改内核配置、加编译优化选项，结果折腾一周发现瓶颈根本不在那儿。正确的做法是先建立一套可量化的性能基线，然后逐项排查。

2.1 建立性能基线的三个必测指标

在 RK3568 上做 OpenBMC 性能分析，我建议至少盯住这三类指标：

第一类是 CPU 调度延迟。BMC 场景对实时性有要求，比如风扇控制需要在温度超阈值后 100ms 内响应。用cyclictest可以测出系统的最大调度延迟：

cyclictest -m -p 80 -n -i 1000 -l 10000 -h 400

在未优化的 RK3568 上，我实测最大延迟经常跑到 800μs 以上，个别情况能到 2ms。这个数字对于纯管理场景勉强够用，但如果你的设备还要跑一些软实时任务（比如 EtherCAT 主站），那就完全不够看了。

第二类是内存带宽与分配效率。用perf stat监控内存相关的硬件计数器：

perf stat -e cache-misses,cache-references,LLC-loads,LLC-load-misses \ -p $(pidof bmcweb) sleep 10

如果 LLC-load-misses 比例超过 15%，说明缓存命中率偏低，可能需要调整数据结构的对齐方式或者减少大块内存的频繁分配释放。

第三类是存储 IO 延迟。OpenBMC 的日志系统（phosphor-logging）和持久化存储（phosphor-persistent-storage）会频繁读写 eMMC。用iostat观察：

iostat -x 1 10

重点关注%util和await两个字段。如果%util长期高于 70%，说明存储子系统已经是瓶颈了。

2.2 用火焰图锁定热点函数

基线数据只能告诉你"哪里慢"，要找到"为什么慢"，火焰图是最直观的工具。在 RK3568 上跑火焰图需要先交叉编译perf工具，然后：

perf record -F 99 -a -g -- sleep 30 perf script > out.perf # 把 out.perf 拉到宿主机上用 FlameGraph 生成 SVG

我之前在一个项目里通过火焰图发现，bmcweb的 CPU 时间有 40% 花在了 JSON 序列化上——具体来说是nlohmann::json的频繁构造和析构。这个发现直接引导我们做了针对性的优化：把传感器数据的 JSON 序列化改成增量更新，而不是每次全量重建。改完之后 Web 端传感器页面的 CPU 占用从 60% 降到了 22%。

2.3 常见性能问题的快速对照表

这张表是我在多个项目中总结出来的，基本上覆盖了 80% 的常见问题。建议你先对照排查，再进入下面的具体优化环节。

3. CPU 与内存层面的调优：让四个 A55 核心物尽其用

RK3568 的四个 Cortex-A55 核心在 BMC 场景下通常不会全部跑满，但问题在于负载分布极不均匀——往往一个核心忙得要死，另外三个在摸鱼。这跟 OpenBMC 的服务架构有关：很多 phosphor 服务是单线程的，DBus 消息处理也是串行的。

3.1 CPU 亲和性与调度策略调整

首先要做的是把关键服务绑定到固定核心上，减少上下文切换和缓存失效。比如把bmcweb绑到 CPU2，把phosphor-hwmon绑到 CPU3，让 CPU0 和 CPU1 处理系统通用任务：

# 在 systemd service 文件中添加 [Service] CPUAffinity=2 Nice=-5

对于实时性要求高的任务（比如风扇控制的 PID 循环），可以启用SCHED_FIFO调度策略：

chrt -f 50 $(pidof phosphor-fan-control)

但要注意，SCHED_FIFO用不好会导致系统卡死——如果实时线程进入死循环，它会永远抢占 CPU。所以务必配合RLIMIT_RTTIME限制单次运行时间。

另外，RK3568 支持 CPU 频率调节，默认的schedutil调频器在 BMC 这种负载波动大的场景下反应偏慢。我建议改成performance调频器，让 CPU 始终跑在最高频率：

echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor

代价是功耗会上升大约 15%-20%，但对于有主动散热的设备来说完全可以接受。如果你的设备是无风扇设计，那就需要权衡了——可以考虑ondemand调频器配合更激进的 up_threshold 参数。

3.2 内存分配优化与 zram 的使用

OpenBMC 在 RK3568 上通常配 1GB 或 2GB DDR。听起来不少，但 phosphor 系列服务加上 bmcweb、dbus-daemon、systemd 本身，再加上各种日志缓冲区，实际可用内存经常只剩 300-400MB。

我常用的几个手段：

启用 zram 作为交换分区。zram 是在内存里做压缩交换，比 eMMC swap 快几个数量级，而且不会磨损存储：

modprobe zram echo 256M > /sys/block/zram0/disksize mkswap /dev/zram0 swapon /dev/zram0 -p 100

在 RK3568 上，zram 用 lz4 压缩算法时压缩比大约 2.5:1，256MB 的 zram 实际能提供约 640MB 的可用交换空间，对缓解内存压力效果很明显。

调整虚拟内存参数。OpenBMC 默认的vm.swappiness是 60，对于嵌入式场景偏高。建议降到 30 左右，让内核更倾向于回收 page cache 而不是换出匿名页：

echo 30 > /proc/sys/vm/swappiness echo 100 > /proc/sys/vm/vfs_cache_pressure

减少不必要的内存分配。用valgrind --tool=massif分析 bmcweb 的内存使用，我发现它在处理每个 HTTP 请求时都会分配一个 64KB 的缓冲区，即使请求体只有几百字节。改成动态分配后，峰值内存降低了约 40MB。

3.3 内核配置的针对性裁剪

OpenBMC 默认的内核配置是面向通用服务器的，里面有一大堆 RK3568 根本用不到的东西。裁剪内核不仅能减小镜像体积，还能减少内存占用和启动时间。

我通常会关掉这些：

• 所有非 ARM64 的架构支持
• 不用的文件系统（ext2、ext3、reiserfs、jfs 等）
• 不用的网络协议（ATM、X.25、DECnet 等）
• 不用的块设备驱动
• 调试相关的选项（在正式版本中）

但有几个选项必须保留甚至加强：

CONFIG_PREEMPT=y # 启用抢占式内核，降低调度延迟 CONFIG_HZ_1000=y # 提高时钟频率到 1000Hz CONFIG_HIGH_RES_TIMERS=y # 高精度定时器 CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_ZRAM=y CONFIG_ZSMALLOC=y

CONFIG_PREEMPT这一项对 BMC 场景的响应速度提升非常明显。我实测从CONFIG_PREEMPT_NONE改成CONFIG_PREEMPT后，cyclictest 的最大延迟从 800μs 降到了 120μs 左右。

4. 存储与 IO 路径优化：别让 eMMC 拖了后腿

RK3568 的存储接口比较丰富，eMMC 5.1、SD 3.0、SATA 3.0、NVMe（通过 PCIe）都支持。大部分 BMC 方案会用 eMMC 作为主存储，但 eMMC 的随机写入性能其实相当有限，尤其是小文件频繁写入的场景。

4.1 日志系统的 IO 优化

OpenBMC 的日志系统是 IO 大户。phosphor-logging 默认会把所有日志同时写到 journal（内存）和 persistent storage（eMMC）。在生产环境中，如果日志级别设得太细，eMMC 每天可能要承受几万次小写入。

我的做法是分三层处理：

第一层：调整 journald 配置，把日志先缓存在内存里，定期批量刷盘：

# /etc/systemd/journald.conf [Journal] Storage=volatile RuntimeMaxUse=64M SyncIntervalSec=30s RateLimitIntervalSec=10s RateLimitBurst=100

Storage=volatile表示日志只存在内存中，重启就丢。对于调试阶段够用，生产环境可以改成auto并配合下面的持久化策略。

第二层：持久化日志做聚合写入。phosphor-logging 默认每条日志单独写一个文件，这对 eMMC 非常不友好。我改成按天聚合，每天一个文件，写入时用O_APPEND模式：

// 伪代码示意 int fd = open("/var/log/bmc/combined.log", O_WRONLY | O_APPEND | O_CREAT, 0644); write(fd, log_entry, strlen(log_entry));

这样每天的写入次数从几万次降到几百次，eMMC 的 IO 压力大幅下降。

第三层：关键事件单独持久化。只有那些真正需要跨重启保留的事件（比如硬件故障、配置变更）才写入独立的持久化文件，其他日志滚动覆盖。

4.2 文件系统选择与挂载参数

OpenBMC 默认用 ext4，但在 eMMC 上，f2fs通常表现更好，尤其是随机写入场景。如果内核支持，我建议把数据分区格式化成 f2fs：

mkfs.f2fs -l bmc_data /dev/mmcblk0p5 mount -t f2fs -o noatime,nodiratime,discard /dev/mmcblk0p5 /var/lib/bmc

noatime和nodiratime能减少元数据写入，discard让文件系统主动通知 eMMC 回收无效块，避免长期使用后性能下降。

如果必须用 ext4，那至少加上这些挂载参数：

noatime,nodiratime,data=writeback,commit=60,barrier=0

data=writeback牺牲一点数据安全性换取写入性能，commit=60把日志提交间隔从默认的 5 秒延长到 60 秒，barrier=0关闭写屏障（前提是 eMMC 有掉电保护或者设备本身有超级电容）。

注意：barrier=0和data=writeback在意外掉电时可能导致数据损坏。如果你的设备没有掉电保护机制，这两个参数要慎用。

4.3 用 tmpfs 承载高频读写目录

OpenBMC 有几个目录是高频读写的，比如/var/run、/tmp、/var/cache。把这些目录挂到 tmpfs 上，直接消除 eMMC IO：

tmpfs /var/run tmpfs mode=755,nodev,nosuid,size=32M 0 0 tmpfs /tmp tmpfs mode=1777,nodev,nosuid,size=64M 0 0 tmpfs /var/cache tmpfs mode=755,nodev,nosuid,size=128M 0 0

但要注意，tmpfs 的内容重启就丢。对于需要保留的数据，要在关机脚本里做同步。我在项目里用了一个简单的方案：在/etc/systemd/system/shutdown-sync.service里定义关机前把 tmpfs 中的关键数据 rsync 到 eMMC。

5. GPU 与显示子系统的加速利用

RK3568 集成的 Mali-G52 2EE 在 BMC 场景下经常被忽略——很多人觉得 BMC 不需要 GPU。但实际上，OpenBMC 的 Web 界面如果启用了硬件加速渲染，流畅度会有质的提升。另外，如果你在 BMC 上跑了一些可视化监控面板，GPU 的作用就更明显了。

5.1 为 bmcweb 前端启用 GPU 渲染

OpenBMC 的 Web 前端是基于 React 的 SPA，默认用 CPU 做 Canvas 渲染。在 RK3568 上，可以通过配置 Chromium 的启动参数来启用 GPU 加速：

chromium --use-gl=egl --enable-gpu-rasterization \ --enable-zero-copy --ignore-gpu-blocklist \ --enable-features=VaapiVideoDecoder

前提是 Mali-G52 的驱动（通常是mali_kbase内核模块 + userspace 的 libmali）已经正确加载。检查方法：

cat /sys/class/misc/mali0/device/gpuinfo # 应该输出类似 "Mali-G52 2EE" 的信息

如果 GPU 驱动没加载，先排查设备树里 GPU 节点的配置。RK3568 的 GPU 节点在设备树里通常是这样的：

gpu: gpu@fde60000 { compatible = "rockchip,rk3568-mali", "arm,mali-bifrost"; reg = <0x0 0xfde60000 0x0 0x2000>; interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "job", "mmu", "gpu"; clocks = <&scmi_clk 1>, <&cru CLK_GPU>; clock-names = "core", "bus"; power-domains = <&power RK3568_PD_GPU>; operating-points-v2 = <&gpu_opp_table>; status = "okay"; };

5.2 用 GPU 卸载传感器数据可视化

如果你的 BMC 界面有实时曲线图（比如温度、功耗随时间变化的折线图），用 CPU 做 Canvas 绘制在数据点超过 1000 个时会明显卡顿。这时候可以用 WebGL 来做渲染，把绘制任务交给 GPU。

我在一个项目里把温度曲线从 Canvas 2D 改成了 WebGL 实现，帧率从 12fps 提升到了 55fps，CPU 占用从 35% 降到了 8%。核心思路是把数据点作为顶点缓冲区传给 GPU，用顶点着色器做坐标变换，片元着色器做颜色映射。

5.3 显示输出的竖屏转横屏设备树配置

RK3568 在很多 BMC 方案里会配一个小尺寸的 LCD 做本地显示。如果你用的是竖屏面板但需要横屏显示，除了在应用层做旋转，更高效的做法是在设备树里配置显示控制器的扫描方向。

以 MIPI DSI 面板为例，在设备树里调整panel节点的rotation属性：

panel: panel@0 { compatible = "simple-panel-dsi"; reg = <0>; rotation = <90>; /* 顺时针旋转90度 */ /* ... 其他配置 ... */ };

或者在 VOP（Video Output Processor）层面配置：

&vp0 { rockchip,plane-mask = <0x5>; rockchip,primary-plane = <0x0>; /* 通过调整扫描方向实现旋转 */ };

硬件旋转的好处是不消耗 CPU/GPU 算力，而且没有额外的内存带宽开销。但要注意，不是所有面板都支持硬件旋转，具体要看面板的时序控制器是否支持。

6. 网络与 DBus 通信的延迟压缩

BMC 的核心职责之一就是网络管理，而 OpenBMC 内部的服务间通信几乎全部走 DBus。这两条路径的延迟直接决定了用户操作的响应速度。

6.1 DBus 消息总线的拥塞治理

DBus 是 OpenBMC 的"神经系统"，但它的默认配置在高负载下会成为瓶颈。我遇到过最严重的情况是：dbus-daemon的 CPU 占用率长期在 40% 以上，消息队列积压导致传感器数据延迟超过 5 秒。

治理手段有几个：

减少不必要的信号广播。很多 phosphor 服务在属性变化时会广播PropertiesChanged信号，即使没有订阅者。可以通过配置只对已订阅的接口发送信号。在phosphor-dbus-interfaces的 YAML 定义里，把不需要广播的属性标记为emit-signal: false。

合并高频属性更新。比如温度传感器每秒上报 10 次，但 Web 界面只需要每秒刷新 1 次。可以在 hwmon 和 DBus 之间加一层聚合，把 10 次更新合并成 1 次：

// 伪代码：属性更新聚合 class PropertyAggregator { std::chrono::steady_clock::time_point lastEmit; static constexpr auto minInterval = std::chrono::milliseconds(1000); void update(const std::string& value) { pendingValue = value; auto now = std::chrono::steady_clock::now(); if (now - lastEmit >= minInterval) { emitSignal(pendingValue); lastEmit = now; } } };

增大 DBus 的消息缓冲区。默认的max_message_size是 128MB，但max_incoming_bytes和max_outgoing_bytes可能偏小。在/etc/dbus-1/system.conf里调整：

<limit name="max_incoming_bytes">134217728</limit> <limit name="max_outgoing_bytes">134217728</limit> <limit name="max_message_size">134217728</limit> <limit name="service_start_timeout">120000</limit> <limit name="auth_timeout">60000</limit>

6.2 网络协议栈的参数调优

RK3568 的双千兆网口在 BMC 场景下通常一个用于管理平面，一个用于数据平面。网络延迟的优化主要从 TCP 参数入手：

# 增大 TCP 读写缓冲区 echo "net.core.rmem_max = 16777216" >> /etc/sysctl.conf echo "net.core.wmem_max = 16777216" >> /etc/sysctl.conf echo "net.ipv4.tcp_rmem = 4096 87380 16777216" >> /etc/sysctl.conf echo "net.ipv4.tcp_wmem = 4096 65536 16777216" >> /etc/sysctl.conf # 启用 TCP 快速打开 echo "net.ipv4.tcp_fastopen = 3" >> /etc/sysctl.conf # 减少 TIME_WAIT 状态的连接数 echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.conf echo "net.ipv4.tcp_max_tw_buckets = 5000" >> /etc/sysctl.conf # 调整网络设备队列 echo "net.core.netdev_max_backlog = 5000" >> /etc/sysctl.conf

对于 Redfish 接口的 HTTPS 通信，还可以启用 TLS 会话复用，减少握手开销。在 bmcweb 的配置里：

{ "tls": { "session_cache_size": 1024, "session_timeout": 300 } }

6.3 中断亲和性与网络吞吐

RK3568 的 GMAC 控制器支持多队列，可以把不同队列的中断绑定到不同 CPU 核心上，避免单个核心被网络中断打满：

# 查看网卡队列数 ls /sys/class/net/eth0/queues/ # 把 rx-0 的中断绑到 CPU0，rx-1 绑到 CPU1 echo 1 > /sys/class/net/eth0/queues/rx-0/rps_cpus echo 2 > /sys/class/net/eth0/queues/rx-1/rps_cpus

同时调整netdev_max_backlog和napi_weight，让网络处理更高效。我实测在千兆满速传输时，经过中断亲和性优化后，CPU 占用从 45% 降到了 28%。

7. 当优化触到天花板：几条替代方案路线的取舍分析

说实话，OpenBMC 这套软件栈在 RK3568 上优化到一定程度后，你会遇到一些"结构性瓶颈"——不是调参能解决的，而是架构本身带来的。这时候就需要考虑替代方案了。

7.1 轻量化 BMC 框架的可行性评估

OpenBMC 的 phosphor 服务架构虽然模块化做得好，但服务数量多、DBus 通信开销大，这是它的"原罪"。如果你的设备功能相对简单（比如只需要 IPMI/Redfish + 传感器监控 + 风扇控制），可以考虑用更轻量的框架。

我评估过几个方向：

方案一：保留 bmcweb，替换 phosphor 服务层。bmcweb 本身设计得不错，Redfish 实现也完整。可以把 phosphor-hwmon、phosphor-fan-control 这些服务替换成自己写的轻量级守护进程，直接通过共享内存或 Unix socket 通信，绕过 DBus。这样能减少 60% 以上的 IPC 开销。

方案二：用 Go 或 Rust 重写核心服务。C++ 的 phosphor 服务在内存安全和并发处理上有些历史包袱。用 Go 重写的话，goroutine 模型天然适合高并发场景，而且交叉编译方便。用 Rust 的话性能更好，但开发周期会长一些。

方案三：完全自研 BMC 固件。如果团队有足够的嵌入式开发经验，直接基于 Linux + 自研管理服务可能是最彻底的方案。但代价是要自己实现 Redfish、IPMI、传感器管理、固件更新等一大堆功能，工作量巨大。

7.2 方案对比与选型建议

我的建议是：如果你的产品周期紧张，优先做 OpenBMC 深度优化，把上面几节的调优手段都用上，通常能解决 80% 的性能问题。如果产品已经量产但性能仍不达标，考虑方案二，保留 bmcweb 做 Redfish 前端，后端服务自己重写。完全自研只在极端情况下考虑，比如你的设备有非常特殊的实时性要求，或者 OpenBMC 的架构根本无法满足。

7.3 与 EtherCAT 等实时任务的共存策略

有些 RK3568 方案需要在跑 OpenBMC 的同时，还要跑 EtherCAT 主站（比如适配 IGH 主站驱动）。这两者对系统资源的需求是冲突的：OpenBMC 需要稳定的网络和存储 IO，EtherCAT 需要极低的调度延迟和精确的时钟同步。

我的做法是用 CPU 隔离 + 实时内核补丁：

# 内核启动参数：隔离 CPU3 给 EtherCAT 专用 isolcpus=3 nohz_full=3 rcu_nocbs=3

然后在 CPU3 上跑 EtherCAT 主站，用SCHED_FIFO最高优先级。OpenBMC 的所有服务绑定到 CPU0-CPU2。这样两套系统互不干扰，EtherCAT 的周期抖动可以控制在 10μs 以内。

但要注意，isolcpus隔离的核心不会被调度器自动分配任务，需要手动把 EtherCAT 线程绑上去。另外，IGH 主站的网卡驱动需要支持实时收发，通常要用ec_generic或者专门的ec_rk3568驱动。

8. 一些踩过坑之后才明白的实操细节

最后分享几个我在 RK3568 + OpenBMC 项目里踩过的坑，都是文档里不会写、但实际会遇到的。

第一个坑：设备树里的status属性被覆盖。RK3568 的很多外设节点在rk3568.dtsi里默认是disabled，需要在板级 DTS 里改成okay。但如果你用了&i2c3 { status = "okay"; }这种引用方式，而rk3568.dtsi里 i2c3 节点本身有status = "disabled"，那覆盖顺序就很重要。我遇到过因为 DTS 包含顺序问题导致 i2c 控制器没使能，排查了半天。

第二个坑：eMMC 的mmc-hs200模式不稳定。RK3568 的 eMMC 控制器支持 HS200 高速模式，但有些批次的 eMMC 芯片在 HS200 下会出现数据校验错误。如果遇到文件系统频繁报 IO 错误，可以在设备树里降速到 HS 模式：

&sdhci { mmc-hs200-1_8v; /* 如果 HS200 不稳定，注释掉上面这行，改用 */ /* mmc-hs-1_8v; */ };

第三个坑：phosphor-hwmon的轮询间隔不能设太短。默认是 1 秒，有人为了"实时性"改成 100ms，结果 DBus 消息量暴增，反而拖慢了整个系统。我的经验值是：温度传感器 1 秒、电压传感器 2 秒、风扇转速 500ms，这个组合在 RK3568 上比较平衡。

第四个坑：内核CONFIG_PREEMPT和CONFIG_DEBUG_PREEMPT不能同时开。后者会引入大量调试检查，导致性能急剧下降。我在一个项目里不小心开了DEBUG_PREEMPT，cyclictest 的最大延迟从 120μs 飙升到 3ms，查了一整天才发现是这个选项的问题。

第五个坑：zram 的压缩算法选择。lz4 最快但压缩比一般，zstd 压缩比高但 CPU 开销大。在 RK3568 的 A55 核心上，我推荐用 lz4，因为 A55 的压缩性能有限，用 zstd 反而会因为压缩耗时抵消掉内存节省带来的收益。实测 lz4 的压缩速度大约是 zstd 的 3 倍。

第六个坑：GPU 驱动和内核版本的匹配。Mali-G52 的mali_kbase驱动对内核版本很敏感，用错版本会导致 GPU 初始化失败或者渲染异常。建议从 Rockchip 的官方 SDK 里拿配套的驱动版本，不要自己从 ARM 官网下最新的。

这些坑的共同特点是：它们不会导致系统完全跑不起来，而是表现为"偶尔卡一下""性能不如预期"这种软性问题，排查起来特别费时间。希望这些经验能帮你少走弯路。