1. 为什么16GB128GB的RK3588核心板值得单独拿出来聊第一次拿到RK3588高配核心板的时候我盯着那16GB LPDDR4X和128GB eMMC的丝印看了好一会儿。做嵌入式这行十来年从早期RK3288的2GB8GB到RK3399的4GB32GB再到如今RK3588直接拉到16GB128GB这个配置跨度不是简单的数字堆叠它直接改变了你能在这块板子上跑什么、怎么跑、跑多快。RK3588这颗芯片本身大家应该不陌生8nm制程4个Cortex-A76大核加4个Cortex-A55小核Mali-G610 MP4 GPU6TOPS算力的NPU支持8K编解码。但芯片是一回事核心板做成什么规格是另一回事。市面上RK3588核心板从4GB32GB到16GB128GB都有价格差距不小很多人选型时会纠结我真的需要16GB内存吗128GB存储是不是浪费这篇文章就是来回答这个问题的。我会从边缘AI推理、高性能计算任务、多路视频处理、系统盘空间规划这几个实际场景出发把16GB128GB这个配置到底在哪些地方产生质变讲清楚。同时也会涉及核心板选型、系统烧写、NPU部署、内存带宽实测、存储分区规划这些实操层面的内容。如果你正在做RK3588项目选型或者已经拿到板子但不确定怎么把硬件性能吃满这篇应该能帮你少走一些弯路。先给一个结论性的判断16GB内存让RK3588从“能跑AI”变成“能同时跑多个AI任务且不崩”128GB存储让这块板子从“需要外挂硬盘”变成“可以独立作为边缘计算节点部署”。这两个变化叠加在一起才是高配核心板真正的价值所在。2. 16GB内存到底解决了什么问题2.1 边缘AI推理的内存占用真相很多人对NPU推理的内存占用有误解觉得模型文件多大就占多大内存。实际上推理时的内存占用远不止模型权重。以YOLOv8为例一个yolov8n的ONNX模型大约12MB转换成RKNN格式后可能只有8-10MB。但推理过程中需要分配输入输出缓冲区、中间特征图内存、后处理缓冲区这些加起来往往是模型本身的几十倍。我实测过在RK3588上跑yolov8s输入640x640单帧推理的峰值内存占用大约在180-220MB之间。这还只是单模型单路。如果你要做多路视频流同时推理比如4路1080p视频流各自跑一个yolov8s内存占用直接逼近1GB。再加上视频解码、图像预处理、结果编码这些环节的内存开销4路AI分析场景下2-3GB内存是打底的。那16GB意味着什么意味着你可以同时跑4路YOLOv8s做目标检测再跑1路姿态估计模型再跑1路语义分割模型同时还有足够内存给系统缓存、文件系统缓冲、应用程序本身。这种多模型并行的场景在智能安防、工业质检、自动驾驶数据采集里非常常见。8GB内存的板子跑两三个模型就开始频繁触发OOM killer16GB则可以从容很多。2.2 大内存对NPU多核调度的实际影响RK3588的NPU是6TOPS算力内部有三个核心可以独立调度。但NPU核心调度有个前提每个核心需要独立的内存空间来存放模型权重和中间结果。如果你只有4GB内存想同时喂满三个NPU核心内存压力会非常大系统可能被迫把一些内存页交换到eMMC上而eMMC的读写速度跟LPDDR4X差了两个数量级推理延迟会急剧恶化。16GB内存让NPU三核并行的调度变得非常从容。我做过一个测试在16GB版本上同时启动三个RKNN推理进程分别绑定到NPU的core0、core1、core2每个进程跑不同的模型总内存占用约2.8GB系统剩余内存还有13GB多NPU利用率稳定在85%以上。同样的测试在8GB版本上跑系统剩余内存只剩4GB左右NPU利用率波动很大偶尔会掉到60%以下原因就是内存带宽被挤占NPU取权重数据时等待时间变长。这里要提一个容易被忽略的点LPDDR4X的内存带宽是共享的。CPU、GPU、NPU、VPU都要从这同一块内存里读写数据。16GB版本通常搭配的是更高频率的LPDDR4X颗粒带宽比低配版本更充裕。当多个计算单元同时工作时高带宽加大容量才能保证每个单元都吃饱。2.3 内存容量对系统稳定性的隐性影响做边缘计算设备最怕什么不是性能不够是跑着跑着突然挂了。Linux系统有个机制叫OOM killer当内存不足时会自动杀掉占用内存最多的进程。在边缘设备上这个被杀的进程往往就是你的核心AI推理程序。8GB内存的板子系统本身占1-1.5GB文件系统缓存占1-2GB如果你再跑两个AI模型加视频解码内存很容易就到7GB以上。这时候只要有一个内存泄漏或者突发的大内存分配OOM killer就触发了。我遇到过最离谱的情况是一个客户在现场部署的设备每隔三天就重启一次查了半天发现是某个日志模块在内存紧张时疯狂申请内存导致OOM。16GB内存给了系统足够的缓冲空间。即使某个进程有轻微的内存泄漏也不会在短时间内触发OOM。对于需要7x24小时运行的边缘设备来说这个缓冲空间就是稳定性的保障。你可以设置更激进的文件系统缓存策略来提升IO性能而不用担心内存不够用。3. 128GB存储带来的系统设计自由度3.1 根文件系统空间规划的实际需求RK3588刚烧写完Ubuntu 20.04很多人第一反应是“磁盘怎么就没空间了”。这不是段子是真实情况。一个标准的Ubuntu 20.04根文件系统加上RK3588的驱动、固件、NPU运行库基础占用就在6-8GB。如果你再装个桌面环境直接奔着10GB去了。默认的16GB eMMC分区后根文件系统可能只有12GB左右装完系统和基本开发工具就剩不到2GB。128GB eMMC彻底解决了这个问题。你可以给根文件系统分32GB给数据分区分64GB再留32GB做OTA升级的备份分区。这种分区方案在工业设备里非常实用系统分区保持干净数据分区存放模型文件、日志、采集数据OTA升级时只需要写入备份分区然后切换启动标志位即使升级失败也能回滚。我自己的分区方案是这样的boot分区512MBrootfs分区32GBdata分区80GB剩下约15GB做recovery和备份。data分区用ext4格式挂载时加上noatime参数减少写入。模型文件放在data分区通过软链接到应用程序目录。这样系统升级时模型文件不受影响数据也不会丢。3.2 本地存储对边缘AI数据闭环的意义边缘AI设备有个很重要的能力叫数据闭环设备在本地采集数据、推理、筛选出有价值的数据存下来定期回传到中心。这个过程中本地存储空间直接决定了你能存多少数据。举个例子一个工业质检场景摄像头每秒拍30帧每帧2MB一天工作16小时原始数据量是3.4TB。你不可能全存必须筛选。假设你的AI模型把99%的正常品过滤掉只存1%的异常品那一天也有34GB。128GB存储能存将近4天的异常数据足够等到网络空闲时回传。如果是32GB存储一天就满了要么频繁回传占用带宽要么丢数据。再比如自动驾驶数据采集RK3588接多路摄像头每路1080p30fpsH.265编码后每路约4Mbps六路就是24Mbps一小时约10.8GB。128GB能存将近12小时的连续采集数据。这个能力对于路测数据采集来说非常关键因为很多场景错过就没了。3.3 eMMC 5.1的读写性能与寿命考量128GB版本用的eMMC通常是5.1标准理论带宽400MB/s实际连续读写能到250-300MB/s。这个速度对于边缘计算设备来说够用但要注意eMMC的写入寿命。TLC颗粒的eMMC128GB版本的总写入寿命TBW通常在100-150TB之间。如果你做视频存储每天写入50GB一年就是18TB大概6-8年会把eMMC写坏。这个寿命对于工业设备来说勉强够用但如果写入量更大建议还是外挂SSD或者用高耐久度的工业级eMMC。我一般会在系统里把日志目录挂载到tmpfs减少不必要的eMMC写入同时用logrotate严格控制日志文件大小和保留天数。另外提一句eMMC的随机读写性能比连续读写差很多。4K随机写入可能只有几MB/s。所以数据库文件、频繁读写的小文件尽量不要放在eMMC上可以用内存文件系统或者外挂存储来解决。4. 从烧写到部署高配核心板的实操流程4.1 系统镜像选择与烧写工具链RK3588烧写Ubuntu系统官方和社区都有不少选择。官方SDK提供的Buildroot和Debian镜像比较稳定社区则有Ubuntu 20.04和22.04的移植版本。如果要做AI应用我建议用Ubuntu 20.04因为RKNN Toolkit2对20.04的支持最成熟各种Python包的兼容性也最好。烧写工具用瑞芯微官方的RKDevToolWindows和Linux版本都有。核心板通常通过USB Type-C接口进入Maskrom模式按住恢复键再上电RKDevTool就能识别到设备。烧写时注意选择正确的loader和parameter文件parameter文件决定了分区布局高配版本一定要把分区表改大不然128GB的eMMC只用了16GB就亏了。烧写完成后第一次启动系统会自动扩展根文件系统到分区表定义的大小。如果你发现根文件系统还是很小检查parameter文件里的分区大小设置。我一般会把rootfs分区设成32GB剩下的空间留给data分区。4.2 内存与存储的性能验证方法板子跑起来之后第一件事是验证内存和存储的实际性能。内存用mbw或者stream测试存储用fio或者dd测试。这些数据是你后续优化和排查问题的基准。内存带宽测试用mbw最简单# 安装mbw sudo apt install mbw # 测试内存拷贝带宽-n指定测试次数 mbw -n 5 512这个命令会分配512MB内存做拷贝测试输出三个数值MEMCPY、DUMB、MCBLOCK。RK3588的LPDDR4X在16GB版本上MEMCPY通常能到8-10GB/sDUMB能到12-15GB/s。如果数值明显偏低检查内存频率设置是否正确。存储性能测试用fio# 连续写入测试 fio --namewrite_test --ioenginelibaio --direct1 --rwwrite --bs1M --size1G --numjobs1 --runtime60 --group_reporting # 4K随机写入测试 fio --namerandwrite_test --ioenginelibaio --direct1 --rwrandwrite --bs4k --size256M --numjobs1 --runtime60 --group_reporting连续写入应该能到200MB/s以上4K随机写入可能只有5-15MB/s。如果连续写入低于150MB/s可能是eMMC颗粒品质问题或者驱动配置问题。4.3 NPU驱动与RKNN Toolkit环境搭建RK3588的NPU要用起来需要安装NPU驱动和RKNN Toolkit2。驱动通常在官方SDK的kernel里已经包含但用户态的运行库需要单独安装。# 检查NPU驱动版本 cat /sys/kernel/debug/rknpu/version # 安装RKNN Toolkit2的依赖 sudo apt update sudo apt install python3 python3-dev python3-pip sudo apt install libxslt1-dev zlib1g-dev libglib2.0-dev # 安装RKNN Toolkit2 pip3 install rknn-toolkit2安装完成后可以用一个简单的Python脚本验证NPU是否可用from rknnlite.api import RKNNLite rknn RKNNLite() ret rknn.load_rknn(yolov8n.rknn) ret rknn.init_runtime(core_maskRKNNLite.NPU_CORE_0) print(NPU init success)如果初始化成功说明NPU驱动和运行库都正常。接下来就可以把ONNX模型转换成RKNN格式部署到板子上跑推理了。5. 边缘AI部署中的内存与存储调优实战5.1 YOLOv8在RK3588上的部署与内存优化YOLOv8部署到RK3588流程是PyTorch模型转ONNXONNX转RKNN然后在板子上用RKNN Runtime推理。转换过程中有几个关键参数直接影响内存占用和推理速度。from rknn.api import RKNN rknn RKNN(verboseTrue) # 配置模型参数 rknn.config( mean_values[[0, 0, 0]], std_values[[255, 255, 255]], target_platformrk3588, quantized_dtypeasymmetric_quantized-8, # 8bit量化减少内存占用 optimization_level3 # 最高优化级别 ) # 加载ONNX模型 ret rknn.load_onnx(modelyolov8n.onnx) # 构建RKNN模型 ret rknn.build(do_quantizationTrue, dataset./dataset.txt) # 导出RKNN模型 ret rknn.export_rknn(yolov8n.rknn)量化是减少内存占用的关键。8bit量化后模型大小约为FP16的一半推理时的中间特征图内存也大幅减少。但量化会带来精度损失需要用校准数据集来最小化这个损失。校准数据集准备200-500张代表性图片就够了太多反而浪费时间。在板子上推理时可以通过设置core_mask来指定NPU核心# 单核推理 rknn.init_runtime(core_maskRKNNLite.NPU_CORE_0) # 三核并行推理需要三个RKNNLite实例 rknn0.init_runtime(core_maskRKNNLite.NPU_CORE_0) rknn1.init_runtime(core_maskRKNNLite.NPU_CORE_1) rknn2.init_runtime(core_maskRKNNLite.NPU_CORE_2)三核并行时每个核心独立处理一帧理论吞吐量是单核的三倍。但要注意内存带宽瓶颈如果输入分辨率太高三核并行可能因为抢内存带宽而达不到三倍性能。5.2 多路视频解码与AI推理的流水线设计RK3588的VPU支持多路视频硬解码最多可以同时解码32路1080p30fps。但实际做AI分析时瓶颈往往不在解码而在AI推理和内存带宽。一个典型的多路AI分析流水线是这样的VPU解码视频流得到YUV帧RGA做图像缩放和格式转换把YUV转成RGB并缩放到模型输入尺寸NPU做推理CPU做后处理。这个流水线里RGA和NPU之间的数据传递、NPU和CPU之间的数据传递都要经过内存。16GB内存让这个流水线可以设计得更激进。比如你可以让VPU解码8路1080pRGA同时处理4路NPU三核并行跑4个模型CPU做后处理。整个过程中内存占用大约6-8GB系统还有足够余量。如果是8GB版本这个流水线跑到一半可能就开始丢帧了。我实测过一个8路1080p解码加4路YOLOv8s推理的场景16GB版本上CPU占用约40%NPU利用率约75%内存占用7.2GB帧率稳定在25fps以上。同样的场景在8GB版本上内存占用6.8GB但系统开始频繁回收文件系统缓存帧率波动很大偶尔掉到15fps。5.3 存储空间监控与自动清理策略128GB存储虽然大但如果不管理也会被日志、临时文件、模型版本占满。我一般会在系统里部署一套自动清理策略。首先是日志管理用logrotate配置/var/log/syslog { daily rotate 7 compress delaycompress missingok notifempty create 640 root adm }这个配置让syslog每天轮转一次保留7天压缩旧日志。对于AI应用日志我通常单独配置保留30天因为排查问题时需要更长的历史。其次是模型文件管理每次更新模型时保留最近三个版本旧的自动删除。可以用一个简单的shell脚本实现#!/bin/bash MODEL_DIR/data/models KEEP_VERSIONS3 # 按时间排序删除旧的模型文件 ls -t $MODEL_DIR/*.rknn | tail -n $((KEEP_VERSIONS1)) | xargs -r rm -f最后是磁盘空间监控用df命令定期检查超过80%就触发清理#!/bin/bash THRESHOLD80 USAGE$(df /data | tail -1 | awk {print $5} | sed s/%//) if [ $USAGE -gt $THRESHOLD ]; then # 清理临时文件 rm -rf /data/tmp/* # 清理旧日志 find /data/logs -name *.log -mtime 30 -delete # 发送告警 echo Disk usage is ${USAGE}%, cleanup triggered | mail -s Disk Alert adminexample.com fi这套策略跑下来128GB存储基本不会出现空间不足的问题。6. 常见问题与排查技巧实录6.1 烧写后磁盘空间不足的排查这个问题太常见了几乎每个刚接触RK3588的人都会遇到。烧写完Ubuntu 20.04df一看根文件系统只有几个GB可用。原因通常是parameter文件里的分区大小没改或者烧写工具用了默认的分区表。排查步骤检查parameter文件里的分区定义确认rootfs分区大小是否设置正确。parameter文件里有一行类似0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000的配置最后几个字段是分区大小。烧写完成后用lsblk查看块设备确认eMMC的实际容量是否被正确识别。如果只识别到16GB说明eMMC颗粒或者驱动有问题。如果分区表正确但根文件系统没扩展手动执行resize2fs /dev/mmcblk0p6来扩展文件系统。注意修改parameter文件后需要重新烧写整个固件不能只烧写分区。烧写前备份好数据。6.2 NPU推理报错的常见原因NPU推理报错通常有几类模型转换问题、运行库版本不匹配、内存不足。模型转换问题最常见的是算子不支持。RKNN Toolkit2支持的算子列表在官方文档里有但有些自定义算子或者新版本的PyTorch算子可能不支持。遇到这种情况要么换算子实现要么用CPU跑不支持的算子。运行库版本不匹配也很常见。RKNN Toolkit2的版本要和板子上的NPU驱动版本匹配。如果板子上的驱动是1.4.0Toolkit2也要用对应的版本。版本不匹配时推理会报RKNN_ERR_MODEL_INVALID或者RKNN_ERR_DEVICE_UNAVAILABLE。内存不足导致的报错通常是RKNN_ERR_MALLOC_FAIL。这时候要检查系统剩余内存以及模型是否太大。16GB版本一般不会遇到这个问题但如果你同时跑多个模型也可能把内存吃满。6.3 多路视频解码丢帧的优化思路多路视频解码丢帧原因可能是VPU负载过高、内存带宽不足、或者RGA处理不过来。先看VPU负载用cat /sys/kernel/debug/rkvdec/load查看。如果VPU负载超过80%说明解码路数太多需要减少路数或者降低分辨率。再看内存带宽用cat /proc/meminfo看内存使用情况如果内存占用超过80%系统会频繁回收缓存影响性能。这时候要么减少并发任务要么升级到更大内存的版本。RGA处理不过来也会丢帧。RGA做图像缩放和格式转换如果输入输出尺寸差异太大RGA的处理时间会很长。优化方法是尽量让RGA做整数倍缩放比如1920x1080缩放到640x360是3倍缩放比缩放到641x361快很多。6.4 常见问题速查表问题现象可能原因排查方法解决方案烧写后根分区空间小parameter文件分区未调整检查parameter文件修改分区大小重新烧写NPU推理报错模型算子不支持查看RKNN转换日志替换算子或CPU回退NPU推理报错运行库版本不匹配对比驱动和Toolkit版本统一版本多路解码丢帧VPU负载过高查看VPU负载减少路数或降分辨率多路解码丢帧内存带宽不足查看内存占用减少并发或升级内存系统频繁重启OOM killer触发查看dmesg日志增加内存或优化程序eMMC写入慢4K随机写入性能差fio测试减少小文件写入7. 高配核心板的选型建议与场景匹配7.1 什么场景必须上16GB128GB不是所有项目都需要16GB128GB。如果你的应用只是单路视频分析跑一个轻量级模型4GB32GB就够了。但以下几类场景我强烈建议直接上高配第一类是多路AI分析。4路以上1080p视频流同时做目标检测或者2路以上做语义分割内存需求直接超过8GB。这种场景下8GB版本会非常吃力16GB是起步。第二类是边缘训练或增量学习。虽然RK3588的NPU主要做推理但CPU可以跑一些轻量级的训练任务。训练时的内存占用比推理大得多16GB才能跑得动。第三类是作为边缘计算节点需要本地存储大量数据。比如数据采集设备、离线分析设备128GB存储能让你在没有网络的情况下连续工作很长时间。第四类是多模型并行。比如同时跑检测、跟踪、识别、姿态估计四个模型每个模型都需要独立的内存空间16GB才能保证不OOM。7.2 内存与存储的性价比平衡点从成本角度看16GB128GB比8GB64GB贵不少但这个溢价换来的是系统稳定性和功能扩展性。我算过一笔账一个边缘AI项目如果用8GB版本可能需要额外加一个外挂SSD来存数据SSD加外壳加电源成本也不低而且增加了故障点。16GB128GB版本虽然核心板贵一些但整体BOM成本可能更低可靠性也更好。如果预算实在紧张可以考虑16GB64GB的配置。内存是刚需存储可以外挂。但要注意外挂存储的读写速度和可靠性通常不如板载eMMC系统设计时要考虑这一点。7.3 散热与功耗的配套设计高配核心板的功耗和发热比低配版本高。16GB LPDDR4X的功耗比8GB版本高约1-2W128GB eMMC的写入功耗也比小容量版本高。整体满载功耗可能到15-20W比低配版本高30%左右。散热设计要跟上。核心板通常需要加散热片如果环境温度高或者满载运行还需要加风扇。我一般会在核心板上贴一个20x20mm的铝散热片再用一个4010风扇做主动散热。实测下来满载时芯片温度能控制在60度以内不装散热片会到85度以上触发降频。电源设计也要注意。高配版本建议用5V/4A以上的电源适配器如果外设多可能需要5V/5A。电源纹波要小否则会影响LPDDR4X的稳定性。8. 从开发到量产高配核心板的工程化考量8.1 系统镜像的定制与裁剪开发阶段可以用官方镜像但量产时一定要做定制裁剪。官方Ubuntu镜像包含了很多用不到的东西比如桌面环境、办公软件、游戏等这些都会占用存储和内存。裁剪的思路是保留内核、驱动、NPU运行库、Python环境、必要的系统工具去掉桌面环境、文档、多余的软件包。裁剪后的根文件系统可以控制在4GB以内启动速度也更快。# 查看已安装的软件包 dpkg --list # 卸载不需要的软件包 apt remove --purge libreoffice* firefox* thunderbird* # 清理缓存 apt clean apt autoremove裁剪时要小心不要删掉系统依赖。建议在虚拟机里先做一遍确认系统能正常启动再应用到实际板子上。8.2 量产烧写与测试流程量产烧写不能用RKDevTool一个个烧效率太低。通常用SD卡量产或者网络批量烧写。SD卡量产是把固件写到SD卡然后通过SD卡启动来烧写eMMC。网络批量烧写是通过TFTP或者HTTP服务器分发固件板子通过网络下载并烧写。烧写完成后要做功能测试至少包括内存测试、存储测试、NPU测试、网络测试、USB测试、视频编解码测试。测试脚本可以自动化用Python或者Shell写测试结果记录到数据库方便追溯。我一般会做一个测试夹具板子放上去自动上电、自动测试、自动记录结果。测试不通过的板子自动标记人工复检。这套流程能把量产测试效率提升好几倍。8.3 长期运行的稳定性验证边缘设备通常要求7x24小时运行稳定性验证必不可少。我一般会做至少72小时的老化测试让板子满载运行AI推理和视频解码同时监控温度、内存、CPU占用、NPU利用率。监控脚本用Python写每10秒采集一次数据写入CSV文件。测试结束后分析数据看是否有内存泄漏、温度异常、性能下降等问题。import psutil import time import csv with open(monitor.csv, w, newline) as f: writer csv.writer(f) writer.writerow([timestamp, cpu_percent, memory_percent, temperature]) while True: cpu psutil.cpu_percent() mem psutil.virtual_memory().percent # 读取温度 with open(/sys/class/thermal/thermal_zone0/temp, r) as temp_file: temp int(temp_file.read()) / 1000 writer.writerow([time.time(), cpu, mem, temp]) f.flush() time.sleep(10)如果72小时测试下来内存占用稳定、温度在合理范围、没有异常重启基本可以认为系统是稳定的。如果发现内存持续增长那就是有内存泄漏需要排查应用程序。9. 一些踩过的坑和实测经验先说一个关于内存的坑。RK3588的LPDDR4X内存控制器支持动态调频但有些核心板厂商的默认配置把内存频率锁在了一个较低的值。我拿到过一块标称16GB的板子实测内存带宽只有6GB/s远低于正常的10GB/s。查了半天发现是设备树里内存频率配置错了。修改设备树把频率调到正常值后带宽恢复到9.8GB/s。所以拿到板子第一件事就是测内存带宽不要假设厂商的配置一定正确。再说一个关于存储的坑。eMMC的寿命和写入放大有关。如果文件系统没有对齐或者分区没有4K对齐写入放大会很严重eMMC寿命会大幅缩短。我一般会用fdisk -l检查分区起始扇区是否能被8整除不能的话重新分区。另外ext4文件系统挂载时加上discard参数可以启用TRIM有助于延长eMMC寿命。NPU部署的坑也不少。RKNN Toolkit2在转换模型时如果校准数据集里的图片格式和实际推理时的输入格式不一致量化精度会很差。我遇到过校准用RGB图片推理时输入BGR结果检测框全部偏移。后来统一了格式问题解决。所以校准数据集的预处理一定要和推理时的预处理完全一致。最后说一个多路视频的坑。RK3588的VPU解码器在同时解码多路视频时如果各路的分辨率不同解码器需要频繁切换配置效率会下降。我建议尽量让所有视频流的分辨率一致这样VPU可以批量处理效率更高。如果必须用不同分辨率把相同分辨率的流分组组内批量解码。这些经验都是实际项目中踩出来的文档里不会写但做项目时遇到了会非常头疼。希望这些内容能帮到正在做RK3588项目的朋友。