l00012320
(kunlun_luzhanghui)
1
问题背景
适配RAID扣卡。
RAID卡相关的配置都是跟PCIeDevice对象绑定的，但是适配RAID扣卡时，相关的PCIe信息不是很好获取和配置，想了解下能否去掉PCIe相关配置，仅配置RAID相关的信息。
所做的尝试
一般的RAID卡配置：
Controller对象必须等到名称加载完毕，而且必须以PCIe Card开头。
但是PCIeDevice的Slot是根据PCIeAddrInfo对象，根据拓扑建立关系，动态分配而来，并非SR配置写死。这就导致了没有BDF上报的RAID扣卡无法获取SlotID，从而无法加载Controller对象，需要在这里增加特殊的处理逻辑。
另外RAID扣卡显示为PCIe卡本身也不太合理，这个before_add_object有什么额外的背景吗？
目前的修改方式：
直接去掉PCIeDevice的关联，将槽位号相关的内容都改为${Slot}直接获取。
##主要疑问
- before_add_object为什么要关联DeviceName为PCIe Card，不是PCIe卡的RAID卡不进行考虑吗？
- PCIeDevice对象整个去掉，会不会影响到哪些功能？因为RAID卡的配置涉及到pcie_device组件和storage组件，分析的可能不够全面，不太确定去掉PCIeDevice以及其它PCIeCard对象有什么影响，这个要帮忙看一下。
答案内容由AI生成，仅供参考：
RAID扣卡适配问题分析与建议
根据您提供的问题背景和尝试过程，当前在适配RAID扣卡时遇到的核心矛盾是：Controller_1对象的加载依赖于PCIeDevice_1的DeviceName必须以"PCIe Card"开头且槽位有效，但RAID扣卡因无BDF上报导致PCIe信息无法动态获取，从而无法完成PCIeDevice的初始化。
以下将从架构原理、适配流程和解决方案三个方面进行系统性分析与建议。
一、问题根源分析
1. 当前加载依赖链路
根据知识库内容和代码逻辑，RAID卡组件的加载遵循如下顺序：
vpd → pcie_device（加载PCIeDevice）→ storage（加载Controller）
vpd模块：负责通过硬件拓扑识别PCIe设备的存在（基于BOM+ID+AUXID），并生成或激活对应SR文件。pcie_device模块：基于BIOS上报的BDF信息，查询PCIe设备四元组（Vendor ID, Device ID, SubVendor ID, SubDevice ID），动态设置PCIeDevice对象属性（如SlotID, DevBus等）。storage模块：在PCIeDevice对象完全建立后，通过RefChip引用初始化Controller对象，获取RAID控制器状态与配置。
关键点：Controller对象的初始化强依赖PCIeDevice存在且DeviceName命名规范。如文档中所述：
if not prefix_equal(object.DeviceName, "PCIE Card") ...
若PCIeDevice未创建或命名不规范，则Controller将无限等待，导致适配失败。
二、是否可以去掉PCIe相关配置？
结论：不推荐直接去除PCIe相关配置
虽然您希望仅配置RAID相关信息以简化流程，但从系统架构设计角度，PCIeDevice不是可选装饰，而是硬件自发现和管理的基础单元，原因如下：
| 原因 |
说明 |
 硬件管理框架统一性 |
openUBMC所有扩展设备均通过PCIeDevice类统一建模。无论是RAID卡、网卡还是GPU，都需先作为PCIe设备被识别，才能进一步加载功能控制器。 |
 拓扑关系绑定 |
PCIeDevice承载了设备物理位置（Slot、Socket）、链路状态（Speed、Width）、告警属性等关键信息，是硬件故障定位、热插拔检测、资源调度的依据。 |
 数据关联桥梁 |
Controller_1.RefChip需通过PCIeDevice.SlotID或GroupPosition反向查找对应的芯片路径，若缺少此层映射，storage无法确定RAID芯片归属。 |
因此，不能完全绕过PCIe配置。但可以通过模拟/预置PCIe信息的方式实现对无BDF上报RAID扣卡的支持。
三、可行解决方案建议
方案一：静态预置PCIeDevice，跳过BDF依赖（推荐）
适用于：RAID扣卡固定安装、无BDF上报、BIOS不可控的场景。
实施步骤：
-
配置IdentifyMode = 1（固定ID模式）
- 在Riser卡SR中配置
Connector_PCIE_SLOTX时不依赖BIOS上报，而是手动指定Id和AuxId。
- 示例：
"Connector_PCIE_SLOT3": {
"Bom": "14140130",
"Slot": 3,
"Position": 3,
"Presence": 1,
"Id": "100010e2", // VendorID(16进制)+DeviceID
"AuxId": "10004010", // SubVendorID+SubDeviceID
"IdentifyMode": 1,
"Container": "Component_RiserCard",
"Type": "PCIe"
}
-
确保CSR文件名为 BOM_ID_AUXID.sr
如：14140130_100010e2_10004010.sr，使vpd能正确加载该文件。
-
在SR中显式定义PCIeDevice并写死Slot
"PCIeDevice_1": {
"DeviceName": "PCIe Card 3 (9500-16i)",
"FunctionClass": 1,
"SlotID": 3,
"DevBus": 0,
"DevDevice": 3,
"DevFunction": 0,
"SocketID": 0,
"GroupPosition": "PCIeDevice_3",
"Container": "${Container}"
}
-
配置PcieAddrInfo传递静态BDF信息
即使BIOS不主动上报，也可由BMC主动模拟传递：
"PcieAddrInfo_1": {
"SocketId": 0,
"Bus": 0,
"Device": 3,
"Function": 0,
"SlotId": 3
}
-
触发pcie_device加载逻辑
方案二：修改Controller加载逻辑（需代码变更）
修改建议点：
风险提示：这类修改属于侵入式变更，可能影响其他场景兼容性，建议在私有分支维护。
四、验证与调试建议
1. 日志检查项
framework.log：查看SR是否成功加载。hwdiscovery.log：确认Connector_PCIE_SLOTX实例化成功。storage.log：观察controller_object.lua是否进入add_controller_to_link_topo流程。app.log：搜索[BizTopoLoader] Load PCIeCard打印。
2. DBus查询命令
# 查看PCIe设备是否加载
busctl --user tree bmc.kepler.hwdiscovery | grep PCIe
# 查询RAID控制器状态
busctl --user introspect bmc.kepler.storage /bmc/kepler/Systems/1/Storage/Controllers/
3. 关键配置文件验证
| 文件 |
检查项 |
vpd/sr/*.sr |
文件名是否为 BOM_ID_AUXID.sr |
PCIeDevice定义 |
FunctionClass=1, DeviceName包含槽位 |
PcieAddrInfo |
包含正确的SlotId, Bus, Device, Function |
Controller_1.TypeId |
确保为系统已注册类型（如20），否则需在common_def.lua中注册回调库 |
五、总结与建议
| 项目 |
建议 |
| 是否可去PCIe配置 |
不可移除，PCIeDevice为必选项 |
| 推荐解决方案 |
使用IdentifyMode=1静态预置PCIeDevice信息 |
| 是否需改代码 |
尽量避免；若必须，建议优化before_add_object校验逻辑 |
| 适配重点 |
确保vpd→pcie_device→storage链路完整 |
最终建议路径：
使用静态ID + 手动定义PCIeDevice + 注入BDF的方式完成适配，既能保持架构一致性，又能解决无BDF上报问题。待后续支持MCTP/i2c带外通信后，再逐步过渡到标准流程。
相关链接：
- raid卡适配指导
- 9500HBA卡web无法获取信息
- raid卡适配出现问题
- RAID卡配置指南
- RAID卡常见问题指南 | 文档中心 | openUBMC
1.openubmc目前没适配过RAID扣卡，before_add_object加这个判断是为了需要主键确定后再分发对象，获取了主键才能正确从持久化里获取数据，如果加了扣卡，需要根据起名，这里适配逻辑。
2.PCIeDevice去掉了应该获取不到BDF和一些PCIE的告警缺失。
