问题描述
在装备单板FT联调中，bmc_spi_test%hi1710_107 测试执行ipmicmd -k ‘f 0 30 90 43 00 20 02 2’ smi 0，提示如下：SPI Test fail,return:0f 31 00 90 00 00 01 46 00 00 00 00 00 53 50 49 20 54 65 73 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
查看日志发现，在进行DFTSPI测试时，提示失败，该版本为互联网厂商定制，互联网厂商要求使用sfc1，但DFT测试时还是使用的sfc0，导致DFT测试失败
compute_manufacture_app.lua文件在闭源仓中，麻烦问下，能否在闭源仓中对该部分进行定制化处理，或者是否有其他方法进行规避呢？感谢
答案内容由AI生成，仅供参考：
该问题是由于 DFT测试流程未适配客户定制硬件（SFC1） 所致。虽然根本逻辑在闭源仓的 compute_manufacture_app.lua 中，但完全可以通过定制化手段解决：
推荐方案：在闭源仓中增加SPI接口动态选择逻辑，结合产品配置实现灵活适配。
此外，建议：
Dft_Switch 或 CSR配置 中预留硬件适配字段，提升可维护性。通过以上措施，可避免同类问题在其他定制项目中重复出现。
在装备单板FT联调过程中，执行DFT（Design for Testability）测试时出现 SPI Test失败 的问题。具体表现为：
ipmicmd -k ‘f 0 30 90 43 00 20 02 2’ smi 0SPI Test fail，返回码包含详细错误信息。DFtSPI[70_0_0] start
remove modules /lib/modules/ko/sfc0_drv.ko successfully
load chipvl spidrv
success to insmod driver /lib/modules/ko/sfc0_drv.ko
check device ready fail.
DFtSPI[70_0_0] verify fail.
尽管当前设备为互联网厂商定制版本，明确要求使用 SFC1 接口进行SPI通信，但DFT测试流程中仍默认加载并使用了 SFC0 的驱动（sfc0_drv.ko），导致无法正确识别和初始化目标Flash设备，最终引发 “check device ready fail” 错误。
从日志可见：
sfc0_drv.kosfc0_drv.kocheck_device_ready 检查失败）这表明DFT测试框架未适配定制化硬件配置，强制绑定到SFC0而非预期的SFC1，造成了测试失败。
根据知识库信息：
sfc_core_spi_probe 是用于探测SPI Flash设备的核心函数，负责读取设备ID（RDID）、验证芯片连接性。sfc_core_spi_probe 对 cs0 和 cs1 的探测行为。0x00000000），将报错“R0ID not right”，并导致后续初始化失败。sfc_core_show_spi 则用于显示当前SPI设备信息（如芯片名称 IS25WP128F、MX25U25645G）。示例：若
sfc_core_spi_probe在Sfc0cs0上读取到错误的RDID响应，则会记录 ID 165/166 的日志条目，并触发错误码-14。
| 组件 | 作用 |
|---|---|
Dft_Test_Interface |
提供通过IPMI命令（Start/Stop/Result）触发DFT测试的能力 |
DftCpldManufactureStart → DftCpldStart |
实际执行启动CPLD相关DFT测试的函数 |
SpiDriver |
负责加载SPI驱动，建立与Flash的通信链路 |
Manufacture_App |
主测试应用，调用DFT测试模块 |
DFT测试中的SPI测试依赖 SpiDriver 正确配置SPI控制器（SFC0 或 SFC1）来访问Flash。
| 原因 | 描述 |
|---|---|
| 硬件配置不匹配 |
客户要求使用 SFC1，但测试代码硬编码或默认加载 SFC0 驱动 |
| 驱动加载逻辑固化 |
compute_manufacture_app.lua 中调用 insmod /lib/modules/ko/sfc0_drv.ko，缺乏动态选择机制 |
| 缺少定制化适配能力 |
DFT测试未感知产品级或客户级配置差异，无法根据机型自动切换SPI接口 |
 设备就绪检测失败 |
check_device_ready 因访问错误总线而超时，返回失败 |
日志印证：
Wait SPI Flash Ready Timeout错误常伴随sfc_core_spi_probe探测失败发生。
compute_manufacture_app.lua（推荐）由于 compute_manufacture_app.lua 位于闭源仓，可以对其进行定制化修改以支持SFC1：
判断当前平台/客户配置
local spi_interface = get_system_property("SPI_INTERFACE") -- 可从配置文件或环境变量读取
if spi_interface == "SFC1" then
driver_path = "/lib/modules/ko/sfc1_drv.ko"
else
driver_path = "/lib/modules/ko/sfc0_drv.ko"
end
动态加载对应驱动
os.execute("rmmod sfc0_drv")
os.execute("rmmod sfc1_drv") -- 清理旧模块
os.execute("insmod " .. driver_path)
配置传参方式
manifest 或 customer_config 注入 SPI_INTERFACE=SFC1Dft_Switch 动态控制（间接规避）利用 Dft_Switch 表定义不同的DFT测试选项，并结合 Manufacture_App 和 Dft_Test_Interface 实现差异化处理。
Dft_Switch 表中增加字段：{
"TestID": 70,
"ItemName": "SPI Test",
"SPI_Port": "SFC1"
}
Manufacture_App 读取该字段，决定加载哪个驱动。ipmi dft start 70）启动测试。
Manufacture_App支持解析新字段，可能仍需闭源修改
参考“构建制品定制化方案”中提到的产品定制化配置权限机制：
sfc0_drv.ko 替换为 sfc1_drv.ko 符号链接，或修改配置文件。# 构建脚本片段示例
if [ "$PRODUCT" = "INTERNET_VENDOR_A" ]; then
sed -i 's/sfc0_drv/sfc1_drv/g' compute_manufacture_app.lua
fi
适用场景：固定客户、固定硬件组合，适合批量生产环境。
| 步骤 | 内容 |
|---|---|
| 1 | 确认闭源仓可修改性：与闭源维护团队沟通，评估 compute_manufacture_app.lua 是否允许定制 |
| 2 | 引入SPI接口配置项：在系统配置中添加 SPI_INTERFACE 字段，支持SFC0/SFC1选择 |
| 3 | 修改Lua脚本逻辑：根据配置项动态加载对应驱动模块 |
| 4 | 测试验证： • 正常加载SFC1驱动 • 成功执行 sfc_core_spi_probe• 输出正确的 sfc_core_show_spi 信息 |
| 5 | 纳入发布基线：将修复纳入 2509版本0502TEST装备版本 等相关版本 |
该问题是由于 DFT测试流程未适配客户定制硬件（SFC1） 所致。虽然根本逻辑在闭源仓的 compute_manufacture_app.lua 中，但完全可以通过定制化手段解决：
此外，建议：
Dft_Switch 或 CSR配置 中预留硬件适配字段，提升可维护性。通过以上措施，可避免同类问题在其他定制项目中重复出现。
从您这边需求上看的话涉及闭源组件的配置，这边后续是需要一个切换功能吗？
就是DFT测试中关于SPI Test的测试我们这边需要对互联网厂商进行定制，互联网厂商要求使用sfc1，想问下闭源仓能否会支持这个定制，如果不支持定制的话，进行切换的话，ipmi_handler.get_obj_by_req这里会影响其他的测试项么，感谢
测试项配置里， 确保dft_id、slot、device_num 这几个参数的组合是唯一的，不会和其他测试项产生冲突。
那请问，如果需要一个切换的功能需要多长时间呢，能否先临时提供一个只支持scf1的版本呢，后续可以自主切换的功能可以继续讨论，感谢
只支持SFC1会对现有测试项带来影响
好吧，那后续这方面什么时候可以切换呢，这个有计划么
不一定通过切换方式解决。目前处理方案还在讨论中，预计在下个季度明确。
