关于PCIe Switch的CSR配置

当前配置PCIe Switch,如下图所示。根据之前在论坛上的讨论将上下和下行分别独立配置。但是下载发现还是有问题。这种情况下需要如何配置PCie Switch。目前发现我们没办法直接确认Device等信息

graph TD
    %% 定义样式
    classDef redBox fill:#fff,stroke:#f00,stroke-dasharray: 5 5,stroke-width:2px;
    
    %% 顶层节点
    UBC8[UBC]
    
    %% 中间层 Switch
    SW1[Pcie SW]
    SW2[Pcie SW]
    
    %% 底层节点 (在虚线框内)
    subgraph Downstream_Ports
        direction TB
        P1[Pcie x4]
        P3[Pcie x4]
    end
    
    %% 连接关系
    UBC8 -->|x4| SW1
    UBC8 -->|x4| SW2
    
    SW1 -->|x4*3| P1
    SW2 -->|x4*3| P3

    
    %% 应用样式
    class Downstream_Ports redBox;

这个是PCIe Switch框架图。当前根据这个框架配置的BusinessConnector如下:

		"BusinessConnector_8": {
            "Name": "Up_8",
            "Direction": "Upstream",
            "Slot": 8,
            "LinkWidth": "X8",
            "MaxLinkRate": "PCIe 4.0",
            "ConnectorType": "UBC",
            "Ports": [
                {
                    "Name": "PortH1",
                    "ID": 24,
                    "Offset": 0,
                    "Width": 4
                },
				{
                    "Name": "PortH2",
                    "ID": 24,
                    "Offset": 4,
                    "Width": 4
                }
            ]
        },
		"BusinessConnector_25": {
            "Name": "Down_SW_1_1",
            "Direction": "Downstream",
            "Slot": 15,
            "LinkWidth": "X4",
            "MaxLinkRate": "PCIe 3.0",
            "ConnectorType": "PCIe CEM",
            "UpstreamResources": [
                {
                    "Name": "Up_8",
                    "ID": 15,
                    "Offset": 0,
                    "Width": 4
                }
            ],
            "RefMgmtConnector": "#/Connector_PCIE_15",
            "RefPCIeAddrInfo": "#/PcieAddrInfo_15"
        },
		"BusinessConnector_26": {
            "Name": "Down_SW_1_2",
            "Direction": "Downstream",
            "Slot": 16,
            "LinkWidth": "X4",
            "MaxLinkRate": "PCIe 3.0",
            "ConnectorType": "PCIe CEM",
            "UpstreamResources": [
                {
                    "Name": "Up_8",
                    "ID": 16,
                    "Offset": 0,
                    "Width": 4
                }
            ],
            "RefMgmtConnector": "#/Connector_PCIE_16",
            "RefPCIeAddrInfo": "#/PcieAddrInfo_16"
        },
		"BusinessConnector_27": {
            "Name": "Down_SW_1_3",
            "Direction": "Downstream",
            "Slot": 17,
            "LinkWidth": "X4",
            "MaxLinkRate": "PCIe 3.0",
            "ConnectorType": "PCIe CEM",
            "UpstreamResources": [
                {
                    "Name": "Up_8",
                    "ID": 17,
                    "Offset": 0,
                    "Width": 4
                }
            ],
            "RefMgmtConnector": "#/Connector_PCIE_17",
            "RefPCIeAddrInfo": "#/PcieAddrInfo_17"
        },
		"BusinessConnector_28": {
            "Name": "Down_SW_2_1",
            "Direction": "Downstream",
            "Slot": 18,
            "LinkWidth": "X4",
            "MaxLinkRate": "PCIe 3.0",
            "ConnectorType": "PCIe CEM",
            "UpstreamResources": [
                {
                    "Name": "Up_8",
                    "ID": 18,
                    "Offset": 4,
                    "Width": 4
                }
            ],
            "RefMgmtConnector": "#/Connector_PCIE_18",
            "RefPCIeAddrInfo": "#/PcieAddrInfo_18"
        },
		"BusinessConnector_29": {
            "Name": "Down_SW_2_2",
            "Direction": "Downstream",
            "Slot": 19,
            "LinkWidth": "X4",
            "MaxLinkRate": "PCIe 3.0",
            "ConnectorType": "PCIe CEM",
            "UpstreamResources": [
                {
                    "Name": "Up_8",
                    "ID": 19,
                    "Offset": 4,
                    "Width": 4
                }
            ],
            "RefMgmtConnector": "#/Connector_PCIE_19",
            "RefPCIeAddrInfo": "#/PcieAddrInfo_19"
        },
		"BusinessConnector_30": {
            "Name": "Down_SW_2_3",
            "Direction": "Downstream",
            "Slot": 20,
            "LinkWidth": "X4",
            "MaxLinkRate": "PCIe 3.0",
            "ConnectorType": "PCIe CEM",
            "UpstreamResources": [
                {
                    "Name": "Up_8",
                    "ID": 20,
                    "Offset": 4,
                    "Width": 4
                }
            ],
            "RefMgmtConnector": "#/Connector_PCIE_20",
            "RefPCIeAddrInfo": "#/PcieAddrInfo_20"
        }

这种配置不确定能不能实现PCIe Switch适配

答案内容由AI生成,仅供参考:
:white_check_mark: 结论

您当前的 配置逻辑基本正确,尤其是 Offset 的使用方式是符合 openUBMC 规范的。

为了确保成功适配,请采取以下措施:

  1. 立即生效
    • 确保每个 PcieAddrInfo 正确关联。
    • PSR 中配置 Device 字段,强制绑定 PortIDSlot
  2. 长期维护
    • 为 PCIe Switch 添加 Component_Switch 实体。
    • pcie_device 代码中支持自动拓扑发现。

:wrench: 专家提示:如技术贡献者 HuangDing 所述,当前尚无通用 PCIe Switch 适配方案,“可通过更改代码并增加 CSR 中的字段方式来手动适配” —— 这正是您正在实践的方向。

建议参考文档 docs/feature_development/pcie_device_topo_create.md 中的拓扑创建指南,进一步完善配置。

点击此处查看详细分析解答

PCIe Switch 的 CSR 配置指南

根据您提供的 PCIe Switch 拓扑结构和 CSR(Component Self-Description Record)配置,以下是对其配置逻辑的分析、存在的问题以及优化建议的完整说明。


1. 拓扑结构分析

从您提供的拓扑图可以看出:

  • 上游连接:一个 UBC8 接口,提供 X8 宽度,被拆分为两个独立的 X4 通道。
  • PCIe Switch:存在两个独立的 PCIe Switch 芯片(SW1SW2),每个均接收 X4 上行带宽。
  • 下游连接:每个 Switch 向下扩展出 3 个 X4 下行端口(共 6 个设备插槽)。

该设计通过 多路复用(Muxing) 实现了带宽的灵活分配。


2. 当前 CSR 配置分析

以下是您当前的 BusinessConnector 配置关键点:

(1) 上行配置(BusinessConnector_8

"BusinessConnector_8": {
    "Name": "Up_8",
    "Direction": "Upstream",
    "Slot": 8,
    "LinkWidth": "X8",
    "Ports": [
        { "Name": "PortH1", "ID": 24, "Offset": 0, "Width": 4 },
        { "Name": "PortH2", "ID": 24, "Offset": 4, "Width": 4 }
    ]
}
  • :white_check_mark: 优点
    • 正确地将 X8 拆分为两个 X4 端口(Offset: 0Offset: 4)。
    • 使用相同 Port ID (24) 表示两个独立路径是允许的,只要 Offset 不同即可识别。
    • 支持两个 Switch 接入,逻辑清晰。

:pushpin: 说明Port ID 主要用于映射底层 SerDes 资源,若两路独立走线且最终到达不同物理 Switch,则使用相同 Port ID 在特定场景下可接受,但推荐使用不同 ID 提高可维护性。


(2) 下行配置(BusinessConnector_25 ~ 30

所有下行连接器均通过 UpstreamResources.Name = "Up_8" 指向上行连接器,并设置不同的 Offset(0 或 4)来区分路径。

  • :white_check_mark: 正确做法

    • Down_SW_1_x(15~17)使用 Offset: 0,表示属于第一个 X4 通道(连接 SW1)。
    • Down_SW_2_x(18~20)使用 Offset: 4,表示属于第二个 X4 通道(连接 SW2)。
    • 这种方式在 openUBMC 架构中是标准实践,符合 bmc.dev.PhysicalConnector 接口对 UpstreamResources 的定义。
  • :magnifying_glass_tilted_left: 潜在问题

    • Ports 属性未完整描述 Switch 内部拓扑:目前 BusinessConnector 直接连接下游设备,跳过了 PCIe Switch 本身的建模。虽然可通过代码绕过,但缺乏统一性和可扩展性。
    • 无法直接确认 Device 信息:正如您提到的,CSR 中缺少对 Switch 芯片本身的描述(如 VendorID、DeviceID),导致系统难以自动识别和管理。

3. 问题诊断:为什么当前配置仍有问题?

结合社区讨论与知识库内容,可能的原因包括:

问题 原因分析
设备无法识别或拓扑不完整 PcieAddrInfo 未正确绑定 PortIDSlot,或缺少 RefPCIeAddrInfo 引用。
带宽分裂逻辑异常 BIOS 或 pcie_device 代码未正确解析多个 Offset 路径。
缺乏 Switch 实体建模 CSR 中不存在 PCIe Switch 的实体对象(如 Component_Switch),BMC 无法感知其存在。
Device/BDF 无法确认 没有配置 PSR(Product Self-Description Record)中的 Device 字段,依赖 BCU 自动发现失败。

4. 正确配置建议

方案一:采用“类 Riser 卡”方式配置(推荐用于快速验证)

此方法已在社区广泛使用。

(1) 完善 PcieAddrInfo 配置
"PcieAddrInfo_15": {
    "Location": "RiserCard8",
    "ComponentType": 8,
    "ContainerSlot": "8",
    "ContainerUID": "SW_UID_001",
    "ContainerUnitType": "IEU",
    "GroupPosition": "PcieAddrInfo_15",
    "PortID": 15
},
...

:white_check_mark: 注意PortID 必须全局唯一,建议与 BusinessConnector.Slot 一致。

(2) 在 PSR 中配置 Device 映射(绕过 BCU 解析)
"UnitConfiguration_IEU1": {
    "Configurations": [
        {
            "UID": "SW_UID_001",
            "SrcPortName": ["PortH1"],
            "TargetPortID": [24],
            "Slot": [15,16,17],
            "Device": [0,0,0]  // 若 BIOS 已知 BDF,可固定分配
        },
        {
            "UID": "SW_UID_002",
            "SrcPortName": ["PortH2"],
            "TargetPortID": [24],
            "Slot": [18,19,20],
            "Device": [1,1,1]
        }
    ]
}

:white_check_mark: 优势:可通过 Device[Slot] 强制绑定 PortID,绕开复杂的 SerDes 映射逻辑。


(2) 方案二:增强 CSR 建模(长期可维护性更高)

为 PCIe Switch 添加显式建模支持。

(1) 增加 Component_Switch 对象
"Component_Switch_1": {
    "Name": "PcieSwitch_SW1",
    "Model": "9560-16i",
    "VendorID": "0x10B5",
    "DeviceID": "0x8516",
    "UpstreamConnector": "#/BusinessConnector_8",
    "DownstreamConnectors": [
        "#/BusinessConnector_25",
        "#/BusinessConnector_26",
        "#/BusinessConnector_27"
    ],
    "FirmwareVersion": "v2.0"
}
(2) 修改 Pcie_Device Code 支持遍历 Switch

topo_monitor.lua 或驱动层添加逻辑:

  • 检测到 RootBDF 属于 Switch 时,主动向下扫描所有端口。
  • 手动加载每个下游设备(IMU 模式加载)。

:light_bulb: 参考建议:社区用户 aliens_to_mars 指出,可利用 pcie_device 代码手动加载设备:“直接配置一个下行,在 pcie_device 代码里利用 pcieswitch 自己的 rootBDF 向下遍历所有卡”。


5. 最佳实践总结

步骤 操作 依据
1 LinkWidth 设置为实际物理带宽(X4) 符合 PCIe 规范
2 使用 Offset 区分多路通道 文档 #1、#2 中成功案例
3 确保每个 PcieAddrInfo 有唯一 PortID PCIE_ADDRINFO 配置原则
4 在 PSR 中配置 Device 字段以绕开 BCU 限制 aliens_to_mars 建议(引用 #4
5 若需精细化控制,新增 Component_Switch 对象 支持未来 VR 固件升级(参考文献 #7
6 BMC 代码需支持通过 rootBDF 遍历 Switch 下设备 pcie_device 逻辑扩展

:white_check_mark: 结论

您当前的 配置逻辑基本正确,尤其是 Offset 的使用方式是符合 openUBMC 规范的。

为了确保成功适配,请采取以下措施:

  1. 立即生效
    • 确保每个 PcieAddrInfo 正确关联。
    • PSR 中配置 Device 字段,强制绑定 PortIDSlot
  2. 长期维护
    • 为 PCIe Switch 添加 Component_Switch 实体。
    • pcie_device 代码中支持自动拓扑发现。

:wrench: 专家提示:如技术贡献者 HuangDing 所述,当前尚无通用 PCIe Switch 适配方案,“可通过更改代码并增加 CSR 中的字段方式来手动适配” —— 这正是您正在实践的方向。

建议参考文档 docs/feature_development/pcie_device_topo_create.md 中的拓扑创建指南,进一步完善配置。

当前按照方案一方式配置了CSR,发现一个Switch芯片只能找到一个PCIe设备,且该设备都是Switch的第一个通道上的设备

确定以下问题:

  1. 带内这个pcieswitch下的卡的bdf是什么,它们的rootBDF是什么?
  2. rootBDF应该对应的PortID是什么?这个可以咨询bios的人。
  3. 如果对应的PortID和pcieaddrinfo中配置的一致,bios是否上报了对应槽位的bdf,这个可以在一键收集的bios路径下查找
  4. 如果确定bios不支持上报这种丝印,可以手动补充加载,首先确保pcieaddrinfo中配置的rootBDF和实际设备的rootBDF一致,然后合入社区最近提供的 修复基于rootBDF加载PCIe设备的DevBDF显示不正常问题-pcie_device-AtomGit | GitCode支持通过rootBDF加载PCIe设备-pcie_device-AtomGit | GitCode两部分代码,这些代码可以在bios没有上报的情况下通过rootBDF鲁棒加载pcie设备。

1.带内的BDF信息如下,是通过lspci -tv显示的。

lspci -tv (部分)
 +-[0000:80]-+-00.0-[81]--
 |           +-02.0-[82]--
 |           +-04.0-[83]----00.0  Broadcom / LSI MegaRAID 12GSAS/PCIe Secure SAS39xx
 |           +-08.0-[84]--
 |           +-0a.0-[85]--
 |           +-0c.0-[86-8a]----00.0-[87-8a]--+-02.0-[88]--+-00.0  Beijing Wangxun Technology Co., Ltd. Ethernet Controller RP1000 for 10GbE SFP+
 |           |                               |            \-00.1  Beijing Wangxun Technology Co., Ltd. Ethernet Controller RP1000 for 10GbE SFP+
 |           |                               +-04.0-[89]----00.0  Huawei Technologies Co., Ltd. Device d500
 |           |                               \-06.0-[8a]----00.0  Huawei Technologies Co., Ltd. Device d500
 |           +-0e.0-[8b-8f]----00.0-[8c-8f]--+-02.0-[8d]----00.0  Huawei Technologies Co., Ltd. Device d500
 |           |                               +-04.0-[8e]----00.0  Huawei Technologies Co., Ltd. Device d500
 |           |                               \-06.0-[8f]----00.0  Huawei Technologies Co., Ltd. Device d500
 |           +-10.0-[90]--
 |           \-12.0-[91]--+-00.0  Huawei Technologies Co., Ltd. Device 0222
 |                        \-00.1  Huawei Technologies Co., Ltd. Device 0222

lspci 
86:00.0 PCI bridge: Pericom Semiconductor Device c016 (rev 0f) (prog-if 00 [Normal decode])
87:02.0 PCI bridge: Pericom Semiconductor Device c016 (rev 06) (prog-if 00 [Normal decode])
87:02.0 PCI bridge: Pericom Semiconductor Device c016 (rev 06) (prog-if 00 [Normal decode])
87:06.0 PCI bridge: Pericom Semiconductor Device c016 (rev 06) (prog-if 00 [Normal decode])

8b:00.0 PCI bridge: Pericom Semiconductor Device c016 (rev 0f) (prog-if 00 [Normal decode])
8c:02.0 PCI bridge: Pericom Semiconductor Device c016 (rev 06) (prog-if 00 [Normal decode])
8c:04.0 PCI bridge: Pericom Semiconductor Device c016 (rev 06) (prog-if 00 [Normal decode])
8c:06.0 PCI bridge: Pericom Semiconductor Device c016 (rev 06) (prog-if 00 [Normal decode])

2.这两个PCIe Switch都连接在CPU2UBCDD2的一个端口上,对应portID为24(这个是我们自己上报的的),华为对应的portID为8与10

如果类比riser卡下的pcie设备加载的话,这个portid应该对应具体pcie设备网上一级,如图中87:02.0 8c:02.0这种,这边不是很确定bios能不能将portid精细到这一级的rootBDF,如果不行依然可以采用方法4进行补充加载

我们这边收到配置了PcieAddrInfo。但是还是看不到。从app.log中看到的BDF对不上。后续发现是因为pcie_device中存在override_root_bdf。这种情况下需要如何配置?

        "PcieAddrInfo_15": {
            "Location": "RiserCard${Slot}",
            "ComponentType": 8,
            "ContainerSlot": "${Slot}",
            "ContainerUID": "00000001042313925",
            "ContainerUnitType": "IEU",
            "GroupPosition": "PcieAddrInfo_20_${GroupPosition}",
            "PortID":8,
            "SlotID": 15,
            "SocketID": 1,
            "Bus": 135,
            "Device": 2,
            "Function": 0
        },

设备中配置lsprop发现配置被修改了

lsprop PcieAddrInfo_15_010105
bmc.kepler.Object.Properties
  ClassName="PcieAddrInfo"
  ObjectIdentifier=[1,"1","1","010105"]
  ObjectName="PcieAddrInfo_15_010105"
  TraceSamplingRate=0
bmc.kepler.Systems.PcieAddrInfo
  Bus=170
  ComponentType=8
  ControllerIndex=1
  ControllerType=0
  Device=2
  DeviceID=0
  Function=0
  GroupID=0
  Lanes=4
  PCIeType="Gen3"
  PortID=14
  ReadyToEnumerate=true
  Segment=0
  SlotID=15
  SlotType=""
  SocketID=1
  VendorID=0
Private
  ContainerSlot=1
  ContainerUID="00000001042313925"
  ContainerUnitType="IEU"
  DevBus=0
  DevDevice=0
  DevFunction=0
  GroupPosition="PcieAddrInfo_15_010105"
  Location="RiserCard1"
  MultihostPresence=0

pcie_device NOTICE: biz_topo.lua(1033): [BizTopo] PCIeAddrInfo: Location=RiserCard1, SlotID=15, ComponentType=0x08,SSBDF=0-1-0xaa-0x02-0x00
pcie_device NOTICE: biz_topo.lua(1033): [BizTopo] PCIeAddrInfo: Location=RiserCard1, SlotID=16, ComponentType=0x08,SSBDF=0-1-0xaa-0x00-0x00
pcie_device NOTICE: biz_topo.lua(1033): [BizTopo] PCIeAddrInfo: Location=RiserCard1, SlotID=17, ComponentType=0x08,SSBDF=0-1-0x87-0x06-0x00
pcie_device NOTICE: biz_topo.lua(1033): [BizTopo] PCIeAddrInfo: Location=RiserCard1, SlotID=18, ComponentType=0x08,SSBDF=0-1-0xaa-0x00-0x00
pcie_device NOTICE: biz_topo.lua(1033): [BizTopo] PCIeAddrInfo: Location=RiserCard1, SlotID=19, ComponentType=0x08,SSBDF=0-1-0x95-0x04-0x00
pcie_device NOTICE: biz_topo.lua(1033): [BizTopo] PCIeAddrInfo: Location=RiserCard1, SlotID=20, ComponentType=0x08,SSBDF=0-1-0x8c-0x06-0x00

PcieAddrInfo写死后还是被修改了,通过代码发现在pcie_device的biz_topo.lua中有一个set_bdf函数,该函数通过override_root_bdf修改了配置我们又没有在PSR中配置bdf_config_map。需要问一下这个函数中这一步的作用是什么

    if override_root_bdf[pai.mds_obj.SocketID] and override_root_bdf[pai.mds_obj.SocketID][pai.mds_obj.PortID] then
        pai.mds_obj.Bus, pai.mds_obj.Device, pai.mds_obj.Function = table.unpack(
            override_root_bdf[pai.mds_obj.SocketID][pai.mds_obj.PortID])
    end

set_bdf是根据实际拓扑建立的结果,将预配置的rootBDF设置到PortID为对应值的PcieAddrInfo上,对于您这种需要自己设置PortID的情况,需要在PSR的UnitConfiguration下设置Device的值,对应配置BDFConfig,保证指定的PortID能拿到预设的BDF,这种情况下就能使得对应PcieAddrInfo拿到预期的rootBDF值。

测试的时候发现一个问题。在Robust load device时,pcie的SystemsPCIeTopoInfo数据库不一定有数据。会出现捞取时PCIe的消息还没有加载,捞取动作就已经完成的问题。同步机制有点问题

捞取要在bdf上报时完成,之前问过bios,上报fdm的实机是比这个早的

我这边因为是BM320机型,bios都是之前的v2版本的bios,在实际测试时发现fdm上报是比捞取动作要慢的

对比了一下S920X20与S920S10机型,S920X20的Bios是与iBMC v3配套的。确实是先上报FDM(type为20),后发送Bios BDF changed信号的。S920S10的Bios是iBMC v2版本配套的,先收到Bios BDF changed信号,随后收到上报的FDM(type为5).应该是机型bios有区别导致的

社区版本应该还是要和新bios配套的

该问题目前已经解决,直接在SR文件中将PcieAddrInfo中配置固定写死(PCie Switch下行的BDF信息、对应CPU信息、PortId写死为255)。同时不在配置PSR中UnitConfiguration信息。