// 此模板仅供参考，如果不适用可以修改
问题描述
25.12版本上出包，环境上插着SF200HT网卡，但是BMC上没有加载出来，查看framework文件是加载成功的，但是版本号是5.00，相关对象都没有加载出来，从环境上导出的配置文件也比较奇怪，图片如下，在尝试将25.12的网卡版本为3.0的加载到环境后可以正常显示网卡，这里想问一下为什么编译出的整包会加载这样的网卡配置文件
环境信息
-
软件版本：openUBMC 25.12
-
硬件配置：S920S20
答案内容由AI生成，仅供参考：
SF200HT网卡在openUBMC 25.12版本中配置文件版本号为5.00导致未正常加载的问题分析
问题概述
在 openUBMC 25.12 版本的系统构建中，当设备环境插入 SF200HT 网卡时，BMC未能正确加载该网卡的相关对象（如 PCIENicCard_1），尽管 framework.log 显示配置文件已加载。经排查发现：
- 加载的CSR配置文件
FormatVersion和DataVersion均为 5.00 - 实际运行时网卡对象未被创建，且
PcbVersion显示为N/A - 手动使用版本为 3.0 的配置文件后，网卡可正常识别和显示
此问题的核心是：为何25.12版本出包时会加载格式版本为5.00的SF200HT网卡配置文件，而该版本反而不能正确工作
根本原因分析
1. CSR 文件版本机制与加载策略冲突
根据《硬件自发现CSR选择策略》文档及知识库内容，BMC在加载 .sr（即CSR）文件时采用如下逻辑：
比较 Eeprom 的天池版本 与 内置CSR的格式版本（默认为3.00），选择版本较高的进行加载；若版本一致再比较数据版本（DataVersion），仍一致则优先加载内置CSR。
而在 search result 的文档 #3《硬件自发现CSR选择策略》 中明确指出：
软硬件sr合并的前提是：sr的格式版本 >= 3.00 且 < 5.00（5.00 是设备树CSR版本），且存在 soft.sr 文件。
这意味着：
- 当
.sr文件的FormatVersion >= 5.00时，将不再执行软硬件合并逻辑 - 而当前 SF200HT 的配置文件版本号为
5.00，触发了“设备树CSR”路径，跳过了传统合并流程 - 导致即使物理卡存在，也无法完成完整的设备对象初始化
2. 版本号为“5.00”代表“设备树模式”，行为发生变化
从命名规范来看，FormatVersion: 5.00 表示进入了新一代 设备树驱动模型（Device Tree CSR） 模式：
- 兼容性断裂：旧版驱动框架（面向3.x格式）无法完全解析5.00版本的配置结构
- 加载路径不同：5.00版本可能依赖新的加载器（如
devicetree-loader），而当前环境可能未启用或配置不完整 - 对象生成方式变化：5.00版本可能要求通过更复杂的设备树绑定逻辑生成对象，而非直接实例化
PCIeNicCard
因此虽然 .sr 文件被“加载”，但没有触发对象实例化逻辑，导致 BMC 中无实际网卡对象。
3. 配置文件构建流程错误引入高版本模板
问题可能出在 general_hardware 或 product_bsp 包构建过程中：
- 构建系统从多个源收集
.sr文件，包括：platforms/*/sr/components/general_hardware/sr/
- 若 SF200HT 的
.sr文件被错误地替换为一个用于开发测试的 设备树版本（5.00）模板文件 - 或构建脚本自动升级了某些
.sr文件的版本号（例如通过version_bump工具） - 则最终打包进固件的是一个不兼容当前运行时环境的配置文件
这一点也与“手动替换为3.0版本即可工作”完全吻合。
4. SF200HT 确实支持但需匹配正确版本
从 KG 数据可验证：
"entity1": "SF400T", "entity2": "bmc.dev.PCIeCard"
"entity1": "Net迅1GE网卡", "entity2": "bmc.dev.PCIeCard"
说明 北京旺讯科技（Netswift）的网卡（如SF系列）已注册为 bmc.dev.PCIeCard 实现类。
此外，Document Chunk #10 提及：
非NVIDIA GPU卡加载依赖
PcieAddrInfo和四元组信息查询加载
同理，SF200HT 这类 PCIe NIC 卡也依赖于正确的四元组信息 + .sr 文件拼接机制 才能完成加载。
但版本为 5.00 的 .sr 文件已经脱离传统四元组加载机制，进入设备树模型，导致链路断裂。
解决方案建议
方案一：确认并回退至兼容版本（临时解决）
- 定位 SF200HT 对应的
.sr文件（通常位于/opt/bmc/sr/<VendorId>_<DeviceId>.sr或含BomID） - 检查其
FormatVersion是否为5.00 - 将其替换为已验证可用的
FormatVersion: 3.0的版本 - 重新打包固件并验证
方案二：统一构建流程中的 .sr 文件版本控制（根本解决）
-
在构建系统中增加
.sr文件版本校验规则- 拒绝打包
FormatVersion >= 5.00的.sr文件，除非明确启用设备树模式 - 增加日志提示：“检测到高版本CSR，请确认是否启用设备树支持”
- 拒绝打包
-
分类管理
.sr文件路径sr/ ├── legacy/ # FormatVersion < 5.00，用于传统加载器 ├── devicetree/ # FormatVersion >= 5.00，仅用于设备树环境 └── common/ -
确保
general_hardware仓中 SF200HT 的.sr使用长期维护的稳定版本
方案三：升级运行时以支持设备树模式（长期演进）
若目标是支持 FormatVersion=5.00，则需确保：
- BMC 运行时组件支持设备树解析（
csr-devicetree-parser） - 启用了
soft.sr合并机制（如果仍需要） hello_openubmc或类似服务支持动态加载设备树节点- 验证日志中是否有
Failed to bind device tree node类错误
否则，强行使用5.00版本只会导致功能缺失
结论
| 项目 | 内容 |
|---|---|
| 问题本质 | 构建系统打包了不兼容的 .sr 配置文件（FormatVersion=5.00），而当前 openUBMC 25.12 运行时仍基于传统加载机制 |
| 根本原因 | FormatVersion=5.00 触发设备树加载路径，跳过软硬件合并，导致无法生成设备对象 |
| 技术依据 | 《硬件自发现CSR选择策略》规定：仅当 3.0 ≤ FormatVersion < 5.0 才执行合并逻辑 |
| 解决方案 | 短期：使用已验证的 v3.0 .sr 文件重新打包长期：规范 .sr 版本管理，或升级运行时支持设备树 |
| 风险提示 | 强行使用5.00版本而不升级运行时，会导致设备识别失败，即使日志显示“加载成功” |
建议操作清单
- 检查构建产物中
SF200HT的.sr文件版本号 - 比对
3.0与5.00两个版本的内容差异（特别是Unit.Type,ManagementTopology等） - 修改构建流程，限制非设备树环境下不得引入
≥5.00的.sr文件 - 提交 issue 至构建团队：要求对
.sr文件加入版本白名单控制 - 如确需使用新格式，请同步升级
csr-loader组件并开启设备树功能
推荐做法：在 openUBMC 25.12 LTS 环境中，应继续使用
FormatVersion=3.0的 CSR 文件，直到正式发布设备树支持说明。
相关链接：
这个sr的版本号变更构建是不感知的。
5.0是走南向设备树加载，你是用最新manifest本地出包吗
合入该PR已经解决：修复南向组件编译构建问题-manifest-AtomGit | GitCode