关于EXU是获取下级板卡UID的疑问

Tzyy_Q_wbdc2 · 2026 年2 月 3 日 09:31

在编写拓展版EXU的sr文件的Connector时有一个疑问。对于IdentifyMode为3的天池加载方式，Connector是如何获取下一级的ID与AuxID的。在整个拓展版SR配置中，很大部分Connector是没有Eeprom的。这里以BCU距离，在拓展版上找不到关于BCU板的Eeprom配置，这种情况下EXU是如何知道下级BCU的Eeprom中存储的UID值？尽管在实际运行中S920X20机型确实加载了BCU板并获取到了UID，但是不知道拓展版是如何获取的。

    "Connector_BCU_1": {
      "Bom": "14060876",
      "Slot": 1,
      "Position": 1,
      "Presence": 1,
      "Buses": [
        "I2c_1",
        "I2c_2",
        "I2c_8",
        "JtagOverLocalBus_1"
      ],
      "SystemId": "${SystemId}",
      "ManagerId": "${ManagerId}",
      "ChassisId": "${ChassisId}",
      "SilkText": "BCU",
      "IdentifyMode": 3,
      "Type": "CPUBoard"
    },

ubmc_assistant · 2026 年2 月 3 日 09:37

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

EXU 并不需要在自身的 .sr 文件中预先知道 BCU 的 UID，而是通过 IdentifyMode=3 自动从 BCU 板卡的 EEPROM 中读取 UID 和其他识别信息。

这是一种典型的 “硬件带描述信息上电自发现” 机制，极大提升了系统的可扩展性和维护便利性。只要下级板正确烧录 CSR 到 EEPROM，EXU 就能自动识别并加载对应的配置，实现真正的即插即用。

详细分析解答

EXU 如何获取下级板卡（如 BCU）的 UID 详解

在 天池（TianChi）架构 中，EXU 拓展板通过 IdentifyMode=3 的方式实现对下级板卡（如 BCU、SEU 等）的 硬件自发现（Hardware Auto-discovery）。您提出的问题非常关键：

EXU 的 Connector_BCU_1 配置中并未直接写明 BCU 的 UID 和 AuxID，系统是如何获取下级 BCU 板卡 EEPROM 中的 UID 值并完成识别与加载的？

下面将结合 知识图谱数据、系统机制及搜索结果，从原理层面全面解答。

一、核心机制：IdentifyMode = 3 的工作流程

当 IdentifyMode = 3 时，表示该连接器遵循 “天池标准” 的硬件自发现机制。这意味着：

板卡的识别不依赖于 SR 文件中硬编码的 UID 或 BoardID。
真正的识别信息存储在下级板卡自身的 EEPROM 中。
系统通过 I2C 接口读取 EEPROM，从中解析出 UID 和其他元数据（如 CSR 文件版本、板型等），再根据这些信息动态加载对应的 .sr 配置文件。

核心流程如下：

EXU 上的 Connector_BCU_1 检测到 Presence=1（物理存在）。
系统根据 Buses 列表中的 I2C 总线（如 I2c_1）访问下级 BCU 板的 EEPROM。
通过标准地址（通常为 0xAE）读取 EEPROM 中的 CSR Header 数据。
解析 Header 中的 UID、BOM_ID、AuxID、CSR 版本号 等关键字段。
根据 BOM_ID 和 AuxID 拼接生成目标 .sr 文件名（如 14060876_BCU_01.sr）。
加载并应用对应 .sr 配置。

二、为什么不需要在 EXU 的 SR 文件中配置 UID？

回答：UID 存在于下级板卡的 EEPROM 中，不是由上级 EXU 指定，而是“被发现”的

即使在 EXU 的 .sr 文件中未配置 Id 字段或写为空字符串（""），只要 IdentifyMode=3，系统就会：

主动去下级板卡的 EEPROM 中读取 UID

这一机制被称为 “基于 EEPROM 的硬件自描述”（CSR, Control & Status Register），其设计目标是实现“即插即用”和“零配置部署”。

证据支持：

知识图谱中的描述：

“当 IdentifyMode 是 3 时，系统从 EEPROM 读取 UID”
“Eeprom 是一个非易失性存储芯片，用于存储 CSR 数据以进行板卡识别”
文档《板卡适配指南》原文：

“框架会自动读取下一级对象的寄存器（Eeprom），解析和校验 Eeprom 里 header 头数据中的 UID……根据读取 Connector 的 Bom 属性、解析的 Eeprom 数据中的 UID 来获取下一级对象的 BOM_ID.SR 文件。”
文档《硬件自发现FAQ》说明：

"Id": "" 表示下级组件 Board Id，天池标准组件的 BoardId 通过 Chip 属性关联的器件对象，调用对应的读写接口获取 EEPROM 数据中的 Board Id 信息。

三、EXU 是如何定位并读取 BCU 的 EEPROM 的？

尽管 EXU 的 .sr 文件中没有显式配置 Eeprom_BCU，但以下信息已在 Connector_BCU_1 中定义：

"Connector_BCU_1": {
  "Buses": ["I2c_1", "I2c_2", "I2c_8", ...],
  "IdentifyMode": 3,
  ...
}

1. 总线连接提供通信路径

I2c_1 是连接 EXU 与 BCU 的 物理 I2C 通道。
BCU 板上的 EEPROM 被挂载在这条总线上，地址通常是固定的（如 0xAE）。
EXU 通过 I2c_1 发起读请求，访问地址 0xAE 获取数据。

2. EEPROM 数据结构标准化（CSR 格式）

天池系统定义了统一的 CSR 二进制格式，所有兼容板卡必须烧录符合规范的 CSR 数据。
CSR Header 包含：
- UID（唯一标识）
- BOM_ID
- AuxID
- Version
- Signature

因此，只要 BCU 板正确烧录了 CSR 到 EEPROM，EXU 就能通过标准协议读取它。

四、实际运行中如何验证？

您提到 S920X20 机型实际能加载 BCU 并获取 UID，这正是因为：

BCU 板出厂时已烧录正确的 CSR 到其板载 EEPROM

例如，在某 BCU 板中：

EEPROM 地址 0xAE 存储了 CSR 数据

CSR 中包含：

"UID": "00000001020302031825",
"BOM_ID": "14060876",
"AuxID": "01"

系统据此加载文件：14060876_BCU_01.sr

五、如何查看运行时的 UID 读取情况？

可通过以下方式验证：

1. 使用 `mdbctl` 查看已解析的 Connector 信息

% mdbctl
% lsprop Connector_BCU_1_0101

输出中会包含：

Id="00000001020302031825"     // 实际从 EEPROM 读取的 UID
AuxId="01"
Chip="Eeprom_3_1_0101"        // 实际访问的 EEPROM 对象

2. 查看日志文件

grep -i "exu" dump_info/LogDump/framework.log

会显示类似：

Loading SR file: 14060876_BCU_01.sr from EEPROM
Detected Board UID: 00000001020302031825

总结：EXU 获取下级 BCU UID 的完整逻辑

步骤	说明
	EXU 中配置 `Connector_BCU_1`，设置 `IdentifyMode=3`，并通过 `Buses` 列表提供 I2C 接口（如 `I2c_1`）
	系统检测到 `Presence=1`，判断下级板卡存在
	框架通过 `I2c_1` 访问下级板卡（BCU）的 EEPROM（地址 `0xAE`）
	读取并解析 EEPROM 中的 CSR 文件头，提取 `UID`、`BOM_ID`、`AuxID` 等信息
	根据 `BOM_ID` 和 `AuxID` 拼接 `.sr` 文件名（如 `14060876_BCU_01.sr`）
	加载并应用该配置文件，完成板卡初始化

结论