3. SMBIOS与UEFI/BIOS的关系
在开发与调试SMBIOS时，最容易踩坑的地方并不是结构体字段填错，而是对“它什么时候被创建、由谁创建、被谁消费”缺乏整体认识。SMBIOS并不是操作系统凭空生成的，它本质上是固件在启动过程中构建并交付给OS的一张“硬件自述表”。理解它与UEFI/BIOS、ACPI、DMI之间的关系，是后续定位表缺失、字段错乱、版本不匹配等问题的前提。
一、核心原理：SMBIOS在固件启动链路中的位置
传统BIOS与UEFI在启动流程上差异很大，但两者都必须完成同一件事：在把控制权交给操作系统之前，把平台硬件信息整理成标准结构，放到OS可以找到的物理内存区域。SMBIOS就是这套标准结构之一。
在传统BIOS中，POST阶段由各个硬件模块（内存、PCI、SMBus等）分别收集信息，最后由SMBIOS模块统一组装成Entry Point Structure（EPS）和若干Structure表，通常放在0xF0000段附近。在UEFI中，这一过程被拆分为多个DXE驱动和Protocol：平台驱动负责采集，SMBIOS DXE Driver负责组装，最终通过SMBIOS Protocol和配置表把EPS地址传递给OS。
二、固件启动流程与SMBIOS生成时机
以UEFI为例，典型启动阶段与SMBIOS相关的动作如下：
- SEC/PEI阶段：完成最早期硬件初始化，此时内存尚不完整，不生成SMBIOS。
- DXE阶段：各硬件驱动加载，SMBIOS DXE Driver被调度，开始收集Type 0/1/2/3/4/7/16/17/19等结构。
- BDS阶段：启动设备选择，SMBIOS表基本定型，但部分OEM字段可能仍会被平台策略覆盖。
- TSL/RT阶段：通过gEfiSmbiosProtocolGuid或SMBIOS配置表把EPS地址写入已知位置，供OS读取。
传统BIOS则通常在POST后期由SMBIOS模块一次性生成，生成时机相对集中，但可调试性较差。无论哪种方式，SMBIOS的生成都发生在“OS引导之前”，这是排查问题的第一条时间线。
UEFI启动链路（简化）：
SEC → PEI → DXE → BDS → TSL → OS Loader
↑
SMBIOS DXE Driver
采集/组装/发布 EPS
三、SMBIOS与ACPI、DMI的关系
很多初学者会把SMBIOS、ACPI、DMI混为一谈，实际上三者定位不同：
- SMBIOS：描述“机器里有什么”，如主板、CPU、内存条、机箱、BIOS版本等，偏静态资产信息。
- ACPI：描述“机器如何工作”，如电源管理、设备枚举、中断路由、热插拔等，偏运行时行为。
- DMI：是SMBIOS在Windows语境下的旧称，微软早期用DMI指代这套接口，如今DMI与SMBIOS基本可视为同一事物的两种叫法。
因此，SMBIOS与ACPI是并列关系，不是包含关系；DMI则是SMBIOS的历史别名。调试时若在Windows下看到“DMI信息”，本质上读的就是SMBIOS表。
四、案例场景：一次“内存条信息缺失”的排查
某项目在Windows下用wmic memorychip get只能看到一条内存，但实际插了两条。排查路径如下：
- 先在UEFI Shell下用
smbiosview -t 17查看Type 17结构数量，确认固件侧是否只生成了1条。 - 结果发现固件侧确实只有1条，说明问题不在OS，而在SMBIOS DXE Driver的内存采集逻辑。
- 进一步检查发现，该平台在DXE阶段只遍历了第一个SMBus通道，第二条内存挂在第二个通道上，未被采集。
- 修复采集逻辑后，Type 17数量恢复为2，OS侧同步正常。
五、常见误区与复盘
| 误区 | 实际情况 | 正确做法 |
|---|---|---|
| SMBIOS由OS生成 | OS只读取，不生成 | 问题定位到固件DXE阶段 |
| SMBIOS就是ACPI | 两者并列，职责不同 | 资产信息查SMBIOS，行为查ACPI |
| DMI是另一种表 | DMI是SMBIOS旧称 | Windows下DMI即SMBIOS |
| 表生成后不会变 | BDS阶段仍可能被OEM覆盖 | 在TSL前确认最终内容 |
总结来看，SMBIOS是固件启动链路中“硬件信息交付”的关键一环：它在DXE阶段被生成，在TSL/RT阶段通过EPS交付给OS；它与ACPI并列，与DMI同义。掌握这条时间线和三者关系，后续无论是分析表结构、定位字段异常，还是做跨平台兼容，都能快速锁定问题所在的阶段与模块。