PCIe网卡适配

Hardware SIG
1

问题描述

不同PCIe网卡的Anchor定义不同，如：

卡A定义
        "Anchor": {
            "Buses": [
                "I2c_2",
                "I2cMux_pca9545_chan1"
              ]
        }
卡B定义
        "Anchor": {
            "Buses": [
                "I2cMux_Chan"
            ]
        }

上一级connector的Buses应该如何定义来支持这两种卡？

        "Connector_PCIE_1": {
            ……
            "Buses": [
                "I2cMux_Chan_0"  //如何定义
            ],
            ……
            "Type": "PCIe"
        }
2

答案内容由AI生成，仅供参考：

结论与建议

  1. 上级 Connector 的 Buses 应定义其实际能提供的所有总线，例如 [“I2c_2”, “I2cMux_pca9545_chan1”]。
  2. 这种设计支持不同的下级设备前提是，下级设备 Anchor 中定义的总线数量不能超过上级 Connector 传递的总线数量，且替换逻辑是基于位置的顺序对应。
  3. 为了兼容性，上级 Connector 传递的总线数量应至少等于所有可能下级设备 Anchor 中定义的最大总线数量。如果卡B只期望1条总线，理论上 Connector 传递2条仍可能存在兼容性问题，因为替换逻辑是按顺序的。

总结：上级 Connector 的 Buses 应定义为硬件实际提供的总线列表。openUBMC通过“按序替代”的机制来实现不同下级设备 Anchor 的兼容性，但这种兼容性依赖于总线数量和顺序的匹配。

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

根据提供的知识库信息，要支持具有不同 Anchor.Buses 定义的PCIe网卡，上一级 Connector 的 Buses 定义需要遵循 “上级传递，下级替换” 的原则。

核心机制：Buses的传递与替换

在openUBMC的管理拓扑（ManagementTopology）中，对于非根节点（如Riser卡上的 Connector_PCIE_1），其 Anchor 中的 Buses 只是一个符号（symbolic placeholder）。这些符号会被来自上级 Connector 传递下来的实际总线按顺序替代。

这意味着，Connector_PCIE_1 的 Buses 定义不取决于下级PCIe网卡的 Anchor 具体定义了哪些总线，而是取决于上级硬件（如Riser卡或BCU）实际提供的物理总线接口。

定义方法

Connector_PCIE_1 的 Buses 应定义为上级硬件能够传递下去的所有总线的列表，例如：

"Connector_PCIE_1": {
    // ... 其他属性（Bom, Id, Slot等）
    "Buses": [
        "I2c_2",
        "I2cMux_pca9545_chan1"
    ],
    // ...
    "Type": "PCIe"
}

工作流程

  1. 上级传递：Connector_PCIE_1 的 Buses （I2c_2, I2cMux_pca9545_chan1）代表了上级硬件（如BCU或Riser卡）实际能够通过此连接器提供的一组管理和通信总线。
  2. 下级接收：当插入一块PCIe网卡时，该网卡的CSR文件中的 Anchor 会定义它期望接收哪些总线。
  3. 按序替代：上级 Connector 传递下来的 Buses（I2c_2, I2cMux_pca9545_chan1）会按顺序替代下级PCIe网卡 Anchor 中的 Buses 符号。

对两种网卡的支持分析

  • 针对卡A：其 Anchor 定义了 ["I2c_2", "I2cMux_pca9545_chan1"]。由于 Connector_PCIE_1 传递的总线完全相同，两者可以实现完美匹配。
  • 针对卡B：其 Anchor 定义了 ["I2cMux_Chan"]。Connector_PCIE_1 传递的总线 ["I2c_2", "I2cMux_pca9545_chan1"] 会按顺序进行替换：
    • I2cMux_Chan（卡B的符号）会被列表中对应的第一个元素 I2c_2 所替代。
    • 第二个元素 I2cMux_pca9545_chan1 因为卡B的 Anchor 中没有对应的符号位，可能会被忽略或导致配置不匹配。

结论与建议

  1. 上级 Connector 的 Buses 应定义其实际能提供的所有总线，例如 [“I2c_2”, “I2cMux_pca9545_chan1”]。
  2. 这种设计支持不同的下级设备前提是，下级设备 Anchor 中定义的总线数量不能超过上级 Connector 传递的总线数量，且替换逻辑是基于位置的顺序对应。
  3. 为了兼容性，上级 Connector 传递的总线数量应至少等于所有可能下级设备 Anchor 中定义的最大总线数量。如果卡B只期望1条总线，理论上 Connector 传递2条仍可能存在兼容性问题，因为替换逻辑是按顺序的。

总结：上级 Connector 的 Buses 应定义为硬件实际提供的总线列表。openUBMC通过“按序替代”的机制来实现不同下级设备 Anchor 的兼容性，但这种兼容性依赖于总线数量和顺序的匹配。

3

在connector中定义所有总线的方式不能解决需求，例如

        "Connector_PCIE_1": {
            ……
            "Buses": [
                "I2c_2",
                "I2cMux_Chan_0"  //如何定义
            ],
            ……
            "Type": "PCIe"
        }

对于卡B，实际是希望I2cMux_Chan对应到I2cMux_Chan_0，而不是I2c_2。

4

只能是按顺序对应