4. Ryzen Embedded开发环境搭建

Ryzen Embedded 平台的开发环境不是“装一个 IDE”就能解决的，它由四层构成：底层是 AMD 官方提供的 BSP（含 SoC 初始化、AGESA、参考 UEFI/固件与内核补丁），中间是发行版构建系统（Yocto 或 Ubuntu 根文件系统），上层是交叉编译工具链，最外层才是调试通道（串口与 JTAG）。这四层必须版本对齐，否则最常见的现象是内核能起来但 PCIe 设备枚举失败，或者编译出的模块 insmod 时报 vermagic 不匹配。

一、官方 BSP 的获取与版本对齐

AMD 针对 Ryzen Embedded V1000/V2000、R1000、7000 系列分别发布 BSP 包，通常以“AMD Ryzen Embedded <系列> Board Support Package”命名，内部包含 amd-agesa、参考 UEFI 源码、Linux 内核补丁集、设备树/ACPI 表以及若干参考设计原理图。获取渠道是 AMD 官方开发者门户（需注册账号并签署 NDA 才能拿到完整包），公开部分一般只提供内核补丁与文档。

版本对齐的核心是三个号：SoC 型号（如 V2718）、BSP 版本（如 V2000_BSP_1.0.0.7）、内核基线（如 linux-5.15.y）。建议在工程根目录建立一份 VERSION.lock 记录这三项，后续所有构建脚本都从这里读取，避免团队成员各用一套。

# VERSION.lock 示例
SOC_MODEL=V2718
BSP_VERSION=V2000_BSP_1.0.0.7
KERNEL_BASE=linux-5.15.74
YOCTO_RELEASE=kirkstone
TOOLCHAIN=x86_64-poky-linux-gcc-11.3

二、Yocto 与 Ubuntu 两条路线怎么选

Yocto 适合量产固件：镜像可裁剪到 200 MB 以内，启动时间可控，BSP 补丁以 bbappend 形式叠加，升级可做成 A/B 双分区。Ubuntu 适合快速原型：驱动齐全、apt 生态方便，但根文件系统体积大（>1.5 GB），且内核升级容易覆盖 BSP 补丁。

Yocto 路线的最小操作序列如下（以 kirkstone 为例）：

git clone -b kirkstone git://git.yoctoproject.org/poky
git clone -b kirkstone git://git.openembedded.org/meta-openembedded
git clone -b kirkstone https://github.com/amd/meta-amd.git
source poky/oe-init-build-env build-v2000
bitbake-layers add-layer ../meta-openembedded/meta-oe
bitbake-layers add-layer ../meta-amd/meta-ryzen-embedded
# 在 conf/local.conf 中设置
MACHINE = "v2000-evb"
# 构建最小镜像
bitbake core-image-minimal

构建产物位于 tmp/deploy/images/v2000-evb/，其中 core-image-minimal-v2000-evb.wic 可直接 dd 到 eMMC 或 SD 卡。判断构建是否成功，不只看 bitbake 退出码，还要确认 Image、*.dtb、wic 三个文件都存在且时间戳一致。

Ubuntu 路线则是在 AMD 提供的 Ubuntu 20.04/22.04 基础镜像上，用 apt 安装 linux-image-amd-ryzen 或自行编译带 BSP 补丁的内核。关键动作是把 BSP 补丁按顺序 git am 到内核源码，再 make -j$(nproc) bindeb-pkg 生成 deb 包，避免直接 make install 污染系统。

三、交叉编译工具链

Yocto 构建时会自动生成 SDK：bitbake core-image-minimal -c populate_sdk，产出 poky-glibc-x86_64-core-image-minimal-...-toolchain.sh。安装后 source environment-setup-*，环境变量 CC、CXX、SYSROOT 自动指向目标架构。此时编译一个测试程序：

$CC hello.c -o hello
file hello
# 期望输出：ELF 64-bit LSB executable, x86-64, ... dynamically linked

注意 Ryzen Embedded 是 x86-64 架构，交叉编译工具链本质是“同架构但不同 sysroot”的 SDK，与 ARM 的跨架构编译不同。最容易踩的坑是宿主机 glibc 版本高于目标 rootfs，导致运行时 GLIBC_2.34 not found。判断方法是 $CC -print-sysroot 指向 SDK 内的 sysroot，而不是 /。

四、调试串口与 JTAG 连接

串口是首要调试通道。Ryzen Embedded 参考板一般把 SoC 的 UART0 引出为 3-pin 排针（GND/TX/RX），电平 3.3 V TTL，需用 USB-TTL 转换器（如 CP2102、FT232）接到主机。连接时 TX↔RX 交叉，GND 共地，波特率通常为 115200 8N1。上电后应能看到 AGESA 与 UEFI 输出；若全是乱码，先核对波特率，再检查是否误接了 RS-232 电平。

# Linux 主机侧
sudo picocom -b 115200 /dev/ttyUSB0
# 或
sudo minicom -D /dev/ttyUSB0 -b 115200

JTAG 用于串口无输出时的底层诊断，例如 SoC 卡在 AGESA 内存初始化阶段。Ryzen Embedded 通常使用 20-pin 或 10-pin JTAG 排针，需配合 AMD 提供的 OpenOCD 配置或专用调试器。JTAG 能读取 CPU 寄存器、内存映射和 PCIe 配置空间，是判断“是硬件没起来还是固件没跑”的关键手段。连接前务必确认目标板已断电，避免热插拔损坏调试器。

五、上电验证的判据

环境搭好后，用一条最小闭环验证：串口能看到 UEFI 输出 → 内核启动日志出现 Linux version 5.15.74 → 登录后 uname -r 与 VERSION.lock 一致 → 交叉编译的 hello 程序能在目标板运行且 ldd 不报缺失库。四项全过，说明 BSP、发行版、工具链、调试通道四层已经对齐，可以进入驱动与 I/O 集成阶段。