3. 开发环境搭建
R-Car 数字仪表与多屏座舱系统的软件开发，几乎不可能在目标板上直接编译。原因很直接：R-Car H3/M3 这类 SoC 的完整镜像包含 U-Boot、ARM Trusted Firmware、Linux 内核、设备树、根文件系统以及 GPU/视频编解码等专有组件，构建一次动辄需要数十 GB 磁盘和数小时 CPU 时间。因此工程上普遍采用“宿主机交叉构建 + 目标板运行”的模式，而 Yocto/OpenEmbedded 正是承载这一模式的标准框架。本节围绕四个环节展开：Yocto 环境准备、交叉工具链、BSP 获取与板级配置、首次启动验证。
一、Yocto/OpenEmbedded 的构建模型
Yocto 不是一个发行版，而是一套构建系统。它由 BitBake 调度器、OpenEmbedded-Core 元数据层、Poky 参考发行版以及各厂商 BSP 层组成。理解它的关键是分清三个概念：Layer（层）存放配方与配置，Recipe（.bb 配方）描述如何获取、编译、打包一个组件，Image（镜像）是最终产物。Renesas 的 BSP 以独立 layer 形式提供，叠加在 Poky 之上，因此构建命令始终是“先初始化环境，再指定机器与镜像”。
宿主机建议使用 Ubuntu 20.04/22.04 LTS，至少 8 核 CPU、16 GB 内存、200 GB 以上空闲磁盘，并安装 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 等依赖包。磁盘不足是新手最常见的失败原因，务必在开始前确认。
二、交叉编译工具链的两种来源
交叉工具链负责在 x86_64 宿主机上生成 AArch64 目标代码。工程上有两条路径：一是直接使用 Linaro 或 ARM 官方发布的 aarch64-none-linux-gnu- 独立工具链，适合单独编译内核模块或小型应用；二是使用 Yocto 通过 bitbake meta-toolchain 生成的 SDK，它包含与目标根文件系统完全匹配的 sysroot、库和头文件，是构建完整应用的首选。
SDK 安装后通过环境脚本激活，之后 CC、CXX、PKG_CONFIG_PATH 会自动指向目标 sysroot，避免宿主机库污染。判断工具链是否可用，可执行 aarch64-poky-linux-gcc -v 查看目标架构，并用 file 检查产物是否为 ELF 64-bit LSB, ARM aarch64。若误用宿主机 gcc，产物会是 x86_64，烧录后无法运行，这是排查“程序在板上无法执行”时的第一检查点。
三、BSP 获取与板级配置
Renesas 官方通过 renesas-rcar 系列 layer 提供 BSP，通常以 Yocto 社区 BSP 或 eLinux 发布包形式给出。获取后需在 bblayers.conf 中加入 meta-renesas、meta-rcar-gen3 等层，并在 local.conf 中设置目标机器，例如 MACHINE = "salvator-xs" 或对应仪表板型号。机器配置决定了 U-Boot 板级文件、设备树和内核 defconfig 的选择。
板级配置的核心是设备树。R-Car 的显示子系统、I2C 触摸、音频、以太网 PHY 都通过设备树描述。若屏幕不亮或触摸无响应，往往不是驱动缺失，而是设备树中对应的 status 仍为 disabled，或引脚复用（pfc）未正确配置。因此首次构建前应确认 BSP 版本与硬件版本匹配，避免用旧 BSP 驱动新板。
四、首次启动验证与常见问题定位
镜像构建完成后，通过 SD 卡或 eMMC 烧录，连接串口（115200 8N1）观察启动日志。验证顺序建议如下：先确认 BootROM 能加载 U-Boot，再确认内核解压与设备树加载，最后进入用户空间。若卡在 Starting kernel ... 之后无输出，通常是设备树与内核不匹配或串口控制台参数错误；若内核启动但根文件系统挂载失败，检查 root= 参数与分区布局。
进入系统后，用 dmesg | grep -i drm 确认显示控制器初始化，用 ls /dev/dri 确认渲染节点存在，用 i2cdetect -y 1 扫描触摸控制器地址。若触摸无响应，先确认设备树中 I2C 节点 status = "okay"，再检查中断引脚复用。这些检查点能把“屏幕不亮”这类模糊问题快速收敛到设备树、驱动或硬件三个方向之一。
bitbake core-image-minimal 验证工具链与 BSP 层是否完整，再切换到带图形栈的 core-image-weston 或厂商仪表镜像，可显著缩短排错周期。完成上述步骤后，你应当得到一个可启动、可登录、显示与外设基本可用的目标系统。这个基线环境是后续仪表 HMI 开发、多屏显示配置与性能调优的前提，务必在进入应用开发前确认其稳定可复现。