4. 参考设计与评估板快速启动

在 Ryzen Embedded 产品化交付流程中，参考设计（Reference Design）、评估板（EVB）与 BSP 包是三条并行的起点。参考设计给出的是“电路与布局已经验证过”的硬件基线，评估板给出的是“可以立刻上电运行”的物理载体，BSP 包给出的是“让 SoC 在自家板子上跑起来”的软件基线。三者配合，才能把一颗 Ryzen Embedded SoC 从“芯片手册上的器件”变成“可调试、可验证、可迭代的开发平台”。本节以 AMD Ryzen Embedded V2000/R2000 系列常见的 EVB 与 BSP 为例，走一遍从开箱到基础外设验证的完整路径。

一、先分清三份材料各自解决什么问题

很多团队拿到 EVB 后直接上电，结果卡在串口无输出，回头才发现 BSP 版本与板卡版本不匹配。因此第一步不是插电，而是把三份材料对齐：

• 参考设计：通常以 PDF 原理图 + 设计检查表 + 关键器件 BOM 形式提供，重点看电源树、DDR4 拓扑、PCIe 通道分配、显示接口与 EC（嵌入式控制器）连接。它决定“硬件能不能跑”。
• 评估板：AMD 或第三方（如 Advantech、DFI、Kontron）提供的 EVB，板上已集成 SoC、DDR、eMMC、调试串口、DP/HDMI、USB、M.2、千兆网口等。它决定“现在能不能跑”。
• BSP 包：包含 UEFI/BIOS 固件、AGESA、EC 固件、Linux 内核与驱动、Yocto/Ubuntu 根文件系统、烧录工具。它决定“跑起来之后能不能用”。

三者版本必须交叉确认。例如 EVB 丝印为 V2000-EVB Rev 1.2，则 BSP 包应选择对应 Rev 1.2 的固件与设备树，而不是 Rev 1.0 的旧包。版本错配最常见的表现是：串口能出 UEFI 日志，但内核启动到 PCIe 枚举时挂死，或 eMMC 识别为 0MB。

二、上电前的物理检查与串口连接

上电前先做三项检查：电源适配器电压与极性是否与 EVB 标注一致（常见为 12V/19V DC Jack 或 ATX 4-pin）；DDR 与散热片是否压紧；跳线帽是否处于“正常启动”位置而非“烧录/恢复”位置。确认后连接调试串口。

Ryzen Embedded EVB 通常提供两种串口：SoC 调试串口（UEFI + 内核控制台，多为 3.3V TTL，波特率 115200 8N1）和 EC 调试串口（可选，用于 EC 固件日志）。使用 USB-to-TTL 模块时，务必确认电平为 3.3V，不要直接接 5V TTL，否则可能损坏 SoC 调试引脚。接线为：模块 TX → EVB RX，模块 RX → EVB TX，GND 共地。

在 Linux 主机上确认串口设备并打开：

ls /dev/ttyUSB*
# 假设为 /dev/ttyUSB0
sudo picocom -b 115200 /dev/ttyUSB0
# 或使用 minicom
sudo minicom -D /dev/ttyUSB0 -b 115200

此时 EVB 尚未上电，终端应为空白。上电后若看到 UEFI 版本号、AGESA 版本、DDR 容量等信息，说明 SoC 已正常启动到固件阶段。

三、从 UEFI 到操作系统的启动链路

Ryzen Embedded 的启动链路可以概括为：SoC 内部 ROM → UEFI 固件（含 AGESA 内存初始化）→ 引导设备选择 → 内核与 initramfs → 根文件系统 → 用户空间。BSP 包中的固件通常已经配置好默认启动顺序，但首次启动仍建议进入 UEFI Setup 确认关键项。

常见需要确认的 UEFI 设置包括：启动模式（UEFI only / Legacy）、eMMC 或 NVMe 是否被识别、显示输出优先级、串口重定向是否开启。若使用 Yocto 生成的镜像，通常通过 dd 写入 SD 卡或 eMMC：

# 示例：将 BSP 镜像写入 SD 卡（假设为 /dev/sdX，务必确认设备名）
sudo dd if=amd-v2000-bsp-image.wic of=/dev/sdX bs=4M status=progress conv=fsync

写入后插入 EVB，上电，串口应依次出现 UEFI 日志、GRUB 或直接内核解压日志、systemd 启动日志，最终停在登录提示符。若卡在 Starting kernel ... 之后无输出，优先检查设备树是否匹配、串口控制台参数是否为 console=ttyS0,115200n8。

四、基础外设验证：从“能启动”到“能用”

系统进入登录提示符后，不要急着跑应用，先按“显示 → USB → 网络 → 存储 → 音频 → 温度”的顺序做一轮基础验证。这一轮验证的目的不是测性能，而是确认 BSP 中的驱动与设备树配置与 EVB 实际硬件一致。

显示输出：连接 DP 或 HDMI 显示器，执行 modetest 或直接查看 /sys/class/drm/ 下的连接器状态。若显示器无输出但串口正常，检查内核命令行是否包含 amdgpu.dc=1 或对应显示驱动参数。

USB：插入 U 盘，观察 dmesg | tail 是否出现 usb 1-1: new high-speed USB device 以及 sd 0:0:0:0: [sda]。若只有 USB 设备枚举而无块设备，通常是 USB 存储驱动未编入内核。

网络：ip link 确认网口为 UP，udhcpc -i eth0 或 dhclient eth0 获取地址，再 ping 网关。若链路灯亮但无法获取 IP，检查设备树中 PHY 地址与复位 GPIO 是否正确。

存储：lsblk 查看 eMMC/NVMe 是否出现，dd 写入 100MB 测试文件并读回校验，确认无 I/O error。

温度与风扇：sensors 读取 SoC 温度，cat /sys/class/hwmon/hwmon*/pwm1 确认风扇 PWM 可调。若温度读数异常（如固定 0 或 255），检查 EC 与 SoC 的 SMBus/I2C 连接。

五、把首次启动结果固化为基线记录

首次启动验证完成后，建议立即记录一份基线信息，作为后续产品化迭代的对照。至少包含：EVB 型号与版本、BSP 包版本、UEFI/AGESA 版本、内核版本、设备树文件名、串口日志完整保存、各外设验证结果与异常现象。这份记录在后续遇到“换了一块板子就跑不起来”或“升级 BSP 后网口失效”时，能快速定位是硬件差异还是软件回归。

完成本节的上电、串口调试、系统启动与基础外设验证后，EVB 已经成为一个可用的开发平台。接下来无论是移植到自研板卡，还是进行显示、PCIe、AI 加速等专项验证，都可以以这份基线为起点，逐步替换硬件与软件模块，把参考设计的“可跑”转化为产品化的“可靠”。