1. 为什么RV1106的系统构建值得单独拿出来聊RV1106这颗芯片这两年在一线出现的频率越来越高尤其是做低功耗视觉终端、电池类IPC、门铃、猫眼、扫码设备这类产品的团队几乎绕不开它。它本质上是瑞芯微面向轻量级AI视觉场景推的一颗SoC单核Cortex-A7加上内置的NPU再配上一颗RISC-V协处理器做低功耗常驻任务封装小、BOM成本压得下来这是它被大量选型的直接原因。但真正上手之后你会发现RV1106的嵌入式Linux系统构建和你在RK3399、RK3568上习惯的那套流程体感完全不一样——它的存储介质通常是SPI NAND或者小容量eMMC内存也紧编译产物动辄几个G烧录镜像又要求分区对齐稍不注意就是编译两小时、启动卡在logo。我前后在RV1106上做过三四个量产项目从最早的SDK默认配置一路踩到能把冷启动压进两秒以内中间关于编译优化和启动优化的坑基本都趟过一遍。这篇东西不是官方文档的复述而是把“从编译到启动”这条链路上真正影响效率的环节拆开讲SDK怎么裁剪、编译怎么并行、镜像怎么瘦身、启动阶段怎么定位耗时、哪些优化是性价比高的、哪些是看着美好实际收益极低的。适合已经拿到RV1106开发板、跑通了官方demo、但觉得构建慢、启动慢、不知道怎么下手的同学也适合正在做嵌入式Linux项目实战、需要把系统体积和启动时间当成硬指标的团队参考。需要先说明一点下面涉及的具体路径、配置项名称不同版本的SDK会有差异我尽量讲清楚“为什么这么改”而不是死记某个文件这样你换SDK版本也能自己推。所有参数和数值都是我在实际项目里测出来的量级不是理论值你的板子和配置不同绝对值会有出入但优化方向和收益比例是通用的。2. 构建流程的整体设计与思路拆解2.1 RV1106系统构建到底包含哪些阶段很多人一说“编译系统”就以为是敲一条make然后等其实RV1106的完整构建链路至少分成五段每一段的耗时和优化空间都不一样。第一段是工具链准备RV1106用的是arm-rockchip830-linux-uclibcgnueabihf这类交叉工具链SDK里通常自带预编译版本但如果你要自己换glibc或者换版本这一步会引入兼容性问题。第二段是uboot编译产出SPL和uboot镜像负责最底层的DDR初始化和引导。第三段是kernel编译包括设备树、驱动、内核模块这是整个构建里最耗时的一块。第四段是rootfs构建用buildroot或者busybox拼出根文件系统再往里塞应用和库。第五段是打包与镜像生成把前面所有产物按分区表拼成一个可烧录的update.img或者分区镜像。这五段里kernel和rootfs占了80%以上的时间uboot通常几十秒就完事。所以优化精力要放在kernel和rootfs上而不是去纠结uboot那点时间。我见过有同学花半天研究怎么让uboot编译快10秒结果kernel那边一个配置没关就多花二十分钟这就是没抓住重点。2.2 为什么RV1106的构建比大芯片更“敏感”RV1106的构建敏感核心原因是它的资源约束和存储介质特性。大芯片的板子往往配大容量eMMC、内存也宽裕编译产物大一点无所谓烧录慢一点也能忍。但RV1106常见的搭配是SPI NAND容量可能就128MB或者256MBrootfs稍微多塞点东西就爆分区而且SPI NAND的写入速度和擦除特性决定了镜像不能太大否则烧录时间成倍增长。另外它的DDR容量通常也小kernel里如果开了太多调试选项启动时内存占用高容易在早期就OOM。这就决定了RV1106的构建思路必须是**“按需裁剪”而不是“全量编译”**。官方SDK默认配置是为了兼容尽可能多的场景所以打开了一堆你可能根本用不到的驱动、文件系统、调试功能。你要做的第一件事不是优化编译命令而是先把这些无关的东西关掉。裁剪带来的收益是双重的编译时间下降镜像体积下降启动时间也跟着下降。这是RV1106上性价比最高的优化没有之一。2.3 编译优化和启动优化的关系这里要纠正一个常见误区很多人把编译优化和启动优化当成两件独立的事其实它们在RV1106上是强耦合的。你编译时关掉的每一个驱动、每一个文件系统、每一个调试选项都会直接反映到启动时间上。比如kernel里关掉一个用不到的USB网卡驱动编译时省几秒启动时省的是驱动probe的时间rootfs里去掉一个用不到的服务编译时省打包时间启动时省的是服务拉起的时间。所以正确的做法是把编译配置当成启动优化的第一手段而不是等系统跑起来了再去用工具分析启动耗时。我一般的流程是先做一轮激进的裁剪把明显用不到的全关掉编译一版测启动然后根据启动日志再针对性关第二轮最后才用工具去抠那些裁剪不掉的耗时点。这样比一上来就上工具分析要高效得多因为工具分析出来的很多耗时点其实你直接关掉对应功能就没了根本不需要优化。3. 核心细节解析与实操要点3.1 工具链选择为什么不要轻易换RV1106 SDK自带的工具链是经过验证的和kernel、uboot的版本是配套的。我强烈建议不要轻易换工具链除非你有明确的理由。换工具链最常见的动机是想用更新的gcc拿到更好的优化但实际收益往往被兼容性问题吃掉。比如你换了高版本gcckernel里某些老代码可能编译报错你得一个个打patch换glibc版本可能导致rootfs里的库和工具链不匹配运行时各种找不到符号。如果你确实需要换我的经验是只换工具链的优化等级不换工具链本身。也就是保持SDK自带的工具链通过CFLAGS调整优化参数。RV1106的Cortex-A7支持到-mcpucortex-a7 -mfpuneon-vfpv4确保这两个参数正确比换工具链带来的收益更实在。另外注意kernel和uboot的编译优化等级不要盲目上-O3-O2在嵌入式场景下通常是体积和性能的最佳平衡点-O3可能让镜像变大反而拖慢启动。3.2 kernel裁剪从menuconfig到defconfig的取舍kernel裁剪是RV1106构建优化的主战场。官方SDK一般会提供一个rv1106_defconfig这个配置是“大而全”的你要做的是基于它做减法。具体怎么减我按优先级列一下。第一优先级是关掉所有用不到的驱动。RV1106常见的应用场景是视觉终端那么声卡、HDMI、大部分USB设备类驱动、蓝牙、WiFi如果你用外挂模组另说、各种传感器驱动如果项目用不到就全关。这里有个技巧不要一个个在menuconfig里找直接看.config里y和m的项对照你的硬件原理图用不到的批量改成# ... is not set。第二优先级是关掉调试和追踪功能。CONFIG_DEBUG_INFO、CONFIG_FTRACE、CONFIG_KPROBES、CONFIG_DEBUG_KERNEL这些量产版本一律关掉。CONFIG_DEBUG_INFO关掉能显著减小kernel体积因为它会往vmlinux里塞大量调试符号。我实测过光关掉DEBUG_INFOkernel镜像能小20%到30%编译时间也能省一截。第三优先级是精简文件系统支持。kernel里支持的文件系统类型只留你实际用的。RV1106上通常用squashfs做只读根、overlayfs做可写层、tmpfs做临时目录那么ext4、f2fs、ntfs、vfat这些如果不用就关掉。每关一个文件系统kernel就少一块代码启动时也少一次初始化。第四优先级是调整内核特性。比如CONFIG_PREEMPT如果你的应用对实时性要求不高用默认的CONFIG_PREEMPT_NONE或者CONFIG_PREEMPT_VOLUNTARY就行CONFIG_PREEMPT会引入额外开销。再比如CONFIG_HZ默认可能是100或者250对于视觉终端100通常够用调高会增加调度开销。3.3 rootfs构建buildroot还是busybox自己拼RV1106的rootfs构建有两条路用buildroot或者用busybox自己拼。buildroot的好处是自动化、依赖管理清晰坏处是它默认会带一堆你可能不需要的包而且buildroot本身的配置也需要裁剪。busybox自己拼的好处是极致精简坏处是依赖要自己处理容易漏库。我的建议是项目初期用buildroot快速跑通量产阶段根据实际情况决定是否换成手工拼。如果buildroot裁剪得当其实也能做到很小。buildroot裁剪的关键是make menuconfig里的Target packages把不需要的包全关掉尤其是那些会自动拉一堆依赖的包比如python、perl、各种网络工具。另外buildroot的BR2_TARGET_ROOTFS_SQUASHFS要打开用squashfs做根文件系统压缩率高读取快。如果你决定手工拼核心是只放运行时真正需要的库和可执行文件。用ldd查每个可执行文件的依赖把依赖库拷进去然后反复在板子上跑缺什么补什么。这个过程比较磨人但最终能拼出一个几十MB甚至更小的rootfs。注意库的版本要和工具链一致否则会出现运行时找不到符号的问题。3.4 并行编译make -j到底开多少make -jN的N怎么定是个老生常谈的问题。理论上N等于CPU核心数但实际要看内存。RV1106的编译通常在x86主机上做如果你的主机是8核16Gmake -j8通常没问题如果是8核8Gmake -j8可能因为内存不够导致编译进程被OOM killer干掉反而更慢。我的经验是N取核心数和内存GB数的较小值比如8核16G取88核8G取64核8G取4。另外kernel编译和rootfs编译可以分开并行。比如你先make -j8 kernel编译的同时在另一个终端make -j4 rootfs只要内存够两者互不干扰。但要注意SDK的顶层Makefile可能有依赖关系直接并行可能出问题稳妥的做法是分步执行而不是一条make -j全包。还有一个容易被忽略的点ccache。如果你要反复编译kernel装个ccache能大幅减少重复编译的时间。配置方法是在工具链的gcc前面加ccache比如export CROSS_COMPILEccache arm-rockchip830-linux-uclibcgnueabihf-。第一次编译会慢一点因为要填充缓存后续改代码再编译命中缓存的部分几乎是瞬间完成。我实测在反复调试驱动阶段ccache能把编译时间砍掉一半以上。4. 实操过程与核心环节实现4.1 环境准备与SDK拉取先确认主机环境。RV1106的SDK编译对主机有要求Ubuntu 18.04或者20.04是比较稳的22.04也能用但可能要装一些老版本的依赖库。必备的包包括build-essential、git、repo、libssl-dev、libncurses-dev、device-tree-compiler、bc、rsync、cpio、python3等。缺哪个装哪个编译报错第一件事就是看是不是缺依赖。SDK拉取一般用repo工具按官方给的manifest来。拉完之后先别急着编译先看一眼目录结构确认kernel、uboot、buildroot、device/rockchip这些目录都在。然后执行一次./build.sh lunch选择板级配置这一步会生成对应的配置文件后续编译都基于这个配置。提示SDK拉取和首次编译建议在SSD上进行机械硬盘上编译kernel会明显更慢因为kernel编译涉及大量小文件读写。4.2 第一轮裁剪从defconfig开始拿到SDK后第一件事是进kernel目录做裁剪。先make ARCHarm rv1106_defconfig生成.config然后make ARCHarm menuconfig进去看。但menuconfig一项项找太慢我的做法是直接编辑.config用搜索的方式批量处理。具体操作先用grep -n y .config列出所有编译进内核的项对照硬件原理图把用不到的驱动标记出来。比如你的板子没有音频codec就搜SND相关的项全改成# CONFIG_XXX is not set。没有USB Host就搜USB相关的项关掉。这个过程要细心关错了会导致启动失败所以建议每关一批就编译一次、启动一次确认没问题再关下一批。裁剪完之后把当前.config保存成自己的defconfig比如make ARCHarm savedefconfig然后把生成的defconfig放到arch/arm/configs/下命名为rv1106_mini_defconfig。以后编译直接用这个不用每次重新裁。4.3 kernel编译参数调优kernel编译时除了-j还有几个参数值得调。第一个是LOCALVERSION如果你不需要在版本号里加后缀把它清空能避免一些不必要的重新编译。第二个是INSTALL_MOD_STRIP编译模块时加上strip能减小模块体积。第三个是KCFLAGS可以在这里追加优化参数比如KCFLAGS-mcpucortex-a7 -mfpuneon-vfpv4确保针对RV1106的CPU特性优化。编译命令我一般这么写make ARCHarm CROSS_COMPILEarm-rockchip830-linux-uclibcgnueabihf- \ rv1106_mini_defconfig make ARCHarm CROSS_COMPILEarm-rockchip830-linux-uclibcgnueabihf- \ KCFLAGS-mcpucortex-a7 -mfpuneon-vfpv4 \ -j8 zImage modules dtbs注意zImage、modules、dtbs分开写这样如果只是改了设备树可以只编dtbs不用全量重编。实测只编dtbs几秒钟就完事全量编kernel要几分钟到十几分钟不等。4.4 rootfs精简与打包rootfs这块如果用buildroot先make menuconfig进Target packages把不需要的包关掉。重点检查这几类网络工具curl、wget、ssh如果不用就关、脚本语言python、perl、lua如果不用就关、图形库如果不用GUI就关、数据库不用就关。每关一个包buildroot会重新计算依赖可能连带关掉一批所以关完要重新make看有没有报错。打包时用squashfs压缩算法选xz或者gzip。xz压缩率高但压缩慢gzip快但体积大。对于RV1106这种存储紧张的板子我倾向用xz虽然编译时多花点时间但镜像小烧录和启动都受益。buildroot里配置BR2_TARGET_ROOTFS_SQUASHFS和BR2_TARGET_ROOTFS_SQUASHFS4_XZ即可。打包命令buildroot会自动执行产物在output/images/下。拿到rootfs.squashfs后用mksquashfs可以手动再压一次确认体积。如果体积还是大用unsquashfs解开看哪个目录占空间针对性删。4.5 镜像打包与分区对齐RV1106的镜像打包用SDK里的build.sh或者mkimage工具。分区表通常在device/rockchip/rv1106/下的配置文件中定义。这里有个关键点分区起始地址要对齐到擦除块大小。SPI NAND的擦除块通常是128KB或者256KB如果分区起始地址没对齐烧录后可能出现读写异常。SDK默认的分区表一般是对齐的但如果你自己调整了分区大小一定要检查对齐。打包命令大致是./build.sh firmware产物是update.img用瑞芯微的烧录工具烧到板子上。烧录前确认板子进了maskrom或者loader模式烧录工具能识别到设备。注意SPI NAND烧录比eMMC慢很多一个100MB的镜像可能要烧几分钟。所以镜像瘦身的收益在烧录环节也很明显别只盯着编译时间。5. 启动优化从冷启动到应用拉起的全链路5.1 启动阶段划分与耗时定位RV1106的启动链路大致是上电 - BootROM - SPL - uboot - kernel - init - 应用。要优化启动先得知道每个阶段花了多久。最直接的办法是打开uboot和kernel的启动时间戳。uboot里可以打开CONFIG_BOOTSTAGEkernel里打开CONFIG_PRINTK_TIME这样串口日志每行都带时间戳一眼就能看出哪个阶段慢。我一般会记录几个关键时间点uboot开始执行的时间、kernel开始解压的时间、kernel initcall完成的时间、init进程启动的时间、应用起来的时间。这几个点一拉出来瓶颈在哪就清楚了。实测RV1106上如果没优化uboot可能占1秒多kernel占2到3秒init和应用占1到2秒总共5到6秒很常见。优化目标通常是压到2秒以内。5.2 uboot阶段的优化uboot阶段能优化的点不多但有几个值得做。第一是关掉uboot里的调试输出CONFIG_DEBUG_UART相关的日志如果不需要就关掉串口打印本身也耗时。第二是精简uboot的命令集用不到的cmd全关掉能减小uboot体积加载更快。第三是调整DDR初始化参数这个要参考瑞芯微给的DDR配置工具参数不对会导致DDR跑在低频拖慢整个启动。第四是跳过不必要的硬件自检比如内存自检量产版本可以关掉。uboot阶段还有一个大杀器是SPL直接引导kernel跳过uboot的完整初始化。但这个改动比较大需要SPL里就完成DDR初始化和kernel加载适合对启动时间极度敏感的场景。一般项目做到关日志、精简命令集就够了。5.3 kernel阶段的优化kernel阶段的优化分两块减少initcall数量和并行化initcall。减少initcall靠的就是前面说的裁剪每关一个驱动就少一个initcall。并行化initcall靠CONFIG_INITCALL_PARALLEL但这个选项在ARM上支持有限收益不稳定我实测下来提升不明显不建议花太多精力。另一个有效的手段是延迟加载非关键驱动。把一些不急着用的驱动从y改成m让它们在init之后再加载这样kernel启动阶段就少了这些驱动的probe时间。比如文件系统相关的驱动、网络驱动、一些传感器驱动都可以改成模块需要时再insmod。还有压缩方式的选择。kernel镜像可以用gzip、xz、lz4等压缩。lz4解压最快但压缩率低xz压缩率高但解压慢。RV1106的CPU是Cortex-A7解压性能有限我实测lz4的解压速度比gzip快不少虽然镜像大一点但启动时间反而更短。这个要实测不同板子结果可能不同。5.4 init和rootfs阶段的优化init阶段是启动优化的另一个大头。如果你用busybox init检查/etc/inittab和/etc/init.d/rcS把不需要的服务全删掉。很多SDK默认会拉起一堆服务比如telnetd、ftpd、各种守护进程量产版本一律不要。每删一个服务就少一次fork和exec启动时间就少一点。如果你用systemd那优化空间更大但也更复杂。systemd本身启动就慢RV1106这种小芯片上我一般不建议用systemdbusybox init足够。如果非要用把不需要的target和service全disable掉用systemctl mask彻底屏蔽。rootfs阶段还有一个技巧是预链接和预加载。把常用的库预链接减少运行时符号解析时间把应用需要的库用LD_PRELOAD预加载减少首次加载的延迟。但这些收益相对小优先级排在裁剪之后。5.5 应用启动的优化应用本身的启动时间也占一部分。如果你的应用是C/C写的检查有没有在启动时做耗时操作比如加载大配置文件、初始化大内存池、扫描目录等。这些能延后的就延后能异步的就异步。如果是脚本语言写的考虑换成编译型语言或者把脚本预编译成字节码。还有一个实用技巧是把应用和依赖库放到tmpfs里。squashfs是只读的读取虽然不慢但tmpfs在内存里读取更快。启动时把应用目录拷到tmpfs再执行能省一点时间。但要注意内存占用RV1106内存紧张别把内存撑爆了。6. 常见问题与排查技巧实录6.1 编译报错速查RV1106编译报错按频率排最常见的是这几类。第一类是缺依赖报错信息里通常有No such file or directory或者command not found装对应的包就行。第二类是工具链不匹配报错里有unrecognized command line option或者cannot find -lxxx检查CROSS_COMPILE和工具链路径。第三类是kernel配置冲突报错里有undefined reference或者conflicting types通常是裁剪时关错了依赖项把相关的项一起关或者一起开。第四类是内存不足编译进程被kill报错里有Killed或者virtual memory exhausted减小-j的值。第五类是权限问题报错里有Permission denied检查文件权限或者用sudo。第六类是磁盘满报错里有No space left on device清理编译产物或者换大磁盘。报错关键词可能原因解决方法No such file or directory缺依赖包安装对应dev包unrecognized command line option工具链不匹配检查CROSS_COMPILEundefined reference配置冲突检查kernel配置依赖Killed内存不足减小-j值Permission denied权限问题检查文件权限No space left on device磁盘满清理或换盘6.2 启动卡死排查启动卡死是RV1106上最常见的问题排查思路是看串口日志卡在哪一行。如果卡在uboot阶段通常是DDR参数不对或者存储介质识别失败。如果卡在kernel解压可能是镜像损坏或者压缩方式不匹配。如果卡在kernel initcall看最后一行日志是哪个驱动大概率是那个驱动的问题把它关掉或者改成模块。如果卡在init阶段通常是rootfs有问题比如init程序找不到、库缺失、挂载失败。这时候可以用init/bin/sh启动到shell手动检查。如果连shell都进不去可能是rootfs镜像本身有问题重新打包。还有一个隐蔽的坑是分区表不对。如果分区起始地址和镜像大小不匹配kernel可能加载到错误的位置表现为启动到一半就重启或者花屏。这时候用烧录工具读回分区表和配置文件对比确认一致。6.3 镜像烧录失败烧录失败常见原因有几个。第一是板子没进对模式RV1106要进maskrom或者loader模式按键时机不对就识别不到。第二是USB线或者口的问题换线换口试试。第三是烧录工具版本不对用瑞芯微官方最新版的烧录工具。第四是镜像本身有问题重新打包一次。第五是SPI NAND坏块这个比较麻烦可能需要换板子。烧录时如果进度条卡住不动先别急着拔线等几分钟看看。SPI NAND烧录本来就慢尤其是大镜像。如果超过十分钟还不动再考虑重来。6.4 启动时间反复优化不下来的情况有时候你裁了又裁启动时间就是下不来。这时候要怀疑几个点。第一是DDR频率没跑满用瑞芯微的工具读一下DDR实际频率如果低于预期检查DDR配置。第二是CPU频率没跑满kernel里检查cpufreq配置确保启动时CPU跑在高频。第三是存储读取速度慢SPI NAND的读取速度本来就有限如果镜像没压缩或者压缩率低读取时间就长。第四是串口日志本身耗时把kernel的loglevel调低减少打印。还有一个容易被忽略的点是电源管理。如果板子的电源设计有问题上电后电压爬升慢也会拖慢启动。这个要用示波器看一般项目碰不到但如果是自己画的板子值得查一下。6.5 独家避坑经验分享几个我在RV1106上踩过的坑。第一个是不要用太新的gcc我试过用gcc 11编kernel结果一堆warning和error换回SDK自带的gcc 8就没事。第二个是squashfs的块大小默认可能是128KB改成64KB或者256KB对读取速度有影响要实测。第三个是uboot的bootdelay默认可能是1秒或者2秒量产版本改成0省这一两秒很可观。第四个是kernel的console如果不需要串口控制台把console参数去掉能省一点初始化时间。第五个是rootfs里的/etc/init.d顺序服务启动顺序不对可能导致某个服务等另一个服务白白浪费时间。检查依赖关系能并行的并行。第六个是应用别用动态链接如果应用不大静态链接能省去加载动态库的时间虽然体积大一点但启动快。第七个是别在启动时做OTA检查这个操作涉及网络会阻塞启动放到后台异步做。7. 优化收益的量化与取舍7.1 各阶段优化的实际收益我把实际项目里的优化收益列一下给你个参考。kernel裁剪关掉DEBUG_INFO和无关驱动通常能省30%到50%的编译时间镜像体积减20%到40%启动时间减0.5到1秒。rootfs裁剪buildroot关包能省20%到30%的编译时间镜像体积减30%到50%启动时间减0.3到0.8秒。uboot优化关日志、精简命令能省0.3到0.5秒启动时间。init优化删服务能省0.2到0.5秒。应用优化异步化、静态链接能省0.2到0.5秒。这些加起来从默认配置的5到6秒启动压到2秒以内是可行的。但要注意收益是递减的越往后越难抠。前期的裁剪收益最大后期的微调收益小但耗时多。所以要根据项目的时间预算决定优化到什么程度。7.2 什么时候该停止优化优化不是无止境的。我的经验是当启动时间已经满足产品需求就停止。比如产品要求3秒内出图你压到2.5秒就够了没必要为了再省0.2秒花一周时间。另外要考虑维护成本过度裁剪的配置可能在新版本SDK上跑不起来每次升级都要重新适配这个成本要算进去。还有一个判断标准是优化是否影响功能稳定性。如果某个优化导致偶发启动失败或者功能异常那这个优化就不值得。稳定性永远优先于启动时间尤其是量产产品。7.3 不同场景的优化侧重不同产品对启动优化的侧重不一样。电池类设备更看重低功耗那么启动优化要配合电源管理比如启动时不要拉高不必要的模块。视觉终端更看重出图速度那么优化重点在sensor驱动和图像pipeline的初始化。带网络功能的产品更看重网络就绪时间那么WiFi或者以太网的初始化要优先。扫码设备更看重扫码响应那么应用层的优化比系统层更重要。所以别照搬别人的优化清单先想清楚你的产品最在意什么把精力放在那个环节上。8. 一些实操中的个人体会RV1106这个平台我最大的体会是**“少即是多”。你关掉的东西越多系统跑得越快、越稳。很多同学舍不得关觉得万一以后要用呢结果就是系统臃肿、启动慢、还容易出问题。我的做法是从最小配置开始往上加**而不是从默认配置往下减。先编一个只有串口和存储驱动的最小系统能启动到shell然后根据需求一个个加驱动和服务每加一个测一次。这样你对系统里有什么、每个东西干什么心里一清二楚出了问题也好定位。另一个体会是编译环境要固定。SDK版本、工具链版本、主机系统版本一旦确定就不要轻易动。我见过团队里有人升级了主机系统结果编译报错查了半天是glibc版本变了。所以建议用Docker把编译环境固化下来或者至少记录清楚版本号换机器时照着装。最后说个小的串口日志是你的好朋友。RV1106没有屏幕出问题全靠串口。把串口日志完整保存下来出问题时对比正常和异常的日志差异点往往就是问题所在。我习惯每次启动都把日志存一份时间长了就是一个日志库排查问题时翻历史日志特别有用。这个平台后续还可以往安全启动和OTA升级方向扩展这两个话题和系统构建也强相关尤其是分区设计和镜像签名和前面讲的打包环节是连着的。如果后面有机会再单独聊。 RV1106嵌入式Linux系统构建与启动优化实战指南
1. 为什么RV1106的系统构建值得单独拿出来聊RV1106这颗芯片这两年在一线出现的频率越来越高尤其是做低功耗视觉终端、电池类IPC、门铃、猫眼、扫码设备这类产品的团队几乎绕不开它。它本质上是瑞芯微面向轻量级AI视觉场景推的一颗SoC单核Cortex-A7加上内置的NPU再配上一颗RISC-V协处理器做低功耗常驻任务封装小、BOM成本压得下来这是它被大量选型的直接原因。但真正上手之后你会发现RV1106的嵌入式Linux系统构建和你在RK3399、RK3568上习惯的那套流程体感完全不一样——它的存储介质通常是SPI NAND或者小容量eMMC内存也紧编译产物动辄几个G烧录镜像又要求分区对齐稍不注意就是编译两小时、启动卡在logo。我前后在RV1106上做过三四个量产项目从最早的SDK默认配置一路踩到能把冷启动压进两秒以内中间关于编译优化和启动优化的坑基本都趟过一遍。这篇东西不是官方文档的复述而是把“从编译到启动”这条链路上真正影响效率的环节拆开讲SDK怎么裁剪、编译怎么并行、镜像怎么瘦身、启动阶段怎么定位耗时、哪些优化是性价比高的、哪些是看着美好实际收益极低的。适合已经拿到RV1106开发板、跑通了官方demo、但觉得构建慢、启动慢、不知道怎么下手的同学也适合正在做嵌入式Linux项目实战、需要把系统体积和启动时间当成硬指标的团队参考。需要先说明一点下面涉及的具体路径、配置项名称不同版本的SDK会有差异我尽量讲清楚“为什么这么改”而不是死记某个文件这样你换SDK版本也能自己推。所有参数和数值都是我在实际项目里测出来的量级不是理论值你的板子和配置不同绝对值会有出入但优化方向和收益比例是通用的。2. 构建流程的整体设计与思路拆解2.1 RV1106系统构建到底包含哪些阶段很多人一说“编译系统”就以为是敲一条make然后等其实RV1106的完整构建链路至少分成五段每一段的耗时和优化空间都不一样。第一段是工具链准备RV1106用的是arm-rockchip830-linux-uclibcgnueabihf这类交叉工具链SDK里通常自带预编译版本但如果你要自己换glibc或者换版本这一步会引入兼容性问题。第二段是uboot编译产出SPL和uboot镜像负责最底层的DDR初始化和引导。第三段是kernel编译包括设备树、驱动、内核模块这是整个构建里最耗时的一块。第四段是rootfs构建用buildroot或者busybox拼出根文件系统再往里塞应用和库。第五段是打包与镜像生成把前面所有产物按分区表拼成一个可烧录的update.img或者分区镜像。这五段里kernel和rootfs占了80%以上的时间uboot通常几十秒就完事。所以优化精力要放在kernel和rootfs上而不是去纠结uboot那点时间。我见过有同学花半天研究怎么让uboot编译快10秒结果kernel那边一个配置没关就多花二十分钟这就是没抓住重点。2.2 为什么RV1106的构建比大芯片更“敏感”RV1106的构建敏感核心原因是它的资源约束和存储介质特性。大芯片的板子往往配大容量eMMC、内存也宽裕编译产物大一点无所谓烧录慢一点也能忍。但RV1106常见的搭配是SPI NAND容量可能就128MB或者256MBrootfs稍微多塞点东西就爆分区而且SPI NAND的写入速度和擦除特性决定了镜像不能太大否则烧录时间成倍增长。另外它的DDR容量通常也小kernel里如果开了太多调试选项启动时内存占用高容易在早期就OOM。这就决定了RV1106的构建思路必须是**“按需裁剪”而不是“全量编译”**。官方SDK默认配置是为了兼容尽可能多的场景所以打开了一堆你可能根本用不到的驱动、文件系统、调试功能。你要做的第一件事不是优化编译命令而是先把这些无关的东西关掉。裁剪带来的收益是双重的编译时间下降镜像体积下降启动时间也跟着下降。这是RV1106上性价比最高的优化没有之一。2.3 编译优化和启动优化的关系这里要纠正一个常见误区很多人把编译优化和启动优化当成两件独立的事其实它们在RV1106上是强耦合的。你编译时关掉的每一个驱动、每一个文件系统、每一个调试选项都会直接反映到启动时间上。比如kernel里关掉一个用不到的USB网卡驱动编译时省几秒启动时省的是驱动probe的时间rootfs里去掉一个用不到的服务编译时省打包时间启动时省的是服务拉起的时间。所以正确的做法是把编译配置当成启动优化的第一手段而不是等系统跑起来了再去用工具分析启动耗时。我一般的流程是先做一轮激进的裁剪把明显用不到的全关掉编译一版测启动然后根据启动日志再针对性关第二轮最后才用工具去抠那些裁剪不掉的耗时点。这样比一上来就上工具分析要高效得多因为工具分析出来的很多耗时点其实你直接关掉对应功能就没了根本不需要优化。3. 核心细节解析与实操要点3.1 工具链选择为什么不要轻易换RV1106 SDK自带的工具链是经过验证的和kernel、uboot的版本是配套的。我强烈建议不要轻易换工具链除非你有明确的理由。换工具链最常见的动机是想用更新的gcc拿到更好的优化但实际收益往往被兼容性问题吃掉。比如你换了高版本gcckernel里某些老代码可能编译报错你得一个个打patch换glibc版本可能导致rootfs里的库和工具链不匹配运行时各种找不到符号。如果你确实需要换我的经验是只换工具链的优化等级不换工具链本身。也就是保持SDK自带的工具链通过CFLAGS调整优化参数。RV1106的Cortex-A7支持到-mcpucortex-a7 -mfpuneon-vfpv4确保这两个参数正确比换工具链带来的收益更实在。另外注意kernel和uboot的编译优化等级不要盲目上-O3-O2在嵌入式场景下通常是体积和性能的最佳平衡点-O3可能让镜像变大反而拖慢启动。3.2 kernel裁剪从menuconfig到defconfig的取舍kernel裁剪是RV1106构建优化的主战场。官方SDK一般会提供一个rv1106_defconfig这个配置是“大而全”的你要做的是基于它做减法。具体怎么减我按优先级列一下。第一优先级是关掉所有用不到的驱动。RV1106常见的应用场景是视觉终端那么声卡、HDMI、大部分USB设备类驱动、蓝牙、WiFi如果你用外挂模组另说、各种传感器驱动如果项目用不到就全关。这里有个技巧不要一个个在menuconfig里找直接看.config里y和m的项对照你的硬件原理图用不到的批量改成# ... is not set。第二优先级是关掉调试和追踪功能。CONFIG_DEBUG_INFO、CONFIG_FTRACE、CONFIG_KPROBES、CONFIG_DEBUG_KERNEL这些量产版本一律关掉。CONFIG_DEBUG_INFO关掉能显著减小kernel体积因为它会往vmlinux里塞大量调试符号。我实测过光关掉DEBUG_INFOkernel镜像能小20%到30%编译时间也能省一截。第三优先级是精简文件系统支持。kernel里支持的文件系统类型只留你实际用的。RV1106上通常用squashfs做只读根、overlayfs做可写层、tmpfs做临时目录那么ext4、f2fs、ntfs、vfat这些如果不用就关掉。每关一个文件系统kernel就少一块代码启动时也少一次初始化。第四优先级是调整内核特性。比如CONFIG_PREEMPT如果你的应用对实时性要求不高用默认的CONFIG_PREEMPT_NONE或者CONFIG_PREEMPT_VOLUNTARY就行CONFIG_PREEMPT会引入额外开销。再比如CONFIG_HZ默认可能是100或者250对于视觉终端100通常够用调高会增加调度开销。3.3 rootfs构建buildroot还是busybox自己拼RV1106的rootfs构建有两条路用buildroot或者用busybox自己拼。buildroot的好处是自动化、依赖管理清晰坏处是它默认会带一堆你可能不需要的包而且buildroot本身的配置也需要裁剪。busybox自己拼的好处是极致精简坏处是依赖要自己处理容易漏库。我的建议是项目初期用buildroot快速跑通量产阶段根据实际情况决定是否换成手工拼。如果buildroot裁剪得当其实也能做到很小。buildroot裁剪的关键是make menuconfig里的Target packages把不需要的包全关掉尤其是那些会自动拉一堆依赖的包比如python、perl、各种网络工具。另外buildroot的BR2_TARGET_ROOTFS_SQUASHFS要打开用squashfs做根文件系统压缩率高读取快。如果你决定手工拼核心是只放运行时真正需要的库和可执行文件。用ldd查每个可执行文件的依赖把依赖库拷进去然后反复在板子上跑缺什么补什么。这个过程比较磨人但最终能拼出一个几十MB甚至更小的rootfs。注意库的版本要和工具链一致否则会出现运行时找不到符号的问题。3.4 并行编译make -j到底开多少make -jN的N怎么定是个老生常谈的问题。理论上N等于CPU核心数但实际要看内存。RV1106的编译通常在x86主机上做如果你的主机是8核16Gmake -j8通常没问题如果是8核8Gmake -j8可能因为内存不够导致编译进程被OOM killer干掉反而更慢。我的经验是N取核心数和内存GB数的较小值比如8核16G取88核8G取64核8G取4。另外kernel编译和rootfs编译可以分开并行。比如你先make -j8 kernel编译的同时在另一个终端make -j4 rootfs只要内存够两者互不干扰。但要注意SDK的顶层Makefile可能有依赖关系直接并行可能出问题稳妥的做法是分步执行而不是一条make -j全包。还有一个容易被忽略的点ccache。如果你要反复编译kernel装个ccache能大幅减少重复编译的时间。配置方法是在工具链的gcc前面加ccache比如export CROSS_COMPILEccache arm-rockchip830-linux-uclibcgnueabihf-。第一次编译会慢一点因为要填充缓存后续改代码再编译命中缓存的部分几乎是瞬间完成。我实测在反复调试驱动阶段ccache能把编译时间砍掉一半以上。4. 实操过程与核心环节实现4.1 环境准备与SDK拉取先确认主机环境。RV1106的SDK编译对主机有要求Ubuntu 18.04或者20.04是比较稳的22.04也能用但可能要装一些老版本的依赖库。必备的包包括build-essential、git、repo、libssl-dev、libncurses-dev、device-tree-compiler、bc、rsync、cpio、python3等。缺哪个装哪个编译报错第一件事就是看是不是缺依赖。SDK拉取一般用repo工具按官方给的manifest来。拉完之后先别急着编译先看一眼目录结构确认kernel、uboot、buildroot、device/rockchip这些目录都在。然后执行一次./build.sh lunch选择板级配置这一步会生成对应的配置文件后续编译都基于这个配置。提示SDK拉取和首次编译建议在SSD上进行机械硬盘上编译kernel会明显更慢因为kernel编译涉及大量小文件读写。4.2 第一轮裁剪从defconfig开始拿到SDK后第一件事是进kernel目录做裁剪。先make ARCHarm rv1106_defconfig生成.config然后make ARCHarm menuconfig进去看。但menuconfig一项项找太慢我的做法是直接编辑.config用搜索的方式批量处理。具体操作先用grep -n y .config列出所有编译进内核的项对照硬件原理图把用不到的驱动标记出来。比如你的板子没有音频codec就搜SND相关的项全改成# CONFIG_XXX is not set。没有USB Host就搜USB相关的项关掉。这个过程要细心关错了会导致启动失败所以建议每关一批就编译一次、启动一次确认没问题再关下一批。裁剪完之后把当前.config保存成自己的defconfig比如make ARCHarm savedefconfig然后把生成的defconfig放到arch/arm/configs/下命名为rv1106_mini_defconfig。以后编译直接用这个不用每次重新裁。4.3 kernel编译参数调优kernel编译时除了-j还有几个参数值得调。第一个是LOCALVERSION如果你不需要在版本号里加后缀把它清空能避免一些不必要的重新编译。第二个是INSTALL_MOD_STRIP编译模块时加上strip能减小模块体积。第三个是KCFLAGS可以在这里追加优化参数比如KCFLAGS-mcpucortex-a7 -mfpuneon-vfpv4确保针对RV1106的CPU特性优化。编译命令我一般这么写make ARCHarm CROSS_COMPILEarm-rockchip830-linux-uclibcgnueabihf- \ rv1106_mini_defconfig make ARCHarm CROSS_COMPILEarm-rockchip830-linux-uclibcgnueabihf- \ KCFLAGS-mcpucortex-a7 -mfpuneon-vfpv4 \ -j8 zImage modules dtbs注意zImage、modules、dtbs分开写这样如果只是改了设备树可以只编dtbs不用全量重编。实测只编dtbs几秒钟就完事全量编kernel要几分钟到十几分钟不等。4.4 rootfs精简与打包rootfs这块如果用buildroot先make menuconfig进Target packages把不需要的包关掉。重点检查这几类网络工具curl、wget、ssh如果不用就关、脚本语言python、perl、lua如果不用就关、图形库如果不用GUI就关、数据库不用就关。每关一个包buildroot会重新计算依赖可能连带关掉一批所以关完要重新make看有没有报错。打包时用squashfs压缩算法选xz或者gzip。xz压缩率高但压缩慢gzip快但体积大。对于RV1106这种存储紧张的板子我倾向用xz虽然编译时多花点时间但镜像小烧录和启动都受益。buildroot里配置BR2_TARGET_ROOTFS_SQUASHFS和BR2_TARGET_ROOTFS_SQUASHFS4_XZ即可。打包命令buildroot会自动执行产物在output/images/下。拿到rootfs.squashfs后用mksquashfs可以手动再压一次确认体积。如果体积还是大用unsquashfs解开看哪个目录占空间针对性删。4.5 镜像打包与分区对齐RV1106的镜像打包用SDK里的build.sh或者mkimage工具。分区表通常在device/rockchip/rv1106/下的配置文件中定义。这里有个关键点分区起始地址要对齐到擦除块大小。SPI NAND的擦除块通常是128KB或者256KB如果分区起始地址没对齐烧录后可能出现读写异常。SDK默认的分区表一般是对齐的但如果你自己调整了分区大小一定要检查对齐。打包命令大致是./build.sh firmware产物是update.img用瑞芯微的烧录工具烧到板子上。烧录前确认板子进了maskrom或者loader模式烧录工具能识别到设备。注意SPI NAND烧录比eMMC慢很多一个100MB的镜像可能要烧几分钟。所以镜像瘦身的收益在烧录环节也很明显别只盯着编译时间。5. 启动优化从冷启动到应用拉起的全链路5.1 启动阶段划分与耗时定位RV1106的启动链路大致是上电 - BootROM - SPL - uboot - kernel - init - 应用。要优化启动先得知道每个阶段花了多久。最直接的办法是打开uboot和kernel的启动时间戳。uboot里可以打开CONFIG_BOOTSTAGEkernel里打开CONFIG_PRINTK_TIME这样串口日志每行都带时间戳一眼就能看出哪个阶段慢。我一般会记录几个关键时间点uboot开始执行的时间、kernel开始解压的时间、kernel initcall完成的时间、init进程启动的时间、应用起来的时间。这几个点一拉出来瓶颈在哪就清楚了。实测RV1106上如果没优化uboot可能占1秒多kernel占2到3秒init和应用占1到2秒总共5到6秒很常见。优化目标通常是压到2秒以内。5.2 uboot阶段的优化uboot阶段能优化的点不多但有几个值得做。第一是关掉uboot里的调试输出CONFIG_DEBUG_UART相关的日志如果不需要就关掉串口打印本身也耗时。第二是精简uboot的命令集用不到的cmd全关掉能减小uboot体积加载更快。第三是调整DDR初始化参数这个要参考瑞芯微给的DDR配置工具参数不对会导致DDR跑在低频拖慢整个启动。第四是跳过不必要的硬件自检比如内存自检量产版本可以关掉。uboot阶段还有一个大杀器是SPL直接引导kernel跳过uboot的完整初始化。但这个改动比较大需要SPL里就完成DDR初始化和kernel加载适合对启动时间极度敏感的场景。一般项目做到关日志、精简命令集就够了。5.3 kernel阶段的优化kernel阶段的优化分两块减少initcall数量和并行化initcall。减少initcall靠的就是前面说的裁剪每关一个驱动就少一个initcall。并行化initcall靠CONFIG_INITCALL_PARALLEL但这个选项在ARM上支持有限收益不稳定我实测下来提升不明显不建议花太多精力。另一个有效的手段是延迟加载非关键驱动。把一些不急着用的驱动从y改成m让它们在init之后再加载这样kernel启动阶段就少了这些驱动的probe时间。比如文件系统相关的驱动、网络驱动、一些传感器驱动都可以改成模块需要时再insmod。还有压缩方式的选择。kernel镜像可以用gzip、xz、lz4等压缩。lz4解压最快但压缩率低xz压缩率高但解压慢。RV1106的CPU是Cortex-A7解压性能有限我实测lz4的解压速度比gzip快不少虽然镜像大一点但启动时间反而更短。这个要实测不同板子结果可能不同。5.4 init和rootfs阶段的优化init阶段是启动优化的另一个大头。如果你用busybox init检查/etc/inittab和/etc/init.d/rcS把不需要的服务全删掉。很多SDK默认会拉起一堆服务比如telnetd、ftpd、各种守护进程量产版本一律不要。每删一个服务就少一次fork和exec启动时间就少一点。如果你用systemd那优化空间更大但也更复杂。systemd本身启动就慢RV1106这种小芯片上我一般不建议用systemdbusybox init足够。如果非要用把不需要的target和service全disable掉用systemctl mask彻底屏蔽。rootfs阶段还有一个技巧是预链接和预加载。把常用的库预链接减少运行时符号解析时间把应用需要的库用LD_PRELOAD预加载减少首次加载的延迟。但这些收益相对小优先级排在裁剪之后。5.5 应用启动的优化应用本身的启动时间也占一部分。如果你的应用是C/C写的检查有没有在启动时做耗时操作比如加载大配置文件、初始化大内存池、扫描目录等。这些能延后的就延后能异步的就异步。如果是脚本语言写的考虑换成编译型语言或者把脚本预编译成字节码。还有一个实用技巧是把应用和依赖库放到tmpfs里。squashfs是只读的读取虽然不慢但tmpfs在内存里读取更快。启动时把应用目录拷到tmpfs再执行能省一点时间。但要注意内存占用RV1106内存紧张别把内存撑爆了。6. 常见问题与排查技巧实录6.1 编译报错速查RV1106编译报错按频率排最常见的是这几类。第一类是缺依赖报错信息里通常有No such file or directory或者command not found装对应的包就行。第二类是工具链不匹配报错里有unrecognized command line option或者cannot find -lxxx检查CROSS_COMPILE和工具链路径。第三类是kernel配置冲突报错里有undefined reference或者conflicting types通常是裁剪时关错了依赖项把相关的项一起关或者一起开。第四类是内存不足编译进程被kill报错里有Killed或者virtual memory exhausted减小-j的值。第五类是权限问题报错里有Permission denied检查文件权限或者用sudo。第六类是磁盘满报错里有No space left on device清理编译产物或者换大磁盘。报错关键词可能原因解决方法No such file or directory缺依赖包安装对应dev包unrecognized command line option工具链不匹配检查CROSS_COMPILEundefined reference配置冲突检查kernel配置依赖Killed内存不足减小-j值Permission denied权限问题检查文件权限No space left on device磁盘满清理或换盘6.2 启动卡死排查启动卡死是RV1106上最常见的问题排查思路是看串口日志卡在哪一行。如果卡在uboot阶段通常是DDR参数不对或者存储介质识别失败。如果卡在kernel解压可能是镜像损坏或者压缩方式不匹配。如果卡在kernel initcall看最后一行日志是哪个驱动大概率是那个驱动的问题把它关掉或者改成模块。如果卡在init阶段通常是rootfs有问题比如init程序找不到、库缺失、挂载失败。这时候可以用init/bin/sh启动到shell手动检查。如果连shell都进不去可能是rootfs镜像本身有问题重新打包。还有一个隐蔽的坑是分区表不对。如果分区起始地址和镜像大小不匹配kernel可能加载到错误的位置表现为启动到一半就重启或者花屏。这时候用烧录工具读回分区表和配置文件对比确认一致。6.3 镜像烧录失败烧录失败常见原因有几个。第一是板子没进对模式RV1106要进maskrom或者loader模式按键时机不对就识别不到。第二是USB线或者口的问题换线换口试试。第三是烧录工具版本不对用瑞芯微官方最新版的烧录工具。第四是镜像本身有问题重新打包一次。第五是SPI NAND坏块这个比较麻烦可能需要换板子。烧录时如果进度条卡住不动先别急着拔线等几分钟看看。SPI NAND烧录本来就慢尤其是大镜像。如果超过十分钟还不动再考虑重来。6.4 启动时间反复优化不下来的情况有时候你裁了又裁启动时间就是下不来。这时候要怀疑几个点。第一是DDR频率没跑满用瑞芯微的工具读一下DDR实际频率如果低于预期检查DDR配置。第二是CPU频率没跑满kernel里检查cpufreq配置确保启动时CPU跑在高频。第三是存储读取速度慢SPI NAND的读取速度本来就有限如果镜像没压缩或者压缩率低读取时间就长。第四是串口日志本身耗时把kernel的loglevel调低减少打印。还有一个容易被忽略的点是电源管理。如果板子的电源设计有问题上电后电压爬升慢也会拖慢启动。这个要用示波器看一般项目碰不到但如果是自己画的板子值得查一下。6.5 独家避坑经验分享几个我在RV1106上踩过的坑。第一个是不要用太新的gcc我试过用gcc 11编kernel结果一堆warning和error换回SDK自带的gcc 8就没事。第二个是squashfs的块大小默认可能是128KB改成64KB或者256KB对读取速度有影响要实测。第三个是uboot的bootdelay默认可能是1秒或者2秒量产版本改成0省这一两秒很可观。第四个是kernel的console如果不需要串口控制台把console参数去掉能省一点初始化时间。第五个是rootfs里的/etc/init.d顺序服务启动顺序不对可能导致某个服务等另一个服务白白浪费时间。检查依赖关系能并行的并行。第六个是应用别用动态链接如果应用不大静态链接能省去加载动态库的时间虽然体积大一点但启动快。第七个是别在启动时做OTA检查这个操作涉及网络会阻塞启动放到后台异步做。7. 优化收益的量化与取舍7.1 各阶段优化的实际收益我把实际项目里的优化收益列一下给你个参考。kernel裁剪关掉DEBUG_INFO和无关驱动通常能省30%到50%的编译时间镜像体积减20%到40%启动时间减0.5到1秒。rootfs裁剪buildroot关包能省20%到30%的编译时间镜像体积减30%到50%启动时间减0.3到0.8秒。uboot优化关日志、精简命令能省0.3到0.5秒启动时间。init优化删服务能省0.2到0.5秒。应用优化异步化、静态链接能省0.2到0.5秒。这些加起来从默认配置的5到6秒启动压到2秒以内是可行的。但要注意收益是递减的越往后越难抠。前期的裁剪收益最大后期的微调收益小但耗时多。所以要根据项目的时间预算决定优化到什么程度。7.2 什么时候该停止优化优化不是无止境的。我的经验是当启动时间已经满足产品需求就停止。比如产品要求3秒内出图你压到2.5秒就够了没必要为了再省0.2秒花一周时间。另外要考虑维护成本过度裁剪的配置可能在新版本SDK上跑不起来每次升级都要重新适配这个成本要算进去。还有一个判断标准是优化是否影响功能稳定性。如果某个优化导致偶发启动失败或者功能异常那这个优化就不值得。稳定性永远优先于启动时间尤其是量产产品。7.3 不同场景的优化侧重不同产品对启动优化的侧重不一样。电池类设备更看重低功耗那么启动优化要配合电源管理比如启动时不要拉高不必要的模块。视觉终端更看重出图速度那么优化重点在sensor驱动和图像pipeline的初始化。带网络功能的产品更看重网络就绪时间那么WiFi或者以太网的初始化要优先。扫码设备更看重扫码响应那么应用层的优化比系统层更重要。所以别照搬别人的优化清单先想清楚你的产品最在意什么把精力放在那个环节上。8. 一些实操中的个人体会RV1106这个平台我最大的体会是**“少即是多”。你关掉的东西越多系统跑得越快、越稳。很多同学舍不得关觉得万一以后要用呢结果就是系统臃肿、启动慢、还容易出问题。我的做法是从最小配置开始往上加**而不是从默认配置往下减。先编一个只有串口和存储驱动的最小系统能启动到shell然后根据需求一个个加驱动和服务每加一个测一次。这样你对系统里有什么、每个东西干什么心里一清二楚出了问题也好定位。另一个体会是编译环境要固定。SDK版本、工具链版本、主机系统版本一旦确定就不要轻易动。我见过团队里有人升级了主机系统结果编译报错查了半天是glibc版本变了。所以建议用Docker把编译环境固化下来或者至少记录清楚版本号换机器时照着装。最后说个小的串口日志是你的好朋友。RV1106没有屏幕出问题全靠串口。把串口日志完整保存下来出问题时对比正常和异常的日志差异点往往就是问题所在。我习惯每次启动都把日志存一份时间长了就是一个日志库排查问题时翻历史日志特别有用。这个平台后续还可以往安全启动和OTA升级方向扩展这两个话题和系统构建也强相关尤其是分区设计和镜像签名和前面讲的打包环节是连着的。如果后面有机会再单独聊。