4. 开发环境搭建与BSP获取

Ryzen Embedded 多媒体工业终端的软件开发，本质上是一条“在 x86_64 主机上为 x86_64 目标板构建完整 Linux 系统镜像”的流水线。虽然主机与目标同为 x86_64 架构，理论上可以本地编译，但工业终端项目通常要求可复现、可裁剪、可长期维护，因此仍采用“交叉编译主机 + 构建系统 + 厂商 BSP”的标准模式。本节围绕这条流水线，说明 Ubuntu 主机的准备、Yocto 与 Buildroot 的取舍、AMD 嵌入式 BSP 的获取方式，以及 SDK 安装与版本管理的关键做法。

一、Ubuntu 交叉编译主机：先满足构建系统的硬性依赖

推荐使用 Ubuntu 22.04 LTS（Jammy）作为构建主机，原因是 AMD 官方 BSP 与 Yocto 各版本对其验证最充分。主机建议配置：8 核以上 CPU、32 GB 内存、至少 250 GB 可用 SSD 空间（Yocto 的 build 目录、sstate 缓存与 downloads 目录会迅速膨胀），并保持稳定的网络访问。磁盘空间不足是构建失败最常见的原因之一，建议单独挂载一块数据盘用于构建。

安装基础依赖包是第一步，这些包覆盖了 Yocto 与 Buildroot 共同需要的工具链、打包与解析工具：

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 zstd liblz4-tool file locales libacl1

sudo locale-gen en_US.UTF-8
sudo update-locale LANG=en_US.UTF-8

其中 chrpath、socat、cpio、zstd 是 Yocto 构建过程中被频繁调用的工具，缺失时往往在构建中途才报错，提前安装可避免返工。此外，Yocto 对 /bin/sh 指向 dash 敏感，建议将默认 shell 切换为 bash：sudo dpkg-reconfigure dash 选择“No”。

二、Yocto 与 Buildroot：按项目需求选择构建系统

两者都能产出完整的根文件系统与镜像，但定位不同。Buildroot 以“简单、快速、单层配置”见长，适合功能固定、裁剪明确的终端产品；Yocto 以“分层（layer）、配方（recipe）、可扩展”见长，适合需要长期维护、多产品线复用、需要 SDK 与包管理的项目。工业终端通常涉及多媒体栈（GStreamer、VA-API）、安全启动与 OTA 升级，Yocto 的元数据分层能力更合适，因此本课程以 Yocto 为主线，Buildroot 作为轻量替代方案。

Yocto 的版本选择要与 AMD BSP 对齐。常见组合是 Yocto 4.0（kirkstone）或 4.2（mickledore）搭配对应的 AMD 嵌入式 BSP 发布分支。版本错配会导致配方解析失败或补丁冲突，因此“先确定 BSP 支持的 Yocto 版本，再拉取对应分支”是必须遵守的顺序。

三、AMD 嵌入式 BSP 的获取与目录结构

AMD 嵌入式 BSP 通常以 Git 仓库或发布包形式提供，包含 BSP 层（如 meta-amd）、机器配置（machine conf）、内核配方与设备树、以及预编译的固件与图形驱动。获取方式一般有两种：一是从 AMD 官方嵌入式下载页面获取发布包；二是通过 Git 克隆 BSP 层并配合 repo 或 kas 管理多仓库。以下为典型的目录组织示例：

ryzen-terminal/
├── poky/                  # Yocto 基础层
├── meta-amd/              # AMD 嵌入式 BSP 层
├── meta-openembedded/     # 通用扩展层
├── meta-ryzen-terminal/   # 项目自定义层
└── build/                 # 构建输出目录

项目自定义层 meta-ryzen-terminal 用于放置产品专属的机器配置、内核补丁、镜像配方与 systemd 服务，避免直接修改 BSP 层，从而保证后续 BSP 升级时冲突可控。

四、SDK 安装与版本管理

Yocto 可生成可扩展 SDK（eSDK），其中包含交叉工具链、sysroot、环境脚本与 devtool，用于在主机上编译目标板应用。生成 SDK 的命令为：

bitbake meta-toolchain
# 或生成包含应用开发组件的 eSDK
bitbake core-image-minimal -c populate_sdk_ext

生成的安装脚本位于 tmp/deploy/sdk/ 下，安装时指定独立前缀，避免多个 SDK 互相覆盖：

./poky-glibc-x86_64-core-image-minimal-core2-64-ryzen-terminal-toolchain-4.0.sh \
  -d /opt/sdk/ryzen-terminal-4.0

安装后通过 source /opt/sdk/ryzen-terminal-4.0/environment-setup-core2-64-poky-linux 激活环境，此时 $CC、$CXX、$PKG_CONFIG_SYSROOT_DIR 等变量已指向目标 sysroot，可直接用 $CC 编译目标程序。

版本管理方面，建议遵循三条原则：第一，用 Git 管理所有层与项目层，每个层固定到具体 commit，而非浮动分支；第二，用 kas 或 repo 的 manifest 文件锁定整套版本组合，使团队任意成员可复现同一构建；第三，SDK 与 BSP 版本一一对应，升级 BSP 时同步重建 SDK，避免应用与系统库 ABI 不一致。下面这张图概括了从主机准备到 SDK 交付的完整依赖与版本对齐关系。

五、构建验证与常见问题判断

完成环境准备后，用一次最小镜像构建验证整条链路是否打通：

source poky/oe-init-build-env build
bitbake core-image-minimal

构建成功时，tmp/deploy/images/<machine>/ 下会出现内核、设备树与根文件系统镜像。若在 do_fetch 阶段失败，多为网络或镜像源问题；若在 do_compile 阶段报缺少工具，回到第一节的依赖清单核对；若在 do_rootfs 阶段报包冲突，通常是层版本不匹配，需检查 BSP 与 poky 分支是否对齐。判断构建是否真正可用的标准不是“没有报错”，而是镜像能烧录到目标板并正常启动到登录提示符。