4. Yocto与Android构建系统集成

R-Car AAOS座舱平台的构建并不是“Android 单独编译”这么简单。它本质上是两套构建体系的协作：底层由 Yocto 负责生成 BSP（Board Support Package）中的引导链、内核、设备树、固件与部分 HAL 依赖；上层由 Android 构建系统（Soong、Make、Kati、Ninja）负责编译 Framework、Native 服务、HAL 接口、应用与系统镜像。理解这两套系统如何“接缝”，是后续镜像定制、产物分析和烧录能否顺利推进的关键。

一、R-Car BSP 层在整体构建中的位置

R-Car BSP 通常以 Yocto meta 层的形式提供，例如 meta-renesas、meta-rcar-gen4 等。它主要交付以下内容：

• Bootloader 与引导链：ARM Trusted Firmware（BL2/BL31）、U-Boot、以及 R-Car 特有的 IPL 与 Flash Writer 相关产物。
• Linux 内核与设备树：Image、*.dtb，以及针对具体板级（如 R-Car H3/M3/N4 参考板）的 DTS 配置。
• 固件与协处理器镜像：如 SCIF、IMP、GPU、VPU、ADSP 等固件，通常以 .bin 或 .elf 形式存在。
• HAL 与驱动接口：部分 Android HAL 依赖的 kernel module、Vendor Interface 定义、以及 libgralloc、libhwcomposer 等底层库的源码或预编译产物。

这些内容最终会以“预编译产物 + 源码补丁 + 配置文件”的形式，被 Android 构建系统通过 device/renesas/ 或 vendor/renesas/ 目录引用。也就是说，Yocto 负责“把硬件跑起来”，Android 负责“把系统跑完整”。

二、Android 构建系统如何接入 BSP

Android 构建系统在 R-Car 平台上通常采用 lunch 目标来区分产品。例如：

source build/envsetup.sh
lunch rcar_h3_aaos-userdebug
make -j$(nproc) dist

其中 rcar_h3_aaos 对应 device/renesas/rcar_h3_aaos/ 下的 AndroidProducts.mk、BoardConfig.mk 和 device.mk。关键集成点包括：

• BoardConfig.mk：定义 TARGET_BOARD_PLATFORM、TARGET_KERNEL_SOURCE、TARGET_KERNEL_CONFIG、BOARD_KERNEL_CMDLINE，并指向 BSP 提供的内核与 dtb 路径。
• device.mk：通过 PRODUCT_COPY_FILES 把 BSP 固件、dtb、HAL 预编译库复制到 vendor/ 或 odm/ 分区。
• Vendor Interface：Android 8.0 以后要求 HAL 通过 vendor_interface 与 Framework 通信，R-Car BSP 中的 HAL 需要提供对应的 .hal 接口定义与 impl 实现。

一个常见的集成错误是：内核编译通过，但 Android 启动时找不到 dtb 或固件。这通常是因为 PRODUCT_COPY_FILES 的源路径没有指向 BSP 实际输出目录，或者 BOARD_KERNEL_CMDLINE 中的 androidboot. 参数与 BSP 的 bootargs 不一致。

三、镜像定制：从分区到内容

R-Car AAOS 的镜像通常包含 boot.img、dtbo.img、vbmeta.img、super.img（或 system.img、vendor.img、product.img）以及 userdata.img。定制时重点关注：

• 分区表：在 BoardConfig.mk 中通过 BOARD_SUPER_PARTITION_SIZE、BOARD_*_IMAGE_PARTITION_SIZE 控制大小，需与 BSP 的 fstab 和 Flash Writer 分区表一致。
• 启动参数：androidboot.selinux=permissive 仅用于调试，量产应设为 enforcing；androidboot.hardware=rcar 用于匹配 init.rc。
• Vendor 内容：把 BSP 的固件、HAL、init.*.rc 脚本放入 vendor/，并通过 PRODUCT_PACKAGES 把 HAL 服务加入构建。

例如，若要把 BSP 中的 libimp.so 和 imp_fw.bin 加入 vendor 分区，可在 device.mk 中写：

PRODUCT_COPY_FILES += \
    vendor/renesas/prebuilt/libimp.so:$(TARGET_COPY_OUT_VENDOR)/lib64/libimp.so \
    vendor/renesas/prebuilt/imp_fw.bin:$(TARGET_COPY_OUT_VENDOR)/firmware/imp_fw.bin

四、编译产物分析与烧录流程

编译完成后，产物集中在 out/target/product/<lunch目标>/ 下。建议按以下顺序检查：

1. 引导链：确认 boot.img 中的 kernel 与 dtb 是否与 BSP 版本匹配，可用 unpack_bootimg 解包查看。
2. 分区镜像：检查 super.img 是否包含 system、vendor、product，可用 lpunpack 解包验证。
3. 固件与 HAL：确认 vendor/firmware/ 和 vendor/lib64/hw/ 下存在 BSP 提供的文件。
4. 签名与校验：vbmeta.img 需与 boot.img、dtbo.img 的 hash 对应，否则启动会触发 AVB 校验失败。

烧录通常使用 Renesas 提供的 Flash Writer 或 fastboot。以 fastboot 为例：

fastboot flash boot out/target/product/rcar_h3_aaos/boot.img
fastboot flash dtbo out/target/product/rcar_h3_aaos/dtbo.img
fastboot flash vbmeta out/target/product/rcar_h3_aaos/vbmeta.img
fastboot flash super out/target/product/rcar_h3_aaos/super.img
fastboot reboot

若板子无法进入 fastboot，则需通过 Flash Writer 从串口或 USB 下载 IPL 与 U-Boot，再进入 fastboot 模式。烧录后通过串口日志观察 U-Boot 是否成功加载 kernel、init 是否启动、vendor 分区是否挂载成功。常见失败点包括：分区大小不匹配、dtb 与板级不匹配、AVB 校验失败、SELinux 拒绝导致 HAL 无法启动。