📚 课程目录第4章 Yocto/OpenEmbedded量产镜像构建

4. Yocto/OpenEmbedded量产镜像构建

在R-Car量产交付中，Yocto/OpenEmbedded不是“编译一次能跑就行”的工具，而是把BSP、驱动、中间件、应用和配置固化成可追溯、可复现、可审计镜像的构建系统。Renesas官方通过meta-renesas层把R-Car SoC的启动链、内核、图形、多媒体和板级支持接入Poky参考发行版。理解这一层的组织方式，是后续做配方定制和镜像裁剪的前提。

meta-renesas的层结构与依赖关系

meta-renesas通常位于Yocto工程sources/目录下，与poky、meta-openembedded、meta-arm等层并列。它内部按功能划分为若干子目录：conf/存放layer.conf和机器配置，recipes-bsp/管理U-Boot、TF-A、OP-TEE等启动组件，recipes-kernel/提供Linux内核配方与设备树，recipes-graphics/和recipes-multimedia/承载GPU、视频编解码相关包，recipes-core/则处理基础系统集成。层与层之间通过LAYERSERIES_COMPAT和BBFILE_PRIORITY约束兼容性与优先级，构建时BitBake按优先级决定同名配方的采用顺序。

实际工程中，我们不会直接修改meta-renesas，而是新建一个产品层，例如meta-r-car-product，通过BBFILE_PRIORITY高于BSP层来覆盖机器配置、内核片段和镜像配方。这样既保留官方层的可升级性，又让产品差异集中可控。

配方定制：从.bbappend到内核片段

配方定制的第一原则是“覆盖而非修改”。对BSP层中已有配方，在产品层创建同名.bbappend文件，例如recipes-kernel/linux/linux-renesas_%.bbappend，在其中追加SRC_URI指向产品专属的内核配置片段或补丁。内核配置推荐使用.cfg片段配合KERNEL_FEATURES，而不是直接替换defconfig，这样在BSP升级时冲突面最小。

对于产品新增的守护进程或诊断工具，应编写独立.bb配方，明确LICENSE、LIC_FILES_CHKSUM、SRC_URI和do_install。若软件来自内部Git仓库，SRCREV必须锁定到具体commit，禁止使用AUTOREV进入量产构建，否则同一配方在不同时间会拉取不同代码，破坏可复现性。

# meta-r-car-product/recipes-kernel/linux/linux-renesas_%.bbappend
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://product.cfg \
            file://0001-can-add-product-filter.patch"

# 产品层机器配置覆盖示例
# meta-r-car-product/conf/machine/r8a779g0-product.conf
require conf/machine/r8a779g0-eagle.conf
PREFERRED_PROVIDER_virtual/kernel = "linux-renesas"
SERIAL_CONSOLES = "115200;ttySC0"
IMAGE_FSTYPES += "tar.bz2 ext4 wic"

镜像类型选择与裁剪策略

Yocto提供多种镜像配方，量产选择取决于产品形态。若目标是快速验证启动链，core-image-minimal体积最小、构建最快；若需要图形界面验证，core-image-weston集成Wayland和Weston合成器；若需要完整驱动与中间件，core-image-base是更合适的基线。量产镜像通常基于core-image-base或自建product-image.bb，通过IMAGE_INSTALL精确控制包集合，并追加IMAGE_FEATURES如ssh-server-openssh、debug-tweaks（仅调试阶段）。

裁剪时优先移除packagegroup-core-tools-debug、packagegroup-core-tools-testapps等调试包组，关闭tools-profile特性。对于R-Car的GPU和视频编解码，需确认gles-user-module、mmngr-user-module等专有包是否被正确引入，避免因裁剪导致HMI或摄像头链路失效。镜像大小可通过du -sh tmp/deploy/images/<machine>/*.wic观察，并与buildhistory中的包体积变化对照。

可复现构建的落地要点

可复现构建要求同一组输入在任何时间、任何构建机上产出比特级一致的镜像。落地时至少做到四点：第一，所有层仓库在bblayers.conf中记录到具体commit，并用repo或git submodule锁定；第二，local.conf中设置BB_HASHSERVE和共享SSTATE_DIR，但需注意sstate缓存本身不保证跨机器一致，最终校验仍以镜像哈希为准；第三，构建在固定版本的Docker容器或SDK中进行，避免宿主工具链差异；第四，归档license.manifest、image.manifest和镜像SHA256，作为量产批次追溯依据。

建议在CI中增加一条校验任务：对同一commit连续构建两次，比较两次.wic文件的SHA256。若不一致，优先排查时间戳嵌入、AUTOREV残留和并行任务顺序依赖。

完成上述配置后，典型构建命令为bitbake product-image，产物位于tmp/deploy/images/<machine>/。量产交付前，应确认镜像已包含正确的启动链、内核、设备树和产品应用，并通过wic写入eMMC或SD卡在目标板上完成启动验证。只有构建可复现、产物可追溯、镜像内容与BOM一致，Yocto构建才算真正进入量产交付状态。