编程器对一个读取正常的 SFP+ 报 WRITE FAIL:是 EEPROM 坏了,还是有什么东西在阻止写入?
我们差不多每个月都要给客户主机重编码一小批模块,没什么特别的:读原始页面,写入主机要求的厂商字符串,把模块插进交换机,就完事了。这一批里有一个模块读取完全正常,但拒绝一切写入,在把它扔掉之前,我想知道还有没有什么办法可以试。
工作台配置:
- CH341 类的 USB 编程器,配 SFP 转接板
- 一个支持诊断的 SFP+ 模块,冷启动和断电重启后读取都正常
- 同一套设备一小时前刚成功写过同一托盘里的另外三个模块
一按写入,工具立刻打印:
WRITE FAIL
紧接着重新读取,拿回来的是逐字节一样的原始页面,说明什么都没写进去,哪怕是部分写入都没有。
已经试过的:
- 重新插拔模块,换了一块备用转接板
- 不写整页,只写一个我不在意的区域里的单个字节,结果一样
- 确认了多次断电重启后读取都是稳定的,说明接线没有问题
一个读取正常但从不接受写入的模块,是单纯用坏了,还是模块本身有能力故意拒绝写入?
Comments 5
读取正常,写入被拒,之后原始页面完好无损。这不是坏掉的 EEPROM 通常的表现。存储单元损坏一般会给你一次读回错误,或者一页写了一半的结果,而不是这种干干净净地拒绝、什么都没被动过。
而且既然连厂商区之外那一个字节的写入都被弹回来了,这就不是芯片上某个区域坏了,而是这个部件在整体拒绝写入。在你下结论之前有两件事值得确认。第一,这个模块到底是谁做的:以你已经导出的页面里的 vendor string 为准,而不是托盘上贴的标签。第二,如果你在刚上电、总线上还没有任何其他东西跟模块通信过的那一刻立刻发写入,会不会成功。可能的解释会因为这两个答案而不同,其中一种情况根本算不上故障。
这看起来更像是密码保护,而不是损坏。SFF-8472 允许一个支持诊断的模块在接受任何写入之前要求一个 4 字节密码。不发密码,或者发错密码,模块会对写入返回错误,同时读取依然完全开放,这正好对应你这个 WRITE FAIL、页面原样不变的情况。这是这个部件的一个特性,不是它快坏了的症状。
这对你的工作台意味着:一个懂这个的编程器会让你输入厂商或主机密码,好一点的还能帮你暴力破解一个未知密码,并在写入之后帮你重新计算校验和。CH341 那类设备完全没有校验和自动化,所以就算你绕过了密码,也得自己去修校验和,不然你会得到一个页面在你看来是对的、但主机依然拒绝的模块。
常规提醒:我在少数几个模块上遇到过这个情况,密码这条路走通了,所以在放弃之前先在你这个部件上试试。
补充一点:对某些厂商来说,密码其实算不上什么秘密。网上流传着一些共享的 Ubiquiti 收发器密码合集,里面有像 0x00001011 这样的条目,也有 SFPX、QSFP 这样的明文字符串,所以如果这个模块来自那个生态,花五分钟先试试这些已知密码,再考虑暴力破解也不迟。
如果你想要一个已经把整个流程都封装好的工具,而不是跟一个通用编程器死磕,UACC-SFP-WIZARD 是大家常用的便宜选择。它不是台正经的实验室仪器,但模块这一侧的处理是到位的。
相关经验,来自给 Huawei S5731、S6730 主机以及一台老的 HP 6120XG 重编码模块的过程。当笼子或转接板才是薄弱环节、而不是模块本身的时候,有人会直接在模块的第 4 和第 7 引脚上焊线,这两个引脚是 I2C 的 SDA 和 SCL,绕开笼子直接驱动 EEPROM。这个办法很粗暴,只能用在你能接受报废的部件上,但它能排除掉一整类接触不良的问题。
这边这么处理过的部件有:Finisar FTLX8571D3BCV 和 FTLX8574D3BCV、Intel 的 SFP+ LR 和 SR 模块、SNR-SFP+W73-3 和 SNR-SFP+W37-3,还有一个 HP J9150A。
你这个情况读取在多次断电重启之后依然非常稳定,所以接触不是你的问题。先去查密码这条线索。
密码很可能是正确答案,但别止步于"输入密码就完事了",因为紧接着有两件事会咬人。
第一,在有些部件上,模块断电之后再上电,密码需要重新输入一次,所以一个按顺序连续写多页的脚本,得做好重新输入密码的准备,而不是假设一次解锁能覆盖整个会话。
第二,校验和。用 CH341 类的编程器,你得自己手动重新计算校验和。留着旧的校验和不管,模块依然读得出来,你的工具也会报成功,但主机会悄悄拒绝这个模块,然后所有人又回过头去怪硬件。在这个模块装进客户交换机之前,先读回页面、验证一下校验和。