欢迎来到 openUBMC 社区
Hey @changxingOpenUBMC , 感谢你对社区的贡献.
机器人使用手册
有关指令的使用，可以点击 说明文档 或 论坛 查看详情。开发人员可以在每个PR或Issue下方评论特定指令来触发机器人任务。
联系指引
有疑问可以联系 SIG: sig-hardware ,
维护者是： @changxingOpenUBMC, @nathanael, @xiaoxinglxs, @yelvsub ,
优秀贡献者是： @dli_bmc, @huangjiapei, @mao_0v0, @yelmh .
Issue 工作流介绍
社区的需求和缺陷的工作流状态处于纳管中。
| 类型 | 上个状态 | 下个状态 | 评论命令 | 谁可以操作 |
|---|---|---|---|---|
| 需求 | 待办的 | 已接纳 | /todo2accepted | SIG组: sig-release-management (maintainer) |
| 需求 | 已接纳 | 开发中 | /accepted2developing | 仓库成员角色: Maintainer, Committer, Contributor, Owner |
| 需求 | 开发中 | 转测中 | /developing2testing | 仓库成员角色: Maintainer, Committer, Contributor, Owner |
| 需求 | 转测中 | 待验收 | /testing2UAT | 仓库成员角色: Maintainer, Committer, Contributor, Owner |
| 需求 | 待验收 | 已完成 | /UAT2done | SIG组: sig-QA (maintainer,committer) |
| 需求 | 待办的 | 已挂起 | /todo2suspended | SIG组: sig-release-management (maintainer) |
| 需求 | 已挂起 | 已接纳 | /suspended2accepted | SIG组: sig-release-management (maintainer) |
| 需求 | 待办的 | 已拒绝 | /todo2rejected | SIG组: sig-release-management (maintainer) |
| 需求 | 已拒绝 | 已接纳 | /rejected2accepted | SIG组: sig-release-management (maintainer) |
PR #658 回顾分析: 新增UpgradePrepareSignal用于升级前固件检查
仓库: openUBMC/mdb_interface
分支: personal/lisongwei_signal_d0727 → main
作者: lisongwei
合并时间: 2026-07-27 16:51:25
合并人: openUBMC-robot
⚠️ 设计链接更正说明：任务最初提供的论坛链接
discuss.openubmc.cn/t/6925实为「天池单板CPLD JTAG扫链巡检」设计（bmc.kepler.Systems.Board.Diagnose），与本 PR 主题无关。本 PR 描述中实际引用的关联设计为 topic 3596（新增升级前预检查相关资源协作接口方法属性），本次回顾以 3596 为准。另注：本 Issue #378 在 topic 6925 中登记为「CPLD JTAG扫链巡检」需求，而本 PR 实现的是 topic 3596 的「升级前预检查信号」。两者为不同特性，建议作者确认 PR 与 Issue 的关联是否正确。
1. AI 检视意见追踪
本 PR 收到两类 AI 检视：一致性检视（OpenClaw，@Richardli25）与平台内置代码审查（@gitcode-bot）。
1.1 一致性检视意见（@Richardli25，2026-07-27 14:21）
| # | 级别 | AI 发现 | 后续处理 | 说明 |
|---|---|---|---|---|
| 1 | 严重 | 设计 3596 要求的新增方法 PrepareUpdateCheck 未实现 |
⏳ 未响应 | AI 评论后无相关 commit，开发者未回复说明 |
| 2 | 严重 | 设计 3596 要求的新增属性 PrepareUpdateCheckStatus 未实现 |
⏳ 未响应 | AI 评论后无相关 commit，开发者未回复说明 |
| 3 | 建议 | 信号 PrepareUpdateSignal 的 description 写作「故障检查」，设计原文为「预检查」，措辞不一致 |
⏳ 未响应 | 合并后 diff 仍为「固件升级前故障检查可选参数字典」，未修改 |
| 4 | 建议 | PR 标题为 UpgradePrepareSignal，实际新增信号名为 PrepareUpdateSignal，且与同文件既有信号 UpgradePrepareSignal 高度相似易混淆 |
⏳ 未响应 | PR 标题未修正 |
1.2 平台内置代码审查（@gitcode-bot，2026-07-27 11:49）
| # | 级别 | AI 发现 | 后续处理 | 说明 |
|---|---|---|---|---|
| 5 | P3 | 信号命名一致性：新增 PrepareUpdateSignal 与 PR 标题 UpgradePrepareSignal 及既有信号名称相似，存在混淆风险 |
⏳ 未响应 | 与上表 #4 同类问题，未修改 |
指标汇总：
| 指标 | 结果 |
|---|---|
| AI 意见总数 | 5 |
| 已采纳并修复 | 0 |
| 已回复说明 | 0 |
| 未响应 | 5 |
说明：意见 #1、#2 涉及的方法/属性缺失，AI 检视本身已注明「可能计划由后续 PR 交付」，本次按本 PR 范围计为未覆盖、开发者未回复确认。回顾分析不评判意见本身正确性，仅追踪后续处理情况。
2. 人工检视补充
- 检视人: @L_Ling（lixiaoning）
- 检视行为: 仅发表了
/lgtm/approve/publish/check-pr批准命令（2026-07-27 16:51），未提出实质性代码改进意见 - diff_comment（行内评论）: 无（本 PR 全程无任何人工行内评论）
- 解决状态: 不涉及（无人工意见）
本 PR 人工检视环节以走查批准为主，未对实现细节提出补充意见。
3. 评审贴覆盖情况
评审贴链接：【已评审】新增升级前预检查相关资源协作接口方法属性（topic 3596）
设计 3596 评审结论同意新增 3 个资源协作接口要素，逐项对比本 PR 变更（仅修改 json/intf/mdb/bmc/kepler/UpdateService.json，+7 行）：
| # | 评审点 | 是否涵盖 | 说明 |
|---|---|---|---|
| 1 | 新增方法 PrepareUpdateCheck（bmc.kepler.UpdateService，权限 BasicSetting，rsp: TaskId:U32） |
❌ 未涵盖 | UpdateService.json methods 段无此方法 |
| 2 | 新增信号 PrepareUpdateSignal（bmc.kepler.UpdateService，AdditionalOptions: Dictionary/a{ss}） |
✅ 已涵盖 | signals 下新增，baseType=Dictionary + $ref=#/defs/Object，与设计匹配 |
| 3 | 新增属性 PrepareUpdateCheckStatus（bmc.kepler.UpdateService.FirmwareInfo，String，读写，default=Init，emitsChangedSignal=false，enum Init/Running/Completed） |
❌ 未涵盖 | FirmwareInfo.json properties 段无此属性 |
覆盖统计: 1/3
4. 总结
- AI 意见采纳率：0%。本次共 5 条 AI 检视意见（含平台内置审查 1 条），开发者均未回复、未在合入前修改，全部判为「未响应」。其中 2 条「严重」级别涉及设计要求的方法/属性未实现，可能由后续独立 PR 承载，但开发者未在 PR 中说明拆分计划。
- 开发者响应态度：PR 作者（@lisongwei）在 AI 检视（14:21）发布后至合入（16:51）期间未作任何回复或代码调整，检视意见未被讨论闭环。
- 人工检视补充价值：本 PR 人工检视仅完成批准流程（@L_Ling），无行内评论与实质补充，未对 AI 未覆盖维度形成补充。
- 设计覆盖度：设计 3596 共 3 个评审点，本 PR 仅实现信号 1 项（1/3）。方法
PrepareUpdateCheck与属性PrepareUpdateCheckStatus尚未交付，建议追踪后续 PR 以闭环设计 3596。 - 值得关注：
- 信号 description「故障检查」与设计术语「预检查」不一致，属低成本可修正项，建议在后续提交中统一。
- PR 标题与实际信号名不符，易与既有
UpgradePrepareSignal混淆，建议规范命名。 - PR 描述引用了与本 PR 无关的 Issue #378（CPLD JTAG扫链）与可能误导的 topic 6925，建议核实 PR-Issue-设计三方关联。
此回顾分析由 AI (OpenClaw + GLM-5.1) 完成
/accepted2developing
/developing2testing
感谢您为社区贡献新需求！请按照以下提示提供详细信息，以便我们更好地理解并跟进。
版本分支
openUBMC main
需求属性
所属版本
openUBMC 26.09
工作量
NA
是否需要编码
是
是否免测试
否
周边依赖
NA
需求来源
NA
需求描述
简要说明
支持天池单板上通过JTAG链路进行CPLD扫链巡检，验证CSR配置的JTAG升级CPLD芯片与实际硬件扫链结果的一致性
系统用户
开发人员、测试人员、运维人员
前置条件
BMC运行正常、各单板CSR配置已下发完成
主成功场景
（1）触发扫链巡检
1. 用户通过Redfish或IPMI接口触发CPLD扫链巡检；
2. 调用新增的RPC接口启动所有单板的CPLD扫链；
（2）计算预期CPLD数量
1. 针对每块单板（基础板、硬盘背板、扩展板、风扇板），获取该单板上已下发CSR中的LogicFirmware对象；
2. 筛选出未配置I2CUpgradeChip属性的LogicFirmware对象个数，即为该单板预期支持JTAG链路升级的CPLD芯片数量；
3. 若LogicFirmware对象同时配置了I2C和JTAG升级能力，则不纳入扫链检查范围；
（3）执行JTAG扫链
1. 对支持安全GPIO升级的CPLD，扫链前先打开JTAG通道；
2. 通过框架提供的接口执行JTAG扫链，获取实际扫链结果；
3. 扫链完成后关闭JTAG通道；
（4）汇总与比对
1. 汇总所有单板的扫链结果；
2. 将每块单板的实际扫链数量与预期CPLD数量进行比对；
3. 若不匹配，设置该单板的扫链检查结果为异常，记录具体差异信息；
4. 返回汇总的扫链巡检结果供Redfish或IPMI接口查询；
（5）操作日志
1. 扫链启动和扫链结果均记录操作日志；
扩展场景（含异常场景）
1、CSR配置的JTAG升级LogicFirmware对象与实际硬件不匹配 记录为硬件CSR配置错误，扫链结果标记异常并返回具体不匹配的单板信息
2、LogicFirmware对象同时配置了I2C和JTAG升级能力，跳过该CPLD，不参与扫链检查
3、单板扫链超时或通信失败，该单板扫链结果标记为失败，记录失败原因，不影响其他单板继续扫链
约束
非功能需求
（1）可靠性要求：1、JTAG通道在扫链异常（超时/失败/进程前溃）时必须自动关闭，避免通道长期开放；2、扫链过程不影响BMC其他业务功能正常运行
（2）可维护性要求：扫链结果不匹配时记录各单板的详细结果（预期数量、实际数量、差异描述）
（3）可测试性要求：提供打桩能力，模拟单板实际可JTAG升级的CPLD个数与扫链结果不匹配的场景
（4）性能要求：1、单板扫链超时时间建议不超过30秒：2、全量扫链巡检整体耗时建议不超过5分钟
（5）兼容性要求(和以前版本及周边配套)：NA
（6）安全要求：JTAG通道仅在扫链期间短暂打开，扫链完成后（无论成功或失败）必须立即关闭，防止安全风险
（7）韧性要求：单板扫链失败不阻塞其他单板继续执行，最终结果汇总返回所有单板状态(成功/失败/超时)