📚 课程目录第4章固件版本命名与发布节奏

4. 固件版本命名与发布节奏

在 EPYC 服务器的生命周期里，固件版本号不是一串随手递增的数字，而是一份“可读的合同”：它告诉你这份固件属于哪个平台代际、基于哪条代码分支、修复了什么、能否与当前 BIOS、BMC、CPU stepping 和操作系统内核共存。理解命名规则与发布节奏，是判断“该不该升、能不能升、升完会不会掉功能”的前提。

一、版本号的分层结构

AMD EPYC 固件通常以“包”的形式发布，一个发布包内包含多个可独立烧录的镜像。理解版本号，要先区分三层：

发布包版本（Package / Release ID）：形如 GenoaPI 1.0.0.8、TurinPI 1.1.0.2。这里的 Genoa/Turin 是平台代号，PI 表示 Platform Initialization 固件包，后四段数字分别对应主版本、次版本、修订号与构建号。
组件版本：包内的 SMU（System Management Unit）固件、PSP（Platform Security Processor）固件、微码补丁（Microcode Patch）、SEV 固件等各自有独立版本，例如 SMU 76.82.0、PSP 1.0.0.5C、Microcode 0xA101148。
AGESA 版本：形如 AGESA 1.0.0.C，是主板厂商集成到 BIOS 中的底层初始化代码版本，决定内存训练、PCIe 链路、CCD/IO die 初始化行为。

四段数字的语义约定通常是：主版本变更意味着架构级或安全模型级改动，可能要求配套 BIOS 与 BMC 同步升级；次版本引入新功能或新平台支持；修订号为缺陷修复与安全补丁；构建号是同一修订下的迭代构建，仅用于区分内部编译批次。因此看到 1.0.0.8 → 1.0.0.9，应理解为同一修订线上的构建推进，而非功能跃迁。

判断一份固件“新不新”，不要只看包版本末位数字。安全修复常以修订号体现，而构建号递增可能只是重新编译。应以 AMD 安全公告（AMD-SB-xxxx）与发布说明中的 CVE 列表为准。

二、发布节奏与里程碑

AMD 的 EPYC 固件发布并非固定日历周期，而是由三类事件驱动：平台首发（Launch）、季度性维护（Sustaining Release）、安全响应（Security Advisory）。平台首发时发布首个 PI 包，随后进入约每季度一次的维护节奏；一旦出现高危漏洞，则可能插入计划外发布。

典型里程碑包括：

ES/QS 阶段：面向 OEM 与早期合作方的预发布固件，版本号常带 ES 或 QS 后缀，不建议生产使用。
Production Release：正式量产版本，进入 OEM 的 BIOS 集成流程，通常滞后 AMD 发布 4～8 周。
Sustaining Update：季度维护包，修复非安全问题、提升兼容性。
Security Patch：针对 CVE 的紧急修复，可能只更新 PSP/SMU 组件而不改变包主版本。
EOL（End of Life）：平台停止维护，不再发布新固件，仅保留历史版本下载。

下图展示了从 AMD 发布到最终上线的一条典型固件流转链，以及各环节的版本形态与验证关注点：

三、兼容性矩阵怎么读、怎么用

兼容性矩阵是固件升级决策的核心依据。它把“固件包版本—组件版本—最低 BIOS 要求—平台 stepping—状态”放在同一张表里。使用时按以下顺序核对：

确认 CPU stepping：通过 lscpu 或 BMC 的 CPU 信息页读取 stepping 值，例如 Genoa B0 与 B1 对固件要求不同。
确认当前 BIOS 版本：若低于矩阵中“最低 BIOS”列，必须先升 BIOS 再升固件，否则可能出现 PSP 与 BIOS 握手失败。
确认 BMC 版本：部分平台的固件更新通过 BMC 的 Update Firmware 接口下发，BMC 版本过低会导致镜像校验失败。
确认 OS 与内核：SEV-SNP、SNP 热迁移等功能依赖内核版本，例如 RHEL 9.2+ 或 Ubuntu 22.04 HWE 内核。

一个常见的误判是：看到包版本从 1.0.0.7 升到 1.0.0.8，就认为“只是小版本，风险低”。实际上 1.0.0.8 可能包含 PSP 安全修复，而 PSP 固件更新后不可回退（anti-rollback），一旦升级就无法降回旧版本。因此升级前必须确认：

是否有回退需求？若有，需在升级前记录当前版本并确认平台是否支持回退。
是否已阅读发布说明中的“Known Issues”与“Fixed Issues”。
是否在测试环境完成一轮内存训练、PCIe 枚举与 OS 启动验证。

四、实操：一次固件升级的版本核对流程

以下示例展示在 Linux 环境下核对固件版本并准备升级的关键命令。示例参数为教学假设，实际值以现场设备为准。

# 1. 查看 CPU stepping 与微码版本
lscpu | grep -E "Model name|Stepping"
grep microcode /proc/cpuinfo | head -1

# 2. 查看 BIOS 版本（需安装 dmidecode）
sudo dmidecode -s bios-version
# 输出示例：2.10

# 3. 查看 BMC 固件版本（通过 ipmitool）
sudo ipmitool mc info | grep "Firmware Revision"
# 输出示例：Firmware Revision : 3.05

# 4. 查看 PSP / SMU 版本（通过 AMD 工具或 BMC 界面）
# 示例：PSP 1.0.0.5C，SMU 76.82.0

# 5. 对照兼容性矩阵，确认目标固件包 1.0.0.8 要求：
#    最低 BIOS 2.10 → 当前 2.10，满足
#    BMC 最低 3.00 → 当前 3.05，满足
#    CPU stepping B1 → 支持

核对完成后，升级顺序建议为：先 BMC，再 BIOS，最后固件包。原因是 BMC 负责固件下发通道，BIOS 负责 AGESA 与 PSP 的初始化衔接，固件包中的 SMU/PSP 镜像需要在 BIOS 就绪后才能被正确加载。升级后通过 dmesg | grep -i amd 观察 PSP 初始化日志，确认无 PSP command failed 或 SEV firmware error 报错。

PSP 固件通常带有 anti-rollback 计数器。一旦升级到更高版本，降级回旧版本会被拒绝，表现为更新工具报“version mismatch”或“rollback not permitted”。生产环境升级前务必确认业务是否允许不可逆变更。

五、版本管理建议

把固件版本纳入配置管理数据库（CMDB），至少记录：平台代号、CPU stepping、BIOS 版本、BMC 版本、固件包版本、SMU/PSP 版本、升级日期、升级人、关联变更单号。每次季度维护窗口前，对照 AMD 发布说明与安全公告，判断是否存在需要跟进的修订。对于 EOL 状态的固件，应制定替换或隔离计划，避免长期运行在无安全补丁的版本上。