新设计的扩展板-升级BCU失败

交流互助区
1

问题描述

基于950的新机型，借用基础板，扩展板是我们自己的，升级BCU失败。

环境信息

  • 软件版本：[OpenUBMC2606]

重现步骤

升级BCU CPLD必现。
image

分析结论

生成的拓扑：

image
image304×147 3.37 KB

与硬件原理图保持一致。
目前让硬件写死JTAG链路为Channel1依然无法升级，获取不到cpld device info，手动调用命令打印出来是空，想知道这是什么东西，出现问题可能与什么有关。
image

2

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

4. 总结

“获取不到cpld device info，手动调用命令打印出来是空”的根本原因在于BMC与目标CPLD之间未建立有效的JTAG通信。这可能由链路切换未完成、CSR定义不匹配、硬件信号异常或总线接口类型错误引起。建议优先验证JTAG链路的软件切换命令是否生效，并对比CSR中的路由配置与实际硬件拓扑，同时结合Linux内核日志和TDO波形测量进一步缩小问题范围。

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

根据您提供的描述——在基于950的新机型上，借用基础板（BCU），升级自研扩展板上的BCU CPLD时失败，且手动获取“cpld device info”返回空值——结合已知的openUBMC社区资料和知识图谱，这一现象通常指向JTAG链路配置、CSR描述或硬件连通性方面的异常。以下是对该问题的详细分析和排查方向。

1. “cpld device info”的含义与获取方式

  • “cpld device info”通常指通过JTAG链路读取CPLD芯片的IDCODE（厂商与器件标识码），用于识别芯片型号并确定正确的升级流程。
  • 在openUBMC中，获取该信息的典型命令为：
    busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Cpld/Cpld_1_0101 bmc.kepler.Chip.JtagTarget GetChipIdcode a{ss} 0
    返回为空或失败，表示BMC未能成功从CPLD读取到预期的响应。

2. 可能的原因分析（基于上下文信息）

2.1 JTAG链路未正确切换或选通

  • 在鲲鹏模组适配约束FAQ中明确指出，出现[cpld] get cpld device info failed时，大概率是JTAG链路没有切过去，需要先通过busctl设置JtagSwitch的Value属性来选通目标CPLD（例如EXU为0，BCU为1），然后再尝试获取芯片信息。
  • 您提到已让硬件“写死JTAG链路为Channel1”，但BMC侧的CSR配置可能与实际链路不一致；若CSR中定义的FirmwareRoute与实际选通通道不匹配，BMC仍可能访问错误的链路，导致无法读到IDCODE。

关键引用：

知识图谱实体JtagOverLocalBus_1描述中提到：“JtagOverLocalBus_1 fails to be created due to unsupported bus type or missing required library。”——该接口可能因配置或依赖问题未能正确初始化。

2.2 CSR配置错误或缺失

  • CPLD升级依赖CSR中的ChipInfo、UpgradeChip、LogicFirmware等属性。若CSR中未正确定义这些属性（如ChipInfo指向错误的Accessor），BMC无法定位到具体的CPLD芯片。
  • 知识图谱中BCU_CPLD与Hisport_0的关系指出：“BCU_CPLD uses Hisport_0 during upgrade, which differs from the CSR-defined JtagOverLocalBus_1。”——这表明升级时使用的总线类型与CSR定义不符，可能导致链路访问失败。
  • 另外，UpgradeChip属性在JTAG升级中是必需项，若误配置为I2C相关属性（如I2CUpgradeChip），同样会引发兼容性问题。

2.3 CPLD扫链失败或硬件链路异常

  • 通过dmesg查看内核日志，若出现svf_scan_register错误或TDO采样值为0，说明JTAG链路虽已选通但无法正确回读数据。
  • 常见原因包括：
    • CPLD未上电或处于异常状态；
    • JTAG信号（TCK、TMS、TDI、TDO）存在断路、电平不匹配或干扰；
    • CPLD版本与BMC侧期望的IDCODE不一致。

社区案例参考：

文档块4（扩展板CPLD Jtag升级失败）中的内核日志显示：“verify TDO [5] expect:0xfe, sample:0x0”——sample为0表示链路完全读不到数据，此情况下需要CPLD逻辑工程师测量TDO波形确认硬件连通性。

2.4 扩展板与基础板之间的JTAG拓扑理解偏差

  • 您提到“生成的拓扑与硬件原理图保持一致”，但仍需确认扩展板的CPLD是否确实挂在BCU的JTAG链路上。若扩展板上的CPLD独立使用另一条JTAG通道，而BMC侧的CSR配置仍指向BCU本身的CPLD，则会导致访问目标错误。
  • 知识图谱中Cpld_1被描述为“CLU board”上的CPLD，但仍通过JtagOverLocalBus_1连接，说明不同板卡可能共享同一总线，但需要通过JtagSwitch进行动态选择。

3. 排查与解决建议

基于上下文中的社区实践，建议按以下步骤定位：

  1. 确认JTAG链路切换状态
    在BMC命令行执行：

    busctl --user set-property bmc.kepler.hwproxy /bmc/kepler/Accessor/Accessor_JtagSwitch_010101 bmc.kepler.Accessor Value t 1

    设置对应链路（BCU通常为1），然后再次尝试获取IDCODE。

  2. 检查CSR文件中的ChipInfo配置
    查阅BCU板对应的CSR文件，确认以下属性正确：

    • UpgradeChip: 应指向具体的Cpld对象（如#Cpld_1）；
    • ChipInfo: 应包含有效的Accessor路径；
    • FirmwareRoute: 与实际JTAG通道号一致。

  3. 分析内核日志与app.log
    执行dmesg，查找cpld std load failed、svf execute error等关键字；同时查看/var/log/app.log中的general_hardware日志，确认升级流程是否进入正确的JTAG分支。

  4. 硬件波形测量
    若所有配置无误但sample值仍为0，需由硬件工程师在CPLD的TDO引脚上测量是否有数据输出，以排除PCB走线或电平转换问题。

  5. 验证升级包与CSR的匹配性
    确保使用的CPLD升级包（.svf或.hpm）是基于当前硬件版本正确生成的，并且update.cfg中UpdateLink配置为JTAG（通常为空或0），而非I2C（1）。

4. 总结

“获取不到cpld device info，手动调用命令打印出来是空”的根本原因在于BMC与目标CPLD之间未建立有效的JTAG通信。这可能由链路切换未完成、CSR定义不匹配、硬件信号异常或总线接口类型错误引起。建议优先验证JTAG链路的软件切换命令是否生效，并对比CSR中的路由配置与实际硬件拓扑，同时结合Linux内核日志和TDO波形测量进一步缩小问题范围。

注：以上分析严格基于您提供的新机型背景及openUBMC版本，并引用了知识图谱中的实体关系（如BCU_CPLD、JtagOverLocalBus_1、UpgradeChip等）以及社区FAQ、问题分析文档中的定位方法。

3

dump_20260717-2327.tar.gz (8.8 MB)

4

改命令为扫链命令，扫链返回空需要硬件定位具体原因

5

image
image708×126 3.32 KB

是用的哪个命令扫描？有具体例子吗

6

image
这个命令