OE、Yocto、Arago构建TI板卡定制文件系统实战指南

1. 从标题看这次要做什么OE、Yocto、Arago 是什么关系1.1 三个名词到底是什么意思做嵌入式 Linux 开发的人看到“OE、Yocto、Arago 构建 TI 板卡的定制文件系统”这个标题第一反应应该是这不是从零开始揉一个 Linux 系统而是要利用一套成熟的开源工具链从源码级别定制一个能在指定硬件平台上跑的完整根文件系统。标题里三个词其实对应三个不同层面的东西很多人刚接触时容易搞混。OpenEmbeddedOE是一个构建嵌入式 Linux 发行版的构建框架它定义了整套软件包的元数据组织方式、全局配置机制和任务执行逻辑。Yocto Project 是一个开源协作项目它把 OE 的构建系统、一堆配套工具、文档以及社区维护的层layer整合在一起形成了一套更工程化的体系。Arago 则是 TI 平台相关处理器 SDK 里使用的那层发行版配置它在 Yocto/OE 之上预置了针对某种处理器平台的系统配置、软件包选型和启动参数的默认策略。打个比方OE 是发动机Yocto 是整车平台Arago 就是厂家针对某款车型做好的调校包。你去买预编译的官方 SDK 镜像相当于直接开一台调好的整车而用这套组合自己构建相当于你拿到了整车平台和调校参数按自己需求重新改一遍。标题之所以把三者并列是因为实际构建时它们会同时出现在你的工程目录和配置环境里——你用的是 Yocto 的构建命令底层跑的是 OE 的元数据和 BitBake 任务调度器面对的则是预置好 Arago 默认配置的 TI 层。1.2 为什么不用官方预编译 SDK 而要自己构建很多项目起步阶段直接烧官方预编译的镜像测功能完全没问题。但一旦进入量产定制、客户交付、安全合规、特定外设集成这些阶段预编译镜像是撑不住的。我自己经历过的痛点大致有三类。第一是软件包集合固定想加东西很痛苦。预编译的根文件系统里有什么就有什么你试图往里面拷贝某个新编译出来的动态库和可执行文件时经常遇到 glibc 版本不匹配、符号找不到、依赖项缺失这种“二进制地狱”。自己构建则可以在编译阶段就把你需要的应用和库一起编进去依赖关系由构建系统统一追踪出来的镜像从源码到产物都是连贯的。第二是裁剪和加固的需求没法满足。预编译镜像通常包含大量用不到的模块、固件、示例脚本体积大不说安全面也宽。定制文件系统时可以精确到包级别指定装什么、不装什么还能通过PACKAGE_EXCLUDE把某些不必要的包从依赖树上整个排除掉。对于有安全审核要求的项目这一步几乎是必须的。第三是持续集成和版本可复现。官方 SDK 是快照式的半年甚至一年才更新一次而 Yocto 构建环境下你可以自己钉住某个层的 revision把整套源码固化到 git 里每次构建出来的文件系统都完全一致。配合 CI你可以随时给客户拉出一个带最新修复和定制功能的镜像而不会因为“官方还没发新版”而卡住。当然自己构建也有代价——下载源码量大、首次构建耗时长、对磁盘和内存有要求、学习曲线陡。但如果你是长期做一个硬件平台的产品这个投入是值得的。1.3 这套方案到底适合哪些人和哪些场景这套方案适合以下几类人和项目做产品级嵌入式 Linux 的工程师需要把特定硬件平台的 BSP、内核、根文件系统和自研应用集成到一个可交付的刷机包。做安全合规审查的项目需要精确知道根文件系统里每个文件、每个包的来源和构建参数。做长期维护的产品线硬件平台固定但软件需要持续迭代希望用一套可复现、可追溯的构建流水线。想系统学习嵌入式 Linux 系统构建的学生和爱好者通过亲手定制一个 rootfs 来理解启动流程、库依赖、包管理机制。不推荐的情况也有只是临时验证某块板子的外设功能直接烧官方镜像就行硬件平台非常冷门且没有现成 BSP 层自己从头写 provider 层的工作量可能远超预期团队里没人能维护构建环境产线要人接手时会比较头疼。2. 构建环境准备把工程目录搭起来2.1 宿主系统与依赖安装构建 Yocto 系统对宿主环境有基本要求。长时间实测下来最稳妥的方案是在一台 Ubuntu 18.04 或 20.04 的机器上用原生环境构建。新版本的宿主机不是不能用但会遇到 python 版本、系统库兼容、host-gcc版本过新导致某些老代码编译失败等零碎问题排查起来很磨人。确定宿主系统后先用包管理器把基础依赖装齐全。下面是一套常见的依赖清单不同版本可能略有出入但大体就是这个范围sudo apt update sudo apt install -y \ gawk wget git diffstat unzip texinfo gcc build-essential \ chrpath socat cpio python3 python3-pip python3-pexpect \ xz-utils debianutils iputils-ping python3-git python3-jinja2 \ libegl1-mesa libsdl1.2-dev pylint xterm python3-subunit \ mesa-common-dev zstd liblz4-tool安装完依赖最好检查一下 python 默认版本。Yocto 较新的版本要求 python3.8 以上如果你系统里默认 python3 版本过低后续解析 recipe 时会直接报语法错误那种报错一开始很难意识到是版本问题。提示尽量不要在一个目录里反复嵌套多个构建环境。我习惯把 workspace 放在一个独立的挂载分区比如/work/yocto文件系统格式用 ext4不要用某些网络文件系统或压缩文件系统。Yocto 构建过程会产生海量小文件文件系统性能对构建效率影响很大。2.2 用 repo 同步各 layer 源码TI 平台的 Yocto 构建不是让你手动一个一个git clone每个 layer 的官方提供了一个基于 repo 工具的初始化脚本名字通常像oe-layertool-setup.sh或者一个setup-environment脚本。你只需要按官方文档指引下载这个脚本然后执行初始化过程。repo 工具的用法值得多说一句。repo 本身是一个基于 git 的仓库管理工具它通过一个 manifest 文件把多个 git 仓库统一组织起来。执行初始化后repo sync会根据 manifest 里指定的分支和 revision 一次性把 cuisante 层比如 meta-ti、meta-arago、meta-openembedded 等全部拉取到本地。# 创建一个工作目录例如以某个产品名命名 mkdir -p /work/yocto/my-ti-bsp cd /work/yocto/my-ti-bsp # 执行 repo 初始化并同步具体命令以官方文档为准 repo init -u manifest仓库地址 -b 分支名 repo sync -j 8repo sync过程中常见的是网络问题。如果某个仓库一直拉不下来或者超时重试往往能解决。如果整体下载速度很慢可以考虑把git配置里的 http.postBuffer 调大git config --global http.postBuffer 524288000如果下载多次仍然失败不要一根筋死磕检查网络环境和下载源是否畅通更实际。同步完成后工作目录下会有多个 layer 目录常见的有meta-tiTI 平台的硬件支持层包含板级配置、内核、引导加载器等。meta-aragoArago 发行版层包含 TI 平台默认的发行版配置和软件包集成规则。meta-openembedded可能拆成meta-oe、meta-python、meta-networking等社区维护的大量软件包 recipe很多软件包依赖这个层。meta-qt5或meta-qt6如果你的产品需要图形界面或 Qt 应用相关 recipe 在单独的层里。meta-virtualization、meta-cloud-services等可选功能层根据实际需求选择是否添加到配置。2.3 初始化构建环境并检查目录结构同步完源码后需要执行一个环境初始化脚本通常是setup-environment它会把PATH、构建目录路径、核心配置变量准备好然后进入一个独立的构建目录build 目录之后所有的bitbake命令都在这个环境里运行。# 以运行 setup-environment 为例具体脚本名字以你的工具链为准 source setup-environment build运行之后构建目录里会出现conf子目录里面有三个核心配置文件local.conf本机构建配置包括机器型号、并行任务数、下载目录、缓存目录等。bblayers.conf当前构建需要引用的层列表Yocto 构建系统只会处理列表里这些层的内容。sanitized-includes.txt某些版本有记录构建环境中的目录包含信息一般不用动。检查bblayers.conf是否把需要的层都列全了比如meta-ti、meta-arago、meta-oe。少了任何一个关键层后续解析 recipe 时会报no recipe for xxx的错误。实操心得构建目录不要放在源码同步目录的相同层级里容易混淆。构建目录专门用build或build-产品名命名不同产品线可以建多个构建目录共用同一份源码仓这是 Yocto 比较推荐的做法——源码多份会浪费大量磁盘空间而构建目录多份则很灵活。3. 定制文件系统的关键操作local.conf 与 recipe3.1 机器型号、发行版和镜像格式进入构建环境后的第一件事是设置local.conf里的关键参数。开头最常见也是影响全局的有三个变量MACHINE、DISTRO、IMAGE_FSTYPES。MACHINE指定目标硬件平台它决定了构建系统使用哪个板级配置、生成哪种 dtb、选择哪个引导加载器。TI 平台对不同的处理器和评估套件有对应的机器名比如某款 ARM 开发板的机器名可能是am335x-evm另一个更完整的平台对应不同的名称。这个变量直接写进local.confMACHINE am335x-evmDISTRO指定发行版策略。TI 平台工具链支持两种主要策略一种是pokyYocto 默认发行版另一种就是arago。Arago 里预置了很多针对 TI 平台的默认选择比如桌面系统、多媒体框架、GUI 工具包等。如果你想要一个更精简、更贴近 Yocto 原生态的系统可以选择poky系列发行版如果是希望开箱即用地获得 TI 平台完整功能使用默认的arago即可DISTRO aragoIMAGE_FSTYPES则决定最终根文件系统镜像输出的格式。常见选择有格式说明适用场景ext4生成 ext4 格式根文件系统镜像可直接dd写入 SD 卡分区最常见的量产格式tar.bz2 / tar.gz打包根文件系统目录方便二次处理或解包到已有分区需要手动改内容后打包wic生成带分区表的完整 SD 卡镜像包含 boot 分区和 rootfs 分区整体烧写、产线刷机wic.xz对 wic 镜像做 xz 压缩缩小发布包体积一般建议一方面把wic打开作为完整刷机包另一方面保留tar.bz2作为灵活处理的中间产物。在local.conf里写IMAGE_FSTYPES ext4 wic.xz tar.bz23.2 在镜像里增删软件包定制文件系统最核心的操作就是决定镜像里装什么。Yocto 提供了几个常用变量来控制这一点。如果你只是想在默认镜像之外额外追加几个包最直接的方式是修改IMAGE_INSTALL:append这个变量。这一行写在local.conf里即可注意append语法中开头的空格符号必须保留IMAGE_INSTALL:append openssh openssh-sftp-server vim i2c-tools如果你想精简镜像把默认某些包排除掉Yocto 提供了PACKAGE_EXCLUDE变量。需要注意的是排除操作发生在包依赖解析之前如果你排除了一个包但另一个包又依赖它那么构建系统会尝试用PACKAGE_EXCLUDE_COMPLEMENTARY之类的机制把这些包重新拉回来所以这种排除要对依赖关系有明确认知。一个实际例子是排除 systemd 如果系统跑的是 sysvinit但多数 TI 平台默认是 systemd这个例子就不太适用。更实际的排除例子是去掉一些无用的调试工具比如PACKAGE_EXCLUDE gdb strace tcpdump另一个常用的增强变量是EXTRA_IMAGE_FEATURES。它控制的是镜像的“特性”层比如是否包含开发调试包、是否包含源码包、是否允许空 root 密码等EXTRA_IMAGE_FEATURES debug-tweaks ssh-server-openssh dbg-pkgs tools-profiledebug-tweaks允许 root 用户空密码登录这在开发调试阶段非常方便但量产时必须去掉否则就有安全风险。这个教训我踩过一个项目在量产测试阶段忘了从特性里删掉debug-tweaks结果现场抓包测试时别人用空密码直接登进了设备。所以量产构建前一定把这个特性清掉。3.3 自定义 layer 与自研 recipe 的添加大多数产品都会包含自己研发的应用这是定制的重头戏。Yocto 的扩展方式是创建自定义 layer然后在里面维护你自己的 recipe 和配置文件。先看 layer 的整体结构。一个标准 layer 目录下必须有一个conf/layer.conf里面声明了BBPATH、LAYERDIVISION等变量。此外通常还有recipes-*目录来分类存放不同功能的 recipe。创建 layer 最省事的方法是使用 Yocto 提供的工具bitbake-layers create-layer ../meta-myproduct工具会帮你生成模板目录结构和示例 recipe。然后把这个新层添加到bblayers.confbitbake-layers add-layer ../meta-myproduct接下来在meta-myproduct里写自定义应用的 recipe。一个最简单但实用的 recipe 结构如下假设你的应用叫myapp源码放在本地files/目录# meta-myproduct/recipes-myapp/myapp/myapp_1.0.bb DESCRIPTION Custom application for product LICENSE CLOSED SRC_URI file://myapp S ${WORKDIR}/myapp do_install() { install -d ${D}/${bindir} install -m 0755 ${S}/myapp ${D}/${bindir}/myapp } FILES:${PN} ${bindir}/myapp这就是一个最基础的三步 recipedo_install负责把编译产物或脚本安装到D目录下的bindirFILES:${PN}声明这个包包含哪些文件。如果你有复杂构建过程比如需要交叉编译、需要链接第三方库通常在inherit里使用cmake、autotools或pkgconfig等 class构建系统会自动调用对应的编译流程。在写自定义 recipe 时有几个细节容易忽略SRC_URI指定源码来源时如果只是本地文件不需要md5sum或sha256sum校验如果是从某个 URL 下载建议把校验值写进去避免上游内容变化导致构建结果不可复现。如果应用需要系统服务systemd service在 recipe 里用SYSTEMD_SERVICE变量并inherit systemd同时确保IMAGE_INSTALL:append里有对应的myapp包名。在 recipe 里引用另一个包的输出文件比如头文件、编出的库需要正确声明DEPENDS。一个常见的场景是应用需要链接libgpiod那DEPENDS:append libgpiod才能确保构建顺序正确。写完 recipe 后可以用bitbake-layers show-recipes | grep myapp确认 recipe 被识别到然后通过bitbake myapp单独构建这个应用来验证。3.4 根文件系统的二次处理postprocess有些定制需求并不是简单地加包能解决的而是要在根文件系统生成之后对里面的文件做统一处理。比如你想给/etc/config里预置一份产品配置、改默认 hostname、清理某些日志目录、统一权限等。Yocto 下有一个强大的工具叫ROOTFS_POSTPROCESS_COMMAND。它是一个 shell 脚本的集合在根文件系统构建完成后执行此时你可以在函数里直接对IMAGE_ROOTFS目录操作custom_rootfs_prep() { echo mydevice ${IMAGE_ROOTFS}/etc/hostname mkdir -p ${IMAGE_ROOTFS}/data/etc cp ${THISDIR}/files/app_config.ini ${IMAGE_ROOTFS}/etc/app_config.ini # 清理无用的日志和缓存 rm -rf ${IMAGE_ROOTFS}/var/log/* chown -R root:root ${IMAGE_ROOTFS}/etc } ROOTFS_POSTPROCESS_COMMAND:append custom_rootfs_prep;需要注意ROOTFS_POSTPROCESS_COMMAND里的函数是在 chroot 之前还是之后执行不同的 Yocto 版本行为不完全一致。在有的版本里它是在 rootfs 目录里直接跑的有的版本里会尝试 chroot 进去执行。所以脚本里尽量避免依赖宿主动态库的命令用最基础的 busybox 命令就好否则会在构建机器上莫名报 “no such file or directory” 之类的问题。另一种更精细的方式是写一个单独的rootfs附加 recipe通过IMAGE_INSTALL:append加进去然后在那个 recipe 的do_install里往${D}/etc目录下放文件构建系统会自动把这些文件合并到最终 rootfs。这个方式的优点是每次构建迭代更快因为你只需要重新构建那一个包。实操心得定制 rootfs 时我一般不会把产品和项目相关的文件和自研应用全部塞进自定义 recipe 目录因为后续维护时层层叠加很容易乱。更好的组织方式是——通用层只放对任何产品都适用的底层修改比如默认时区、默认网络配置、增值税格式产品专属内容放在单独的 product layer 里。这样项目交接、产品线划分都有清晰边界。4. 构建过程、产物与常见问题4.1 bitbake 构建流程与产物存放位置理解了 recipe 和 layer 之后执行构建就成了顺理成章的事。在构建环境初始化后执行bitbake 目标镜像名TI 平台默认的目标镜像名通常包含tisdk字样比如tisdk-default-image、tisdk-base-image、tisdk-amp-image等。从名字可以猜个大概base 镜像比较基础default 镜像集成度更高amp 镜像则针对异构多核场景。bitbake 构建过程有一点像是流水线它会先解析所有 layer 里的 recipe 和配置生成整个依赖关系图然后按照依赖顺序并行执行任务。每个任务有自己的前缀比如do_fetch负责下载源码do_unpack负责解压do_patch负责应用补丁do_configure负责运行 configure 步骤do_compile负责编译do_install负责安装到临时 rootfsdo_package负责打包成 ipk/deb/rpm 等格式最后do_image_*负责组装根文件系统镜像。你可以用以下命令查看某个 recipe 的任务列表bitbake recipe -c listtasks也可以查看整体依赖图不过那个图通常很大实战里比较有用的是bitbake -e target | grep ^IMAGE_INSTALL通过-e导出环境变量方式排查变量值是否正确是 Yocto 调试的基本功。构建完成后镜像产物和中间产物都位于构建目录下的tmp/deploy/images/MACHINE/。这个目录里你会看到*.wic或*.wic.xz带分区表的完整 SD 卡镜像。*.ext4根文件系统镜像。*.tar.bz2/*.tar.gz根文件系统的打包形式。zImage或Image内核镜像。*.dtb设备树文件。MLO/u-boot.img或者类似名字引导加载器文件。知道这些文件的关系很重要。有时候bitbake 目标镜像构建完了却发现生成的 dtb 版本不对这时你单独构建目标内核或者单独生成某个 dtb 就行不需要重新构建完整镜像。单独构建某个产物是 Yocto 工作中非常常见的任务。4.2 镜像格式选择与刷写测试拿到构建产物后把镜像刷到 SD 卡是最常见的使用方式。如果你的镜像配置到了wic格式那么一个指令就能完成刷写sudo dd if/work/yocto/build/tmp/deploy/images/MACHINE/镜像名.wic of/dev/sdX bs4M convfsync statusprogresswic镜像的好处是分区表齐全包含了引导分区、内核分区、根文件系统分区烧写后直接上电启动不需要再手动刷 bootloader。这一点在产线刷机、多人协作时特别省事。如果你只是更新根文件系统而不用换 bootloader可以只刷.ext4或解压.tar.bz2到已有分区。用tar.bz2解压的方式最灵活sudo mkfs.ext4 /dev/sdX1 sudo mount /dev/sdX1 /mnt/rootfs sudo tar -xjf 镜像名.tar.bz2 -C /mnt/rootfs sync sudo umount /mnt/rootfs刷完后上电测试要重点确认三件事启动是否正常到达登录提示或应用界面。根文件系统是否挂载正确设备树是否匹配硬件。控制台日志里如果出现failed to mount /或者 dtb 加载失败的错误先检查MACHINE是否正确。网络、存储、外设是否正常工作。有时候镜像能起来但 eth0 没有拿到 IP很可能是内核里对应的驱动没编进去或者设备树里状态设成了 disabled。4.3 常见报错与排查技巧速查表Yocto 编译报错是家常便饭但如果能快速定位问题效率就能提升不少。我把自己平时踩过的坑按现象整理成了一张表方便对应排查。现场现象可能原因处理方法repo sync卡住或失败git 仓库下载中断、网络受限重试调大http.postBuffer换网络再试bitbake解析时提示layer not in BBPATHbblayers.conf缺失某个层用bitbake-layers add-layer添加缺失层提示No recipe for xxxrecipe 未找到层未启用或命名不一致bitbake-layers show-recipes确认检查MACHINE和DISTRO配置编译某个包时头文件缺失缺少对应的DEPENDS声明在 recipe 里补充DEPENDS重建该 recipedo_fetch失败下载不到源码URL 失效或校验值不匹配检查SRC_URI清掉tmp/downloads里缓存重试构建完没找到想要的镜像文件IMAGE_FSTYPES未包含对应格式在local.conf里补上格式重新bitbakedisk full磁盘空间不足检查tmp目录占用清理旧构建产物适当加大磁盘MemoryError或构建被杀内存不足降低BB_NUMBER_THREADS和PARALLEL_MAKE用更小的构建任务根文件系统启动后缺应用IMAGE_INSTALL:append未生效检查变量语法是否自带前导空格用bitbake -e验证变量展开结果UNINITIALIZED_VALUE等奇怪编译错误构建环境被污染删除对应包的临时构建目录必要时bitbake recipe -c cleanall bitbake recipe有几个技巧值得展开说。第一个是用-e查变量的正确姿势。有时候你明明在local.conf写了IMAGE_INSTALL:append myapp但构建出来的镜像里就是没有。此时敲bitbake -e 目标镜像名 | grep ^IMAGE_INSTALL看变量最终展开结果是否包含你的包名。不包含的话多半是变量名写错了、层没加载、或者append语法少了空格。第二个是单独构建某个包的技巧。当你只想调试一个 app 或者内核配置时可以用bitbake recipe -c compile -f-f强制重新执行该任务跳过缓存。改完代码后再-c compile最后重新生成目标镜像。这个流程比每次从头构建整个镜像要快得多。第三个是开发镜像的调试利器devshell。在开发某个包的 recipe 时可以用bitbake recipe -c devshell它会打开一个 shell工作目录就是该包的编译目录此时交叉编译环境、PATH、CFLAGS都已经设置好了。你可以在里面直接手动跑 configure、make、debug快速定位构建问题不用反复改 recipe 然后重新构建。第四个是sstate 缓存目录的妙用。Yocto 的构建系统会缓存每个包的输出内容到 sstate cache 目录。如果你在local.conf里配置了SSTATE_DIR /work/yocto/sstate-cache那么后续构建会检查缓存避免重复编译相同包。如果你有多台机器做同样构建甚至可以把SSTATE_DIR放在共享目录里让所有构建共享这些缓存能大幅节省重复编译时间。当然这个共享目录要有足够的空间和适当的并发控制否则容易产生缓存读写冲突。另外有一点容易被新手忽略修改 layer 里的 recipe 后并不总会触发重新构建。构建系统根据任务输出变化来判断是否需要重新执行如果你改了 recipe 但输出指纹没变它可能认为没必要重跑。这时候用bitbake recipe -c cleanall强制清理该包的构建产物再重新构建确保旧产物不会干扰结果。cleanall比较暴力会连同下载缓存一起清掉通常cleansstate更温和一些。4.4 加速增量构建的几个习惯Yocto 构建慢是出了名的首构建动辄一两个小时甚至更久。但构建系统能做增量缓存只要养成几个好习惯后续构建可以快很多。别频繁改全局变量。如果你在local.conf里随手改了某一行可能影响大量包的重建整个构建系统会把这颗依赖树上的包全部重编。所以全局配置尽量保持稳定。单独构建经常变动的 recipe。我在改自研应用时基本上都只执行bitbake myapp -c compile -f确认无误后再执行bitbake 目标镜像。这样自研应用的构建时间基本都是秒级。把DL_DIR共享出来。DL_DIR是源码包下载后的统一存放目录多个构建目录甚至多台机器可以共用一个DL_DIR这样只要下过一次源码后续所有构建都不用再重复下载。实测下来这个省时效果非常明显尤其是在网络不太稳定的环境里。合理利用BB_NUMBER_THREADS和PARALLEL_MAKE。这两个变量控制 CPU 并行度不是设得越大越好内存不够的话反而拖垮构建。经验上一个 4 核心 16G 内存的开发机设BB_NUMBER_THREADS4、PARALLEL_MAKE4就是一个比较平衡的组合。定时清理 tmp 目录。tmp目录里积累的临时构建文件非常多动不动就十几个 GB。定期bitbake -c cleansstate清理旧包缓存能有效控制磁盘占用避免“明明还有几十 GB 却装不下”的尴尬。5. 我在实际使用这套工具链的几点体会做嵌入式 Linux 也有一段时间了和 Yocto、OE、Arago 这套体系打交道这几年最大的感受是它最大的优点和最大的缺点都是同一个——自由度太高。高到你几乎可以改任何东西也因此容易花大量时间去调那些“其实不影响功能”的细节。所以我养成了一个习惯先跑通默认配置的完整构建确认板子能起来再一步步把定制加进去。每加一步就构建一次并烧写验证不攒一堆改动一次性跑——这是防止排查问题时不知道是哪一步引入的最有效手段。构建产物出来之后我会手动检查几个关键点根文件系统启动日志里有没有Failed to start、Unable to之类字样的服务ls /usr/bin或者dpkg -l核对关键包是不是在跑一下poweroff和reboot验证系统能正常关机重启。这些基本功能测试通过后再去做更深层的外设、网络和应用层验证。最后再分享一个小技巧把每次成功构建的 git revision、镜像名、时间在构建目录里写到一个build-info.txt看起来是个笨办法但真到客户反馈某个版本有 bug 时这个记录的保存成本简直可以忽略不计却能帮你快速定位是哪个 commit 带来的变化。希望这篇内容能帮你少走一些弯路。