先说一个我自己的真实经历。前两年给客户做一台基于 RK3588 的边缘 AI 盒子部署在园区配电房做 YOLOv8 安全帽检测设备放在弱电井里7×24 跑推理。头一个月一切正常第二个月凌晨三点值班电话打过来——画面全黑设备失联。我驱车来回两小时结果到现场一看机器没死是 NPU 卡死了推理线程阻塞系统负载飙到 20 多网络假死。按一下复位好了。但这个场景发生在偏远站端呢来回一次的成本够买三台设备。从那以后我开始认真研究 RK3588 平台的“不死机”问题陆陆续续做了三版方案后来慢慢沉淀成一套完整的守护机制我管它叫 Guardian。今天把整套思路、配置、踩过的坑全部摊开讲希望能帮到正在做边缘 AI 设备的朋友。适合谁看如果你正在做基于 RK3588 的AI盒子、边缘计算终端、工业视觉设备或者已经遇到了设备长时间运行后死机、NPU 卡死、SSH 假死这类问题这篇文章应该能帮你省掉至少两个月的试错时间。1. 先说结论RK3588 边缘设备为什么需要“守护”而不是“运维”很多做产品的朋友一上来就讨论散热、电源、看门狗方向对但格局小了。RK3588 这块芯片本身是非常成熟的8nm 工艺、四核 A76 四核 A55、6 TOPS NPU算力在边缘侧完全够用。7×24 不死机的难点从来不在芯片而在芯片之外的整个“系统生态”。1.1 三个真实场景告诉你“不死机”有多难第一个场景工业检测。设备挂在产线旁边环境温度 40℃ 以上旁边还有电焊机、变频器这类强干扰源。RK3588 的 NPU 满载跑 YOLOv8整板功耗能摸到 15W 以上散热稍跟不上芯片温度直奔 85℃。温度一高CPU 降频推理帧率掉一半客户以为你算法不行其实你已经快死机了。第二个场景无人店 / 自助终端。这种场景往往是市电不稳晚上电压波动大设备用着用着突然断电或者“半断电”——电压忽高忽低导致 eMMC 写入出错。第二天开机系统起不来卡在 kernel panic只能派工单上门刷机。第三个场景车路协同边缘站。设备放在户外机柜网络是 5G CPE偶尔断网是常态。断网期间软件里的网络重连逻辑如果写得不好线程会不断堆积内存慢慢涨几天后 OOM系统自动杀掉关键进程然后整机进入假死状态。这三个场景说明一个问题边缘 AI 设备的不死机不是靠某一个看门狗芯片就能解决的而是一整套从硬件到内核再到应用的分层兜底机制。单纯靠远程运维去“救火”成本高、时效差用户根本等不起。1.2 死机是表象根因都在这些位置我统计了自己手上 RK3588 设备的故障记录大概 80% 的“死机”其实不是真正意义上的硬件死机而是下面这几种情况NPU 卡死RKNN 推理进程在调用rknn_run时长时间不返回或者返回了错误的错误码但应用层没处理导致进程不死不活。内核锁死常见于某些外设驱动异常比如 USB 摄像头掉线后内核在等待 USB 枚举超时或者 MIPI-CSI 信号异常导致 dmesg 刷屏把系统 IO 拖垮。OOM 被杀Python 推理进程内存泄漏跑几天后 RSS 涨到几个 GB触发内核 OOM killer关键进程被杀。文件系统写满或损坏日志没做轮转eMMC 被写满或者异常掉电导致 overlayfs/ext4 元数据损坏。有意思的是这些根因在实验室里都很难复现因为实验室环境太“干净”了。真正到了现场电网波动、高温、电磁干扰、断网、人为误操作各种因素叠加才会暴露问题。1.3 Guardian 守护的设计目标与分层思路我定义 Guardian 的目标很简单即使应用层已经“感知”不到系统了设备也必须能在无人干预的情况下自动恢复而且恢复时间越短越好。理想状态下最坏情况是 3 分钟内重启恢复期间如果用户询问运维人员只需要说一句“设备自愈了”就行。为了实现这个目标我采取的是分层兜底架构层级守护手段解决的问题L0 硬件层硬件看门狗、电源保护、温控系统崩溃、电池/电源异常L1 内核层内核 panic 自动重启、EDAC 内存错误内核级死锁、硬件错误L2 系统层systemd 服务健康检查、日志兜底关键服务异常退出L3 应用层进程守护、心跳上报、RKNN 超时恢复推理进程卡死、内存泄漏核心思路是每一层都只兜住自己下面的那一层不要把宝押在单一机制上。比如你写了很好的应用层守护但内核已经 panic 了应用层代码再漂亮也没用必须靠硬件看门狗把系统拉起来。反过来你不能只靠硬件看门狗因为它能做的只是“重启”重启之后应用层问题依旧存在设备会陷入反复重启的死循环。下面我把每一层的具体做法拆开讲能贴配置贴配置能贴代码贴代码都是实测验证过的。2. 硬件看门狗 软件看门狗把底兜住看门狗是整套 Guardian 的地基。如果地基打不好上面盖什么楼都没用。RK3588 内部自带硬件看门狗DW_wdtIP在 Linux 下对应dw_wdt驱动设备节点是/dev/watchdog。这个看门狗一旦启动系统就必须周期性去“喂狗”否则硬件强制复位。2.1 devicetree 里开启硬件看门狗很多 RK3588 开发板出厂默认 watchdog 是 disabled 的因为默认固件不启用喂狗服务开了不喂会一直重启。所以第一步是在内核 devicetree 里把它打开。以 RK3588 的 dtsi 节点为例wdt { status okay; timeout-sec 16; };timeout-sec我建议设置在 10~16 秒之间。太短了系统高负载时喂狗线程本身被调度延迟容易误触发重启太长了真死机时要等半天才复位业务中断时间太长。16 秒是我测试下来比较稳的值。然后是 Linux 内核配置需要确保这几个 config 打开了CONFIG_WATCHDOGy CONFIG_DW_WATCHDOGy CONFIG_WATCHDOG_COREy如果用的是 Rockchip 的 SDK默认一般都有。但如果你是自己 build 的 mainline 内核务必检查一下缺了这两个 config后面的所有看门狗配置都是白搭。2.2 systemd 软件看门狗怎么配合硬件看门狗只是最后一道保险正常运行时我们更希望用 systemd 的软硬结合机制来提前发现异常。systemd 本身内置了 watchdog 支持可以让 PID 1 周期性去喂硬件看门狗。只要 systemd 还活着系统就被认为是健康的。配置在/etc/systemd/system.confRuntimeWatchdogSec10 ShutdownWatchdogSec60RuntimeWatchdogSec10的意思是 systemd 每 10 秒向/dev/watchdog喂一次狗。这个值必须小于 devicetree 里的timeout-sec16 秒否则喂狗间隔比硬件超时还长系统会被误杀。ShutdownWatchdogSec60是关机和重启阶段给系统更多时间去卸载文件系统、停服务避免关个机还被看门狗打断。配置完重启 systemd 或者整机重启后可以用下面命令确认喂狗生效cat /dev/watchdog正常情况下这条命令会打开设备节点并触发一次喂狗然后会报错退出这反而说明驱动正常。更靠谱的验证方式是watch -n 1 cat /sys/devices/platform/watchdog/watchdog0/state也可以直接禁掉喂狗服务手动观察设备会不会在 16 秒后自动重启。我建议每一批板子出厂前都做一次这个测试确保硬件看门狗是真实可用的而不是 devicetree 里写了“okay”但实际没生效。2.3 看门狗喂狗的正确姿势这里有个关键细节喂狗不是在应用层随便写个死循环就行的必须设计成“健康检查通过才喂”。我见过太多团队写一个while(1) { write(fd, w, 1); sleep(5); }的线程一直喂等于自己把看门狗废了——任何应用层故障都不会触发重启因为你的喂狗线程还活着。我之前在一套方案里做的是分级喂狗喂狗线程每 10 秒读取一次系统健康状态关键进程是否存活、内存是否够用、最近的 dmesg 里有没有驱动报错。只有所有检查项都通过才写入/dev/watchdog。任一检查项失败停止喂狗等硬件看门狗超时自动复位。伪代码大致长这样import fcntl import os import time WATCHDOG_FD os.open(/dev/watchdog, os.O_WRONLY) def system_healthy(): # 1. 关键进程存活检查 if not check_process(rknn_infer): return False # 2. 内存检查可用内存低于 200MB 判定为异常 if available_memory_mb() 200: return False # 3. 最近 60 秒 dmesg 是否出现连续驱动错误 if recent_dmesg_has_errors(): return False return True while True: if system_healthy(): os.write(WATCHDOG_FD, bw) time.sleep(10)注意这里我刻意把这个喂狗逻辑做成了独立进程而不是放在主业务进程里。为什么因为主业务进程是最容易卡死的如果喂狗逻辑跟着它跑卡死就一起卡死守护就失去了意义。用 systemd 把喂狗进程拉起来加Restartalways即便这个进程本身崩了systemd 也会把它重新拉起来继续喂——当然如果 systemd 都崩了还有硬件层兜底这是双保险。3. 应用层守护与 RKNN 推理异常自恢复看门狗解决的是“系统级死机”但实际项目里更常见的是“应用级卡死”。系统没死SSH 能连top 能看到进程还在但 NPU 推理线程卡住不动了画面一直停在那。这种问题靠看门狗是发现不了的必须靠应用层自己的健康检查机制。3.1 进程守护与心跳我在方案里给每一个关键业务进程都配了 systemd service统一加了Restartalways和健康检查。以推理服务为例[Unit] DescriptionRKNN Inference Service Afternetwork-online.target rknn.service [Service] Typesimple ExecStart/usr/bin/rknn_infer --config /etc/guardian/rknn_infer.yaml Restartalways RestartSec5 WatchdogSec30 StartLimitIntervalSec60 StartLimitBurst5 [Install] WantedBymulti-user.targetRestartalways保证进程退出后 5 秒内被拉起来。但光这样不够因为前面说的“卡死”不是进程退出而是进程还活着但无响应。所以这里又用了WatchdogSec30——systemd 会要求服务每 30 秒调用一次sd_notify(WATCHDOG)如果超时systemd 会认为这个服务已经“僵死”杀掉并重新拉起。服务内部需要周期性地维护看门狗通知。C 里用sd_notifyPython 里用systemd库或者直接往/run/systemd/notify写消息import socket import time NOTIFY_SOCKET_PATH /run/systemd/notify def notify(): sock socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) sock.connect(NOTIFY_SOCKET_PATH) sock.send(bWATCHDOG1) sock.close() while True: # 执行一帧推理 result rknn_run() if result is not None: notify() time.sleep(1)这个机制的意义在于只要推理主循环还能跑完一帧我们才认为服务健康如果一帧推理超过 30 秒没完成即使进程还在systemd 也直接把它干掉重来。实测下来这套机制对“NPU 卡死但进程还活着”的场景特别有效。3.2 RKNN 运行时的超时检测与自动重初始化RKNN 的rknn_run默认是同步阻塞调用的如果 NPU 内部出现了异常这个调用可能永远不返回。你写再多的心跳代码也走不到心跳那里。所以我在封装 RKNN 推理时会把推理放到独立线程里用带超时的 join 去检测一旦超时就认为 NPU 已卡死进入恢复流程std::futurecv::Mat future std::async(std::launch::async, [this] { return infer(frame); // 内部调用 rknn_run }); if (future.wait_for(std::chrono::seconds(5)) std::future_status::timeout) { // 推理超时判定 NPU 卡死 recover_from_npu_hang(); return; } cv::Mat result future.get();恢复流程recover_from_npu_hang()做几件事先把旧的推理进程退出调用rknn_destroy释放 NPU 上下文如果还能调用的话实在不行就直接exit(0)让 systemd 重启整个服务。然后把/dev/rknpu设备节点重新 bind/unbind 一次把 NPU 驱动复位echo 0 /sys/class/misc/rknpu/device/remove echo 1 /sys/class/misc/rknpu/device/remove注意/dev/rknpu设备节点的路径在不同 SDK 版本里可能不一样有的叫rknpu有的叫mpp_service需要先确认一下你们板子的实际情况。复位 NPU 驱动后再重新rknn_init加载模型继续推理。这个过程最好能自动完成不需要重启整机恢复正常的时间控制在 10 秒以内业务中断的感知就很小了。3.3 进程崩溃后的现场保留进程崩溃后第一件事不是急着拉起来而是把现场保护好。我只说一个点coredump 一定要开但要写到内存盘上不能写 eMMC。否则每次崩溃都往 eMMC 写几百 MB core 文件写几次 eMMC 就废了。我的做法是# /etc/systemd/coredump.conf [Coredump] Storageexternal Compressyes # 把 coredump 临时保存到 /tmptmpfs重启后自动清空配合挂载一个 tmpfs 到/var/log/coredumptmpfs /var/log/coredump tmpfs defaults,size256m,mode0755 0 0这样崩溃时 core 文件先落内存盘不影响 eMMC如果现场非常重要再通过网络把 core 传到远端。很多团队的设备一到现场就频繁崩溃但 Log 里什么都没有就是因为 coredump 没开或者开了直接写坏存储。4. 散热与供电防止“慢性死亡”讲完了看门狗和应用层守护可能有人觉得够了。但我的经验是真正的“不死机”有一半功夫要花在散热和供电上。白天 NPU 满载还好到了满载几个小时后如果没有合理的温控策略RK3588 会热到降频甚至直接高温关机。这种问题不是突发性的而是“温水煮青蛙”——系统越来越慢最后悄悄死给你看。4.1 PWM 风扇控制与转速读取RK3588 开发板一般都有 PWM 风扇接口内核驱动是pwm-fan。我在设备树里是这样配的pwm13 { status okay; pinctrl-names active; pinctrl-0 pwm13m1_pins; }; fan: pwm-fan { compatible pwm-fan; #cooling-cells 2; pwms pwm13 0 50000 0; /* 50kHz 频率 */ cooling-min-state 0; cooling-max-state 255; };这里的核心参数是pwms里的 period也就是 PWM 频率。不同风扇对频率的要求不同但我测过的大部分 4 线 12V 风扇在 25kHz~50kHz 之间都能正常工作。太低的频率比如 1kHz会有明显噪音太高的频率100kHz 以上风扇驱动芯片可能跟不上。然后是读取风扇转速。很多 4 线风扇的转速反馈引脚FG可以直接接 RK3588 的 GPIO用pwm-capture或者 GPIO 中断的方式测量。但我更推荐用hwmon的方式RK3588 的 SDK 里通常已经支持了风扇转速的 hwmon 节点cat /sys/class/hwmon/hwmon0/fan1_input如果输出一个 RPM 数值说明测速功能正常。如果没有这个节点就需要检查一下风扇的 FG 引脚是否接到了正确的 GPIO 上以及内核有没有开CONFIG_SENSORS_PWM_FAN或者你们需要的gpio-fan驱动。转速读取的价值不只是让你知道风扇转没转更关键的是可以做风扇失效检测。当 PWM 输出已经 100% 但转速始终为 0说明风扇卡住了或者掉线了必须立即告警否则芯片温度会直线飙升。4.2 温控策略别让芯片扛到最后RK3588 芯片的结温上限一般是 105℃ 左右但长期跑在 85℃ 以上不仅加速器件老化还有可能触发内部热保护直接断电。我的温控策略是在用户空间写一个守护线程直接读 SoC 温度做分级控制import os import time def read_temp(): with open(/sys/class/thermal/thermal_zone0/temp) as f: return int(f.read().strip()) / 1000.0 def set_fan_duty(duty): # 通过 pwm-fan 的 cooling device 或者 sysfs 设置占空比 with open(/sys/class/hwmon/hwmon0/pwm1, w) as f: f.write(str(duty)) while True: temp read_temp() if temp 45: set_fan_duty(0) # 停转安静省电 elif temp 60: set_fan_duty(80) # 低转速 elif temp 75: set_fan_duty(160) # 中转速 else: set_fan_duty(255) # 全速压温度 time.sleep(5)阈值可以根据实际机型微调但思路是留出冗余在 75℃ 就已经全速散热不要等到 90℃ 才慌。另外如果你的设备是静音优先的场景可以考虑把 45℃ 这个停转阈值调高到 50℃但一定要配合风扇失效检测否则夏天必出事。还有一点RK3588 有thermal-zones的被动降频策略建议在 devicetree 里打开让内核在温度过高时主动给 CPU/GPU 降频而不是硬扛thermal_zones { soc_thermal { trips { cpu_cooling: cpu_cooling { temperature 75000; hysteresis 5000; type passive; }; }; cooling-maps { map0 { trip cpu_cooling; cooling-device cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT; }; }; }; };4.3 供电与硬件防护软件做再好供电不行全白搭。RK3588 在满负载时核心电压对电源纹波极其敏感我碰到过一个案例设备白天跑得好好的一到晚上就随机重启查了半天最后发现是客户配的劣质 DC 适配器纹波超标电压一波动芯片就复位。所以硬件选型上电源部分至少要满足三个要求输入电压要留足余量标称 12V 供电实际要能扛住 9V~16V 的波动。很多开发板用的 DC-DC 方案输入范围就是 9~24V但有些精简方案只在 12V 附近能稳住。输出纹波要小CPU 核心供电VDD_CPU的纹波最好控制在 50mV 以内否则高频负载变化时系统会随机复位。要有过压/反接保护乡村、工控现场的市电环境很差插错电源是常事硬防护必须做。如果成本允许建议加一个简单的电源监控芯片比如 INA226在应用层定期读电压电流一旦发现输入电压异常波动就主动告警把问题暴露在“死机之前”。5. 存储保护与日志策略延长 eMMC 寿命防止日志写爆很多 RK3588 设备出厂配的是 eMMCTLC 颗粒擦写寿命大概在 3000~5000 次 P/E 之间。如果系统跑一些频繁写日志的软件每天写几十 GBeMMC 很快就废了然后就是各种诡异故障文件系统只读、应用启动报错、系统随机重启。这些都是慢性病等到你发现的时候往往只能返厂换板了。5.1 根文件系统只读化能读就不写我的设计原则是能只读的绝对不读写。根文件系统挂载为只读/var、/tmp、/run这些动态目录挂到 tmpfs所有需要持久化的数据集中到/data分区。具体做法是把根文件系统做成 squashfs 或者 ext4 只读分区然后用 overlayfs 提供一个小规模的可写层mount -t squashfs -o loop /dev/mtdblock0 /mnt/ro # 或者 ext4 ro mount -t tmpfs tmpfs /mnt/rw mount -t overlay overlay -o lowerdir/mnt/ro,upperdir/mnt/rw/upper,workdir/mnt/rw/work /这样程序只能往内存里写重启后所有修改自动丢弃从源头上杜绝了“日志写满磁盘”的可能。需要持久化的配置和数据明确写到/data分区并且做好掉电保护。这个方案唯一的副作用是现场临时改配置变得有点麻烦。但换个角度想这也倒逼你把配置项通过 web 界面或者远程统一管理而不是每次都用 SSH 上去 vi 一通改。5.2 日志轮转与内存缓冲如果因为业务原因必须写日志到磁盘至少做到两点限制大小、及时轮转。我通常用logrotatesystemd-journald配合journald 本身已经有大小限制功能# /etc/systemd/journald.conf SystemMaxUse128M RuntimeMaxUse32M SystemMaxFileSize32M MaxRetentionSec3day ForwardToSyslogno这个配置把 journald 的总量控制在 128MB 以内避免它无限膨胀。业务日志如果走syslog或者直接写文件也要在应用层做好 max size 控制超过就滚动。还有一个很实用的做法日志先写内存盘定期同步到远端。把/var/log挂成 tmpfs应用和方法和之前的 coredump 一样。然后写一个脚本每 5 分钟检查一次日志目录有需要归档的内容就通过 MQTT 或者 HTTP 上报到运维平台上报完把这个文件删掉。这样日志既不会丢远端有也不会伤 eMMC。5.3 异常掉电防护工业现场最怕的其实是“写一半断电”。文件系统层最稳妥的方案还是 ext4 开 journaltune2fs -O journal_data_ordered /dev/mmcblk0p6如果用的是 overlayfs 的可写层tmpfs断电其实无所谓内存直接清空。但data分区如果直写 ext4掉电后有可能损坏。所以我建议 data 分区采用“先写临时文件fsync再 rename 覆盖”的方式保存配置避免原地修改主文件时掉电导致文件损坏FILE *tmp fopen(/data/config.yaml.tmp, w); fprintf(tmp, key: value\n); fclose(tmp); sync(); rename(/data/config.yaml.tmp, /data/config.yaml); sync();这算是嵌入式 Linux 上最实用、最可靠的掉电安全写文件方式了简单但极其有效。6. 常见问题排查与避坑速查看完前面的内容按部就班把这些机制搭起来设备大概率已经比较稳了。但调试过程中一定会踩到各种奇奇怪怪的坑。我把常见的几个写下来省得大家再走一遍弯路。6.1 开机报 “cant find suitable delayline” 是什么问题这个错误在 RK3588 上很常见很多人一搜出来就慌了以为板子坏了。其实这是 RK3588 的rockchip_drm驱动在初始化时尝试去查找某个显示接口的 delayline 校准参数失败。多数情况下是 devicetree 里没有包含对应的board.dtsi参数或者是显示时序配置里缺了delayline相关字段。如果设备不接显示屏、不跑 HDMI这些报错通常不影响正常运行可以直接忽略。但如果你的设备需要 HDMI 输出就要去 devicetree 里补齐对应端口的参数hdmi0_in_vp0 { status okay; }; hdmi0 { pinctrl-names default; pinctrl-0 hdmim0_tx0_cec hdmim0_tx0_sda hdmim0_tx0_scl; };注意不同开发板的 pinmux 可能不同这个要根据你的板子原理图来确认。遇到这类问题我的建议是先确认功能是否受影响不受影响就不用管。6.2 网络连接受限 / 网络假死RK3588 设备跑着跑着 SSH 连不上了、Ping 不通但设备的串口界面还有响应这是边缘设备最常见的“假死”现象。排查思路按顺序来先看dmesg里有没有网卡驱动报错比如 RTL8211F 这种 PHY 芯片在弱电环境下偶尔会挂掉。检查是不是省电策略把网卡休眠了。很多 SDK 默认开了ethtool的节能特性现场环境下网络稍有波动就触发网卡挂起。直接关掉ethtool -s eth0 autoneg on duplex full speed 1000 ethtool -K eth0 tx-checksum-ip-generic off如果还是不定期断网建议在应用层加网络质量巡检每 30 秒 Ping 一次网关连续 3 次超时就把网卡 down 掉再 up 一遍。ifconfig eth0 down sleep 2 ifconfig eth0 up这个土办法治“网卡假死”特别有用实际效果立竿见影。6.3 启动进 recovery / maskrom 后怎么办RK3588 的刷机模式有两种Recovery 模式和 MaskROM 模式。Recovery 模式按住 recovery 键再上电用于日常固件升级MaskROM 模式一般出现在 loader 损坏、固件刷坏的情况下。如果你的设备启动进不了系统而是被识别为 MaskROM 设备别慌先用 USB Type-C 线连电脑打开 RKDevTool重新烧录完整的 Loader 和固件。从我踩过的坑来看最容易导致进 MaskROM 的情况是烧录过程中突然断电、或者用了和板子不匹配的 Loader/miniloader。所以我强烈建议量产前把 loader 文件和固件打包锁定不要让现场人员随意用新版工具去刷否则很容易出现兼容性问题。6.4 miniloader.bin 版本不匹配如果你用的是自己编译的 U-Boot 或者从网上拉的新版工具链烧录时经常遇到miniloader.bin报错或者烧完起不来。原因通常是 SDK 版本和烧录工具版本不匹配。处理办法很简单——用什么 SDK 编出来的 loader就用那个 SDK 配套的烧录工具不要交叉使用。Rockchip 官方的工具版本很多但每个版本的 miniloader 和 ddrbin 都跟具体芯片和系统版本强相关混用很容易翻车。6.5 问题排查速查表现象可能原因优先排查方向运行几小时后整机无响应内存泄漏 / 内核锁死检查OOM日志、dmesg尾部、top内存占用NPU 推理越跑越慢散热不足导致降频查看thermal_zone0温度、风扇转速断电后起不来eMMC 分区损坏进入 MaskROM 重刷固件风扇不转但机器没死风扇控制失效 / 温控策略未生效手动写pwm1测试日志刷屏导致系统卡顿驱动反复报错检查dmesg关掉或降级出问题的外设驱动WiFi/以太网频繁断开省电策略 / 供电不足关节能ethtool -K、检查电源功率这套表是我整理给自己团队线上排障用的基本可以覆盖现场 90% 的难题。做边缘 AI 设备拼的从来不是谁算法刷榜高而是谁能让设备在无人看守的角落里安安稳稳跑上一年。RK3588 本身底子很好用好了它能成为非常可靠的边缘算力平台希望这些经验能帮你少走一些弯路。最后再啰嗦一句任何守护机制都要先做故障注入测试——手动 kill 进程、拔掉风扇、断电、写满内存——确认设备都能自愈才算真正的“守护”。祝大家的设备都能安稳运行。