Программатор читает SFP+ FTLX8571D3BCV-IT, но на запись отвечает No Acknowledge
Держу небольшой обменный фонд модулей: узлы разбросаны по городу, и почти под каждый чужой коммутатор приходится перекодировать SFP. С гигабитными модулями схема давно отработана, а на десятке встал.
Что на столе:
- программатор с клеткой под SFP/SFP+, питание 3.3 В
- Finisar FTLX8571D3BCV-IT и FTLX1471D3BCV-IT, читаются оба
- Cisco GLC-LH-SM из старых запасов
- HP J4858B и J4859C
Чтение снимается стабильно и повторяемо, оба банка целиком. Запись не идёт ни в одном варианте:
read A0 0x00-0xFF ... OK
read A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No AcknowledgeЧто уже проверил:
- те же операции на обычных гигабитных SFP тем же программатором проходят, значит обвязка и питание живые;
- взял второй экземпляр FTLX8571D3BCV-IT, поведение байт в байт такое же;
- на GLC-LH-SM No Acknowledge прилетает сразу, ещё до попытки тронуть вендорские поля.
Получается, дело не в конкретном экземпляре. Это аппаратная защита записи в самом модуле, или в SFP+ память уже не голая EEPROM и обычной записью по I2C туда просто не попасть? И отдельно интересует HP J4858B/J4859C: их кто-нибудь пишет обычным программатором, или это заведомо тупик?
AI translation to English
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 6
Тут смешались два разных механизма, и лечатся они по-разному.
Первый - обычная EEPROM с аппаратной защитой записи. У микросхемы памяти есть вывод write protect, и пока он подтянут, чтение идёт, а запись отваливается. Способ, который советовали люди, занимавшиеся этим вплотную, - посадить этот вывод на землю на время прошивки. На части гигабитных модулей этого достаточно.
Второй - то, с чем ты столкнулся на десятке. В SFP+ данные часто лежат не в отдельной EEPROM, а за микроконтроллером модуля: он сам отдаёт A0 и A2 на чтение и принимает запись только своей командной последовательностью. Стандартный программатор такой последовательности не знает и получает No Acknowledge на любую попытку, независимо от того, в какое поле ты метишь. Заземлять там нечего.
Что реально помогает обойти клетку: паяются проводами прямо к ножкам 4 и 7 модуля, то есть на линии I2C, минуя разъём программатора. По отзывам, после этого пишется часть модулей, которые в клетке молчали. Способ грубый, руки нужны ровные, и модуль после него живёт на твою ответственность.
HP - отдельная песня. Стандартные программаторы их не берут, там нужна своя обработка, и на J4858B/J4859C с обычной обвязкой я бы успеха не ждал. Если задача - просто получить рабочий модуль в чужом коммутаторе, дешевле не мучить HP, а взять модуль с честной памятью и залить в него вендорский образ целиком: из 256 байт дампа значимы первые 128, остальное - резерв производителя.
Ни один вендор такую перекодировку, разумеется, не поддерживает: с перепрошитым модулем в поддержку идти не с чем.
Уточни пару вещей, иначе получится гадание. No Acknowledge прилетает на самом адресе устройства или уже после первого байта данных? По логу программатора это обычно видно. И что у тебя за программатор - готовое устройство или самоделка на своей обвязке? От этого зависит, чего вообще ждать от 3.3 В на клетке.
Ещё интересно поведение при подаче питания: отказ одинаковый сразу после установки модуля и после того, как он постоял под питанием пару минут? И все четыре типа ведут себя одинаково или Finisar и HP отличаются: у HP обычно свои причины отказа, их лучше сразу отделить от остальных.
Отчитываюсь по результау. Спаялся на линии I2C напрямую к ножкам 4 и 7, минуя клетку. Finisar пошли: FTLX8571D3BCV-IT записался и обратным чтением подтвердился, FTLX1471D3BCV-IT тоже. GLC-LH-SM перестал выдавать No Acknowledge и пишется нормально.
HP так и не сдались. J4858B запись формально принимает, но после правки модуль коммутатором отвергается, J4859C ведёт себя так же. Так что для меня вопрос закрыт наполовину: Finisar и Cisco теперь пишу, HP отложил в сторону до лучших времён.
С HP ловушка глубже, чем защита записи, поэтому твой результат ожидаемый. На J4858B при правке байтов 68-83, то етсь серийного номера, меняется контрольная сумма в байтах 124-127, и модуль после этого отвергается. Это не MSA-шные CC_BASE и CC_EXT, их посчитать не проблема, а отдельная вендорская сумма в последних четырёх байтах A0. Алгоритм публично так и не разобрали, сколько ни ковыряли.
J9150A из той же истории. А в более новых модулях HP и Aruba вообще ушли от статической суммы к схеме запрос-ответ, HPIDv2, и там программатор бесполезен в принципе. Так что «пишется, но не принимается» - это ровно то, что и должно было получиться.
Раз у тебя парк, а не один модуль, скажу про инструмент. Я под перекодировку для Huawei S5731 и S6730 и для HP 6120XG приспособил UACC-SFP-WIZARD от Ubiquiti - как дешёвый программатор он вполне живой. Только по самим модулям Ubiquiti гуляют списки паролей, записи вида 0x00001011, SFPX, QSFP, и без них часть модулей на запись не открывается. Из образов у меня в ходу FTLX8571D3BCV и FTLX8574D3BCV, реже SNR-SFP+W73-3 и W37-3.
Поправлю обобщение выше, чтобы никто не хватался за паяльник раньше времени: не в каждом SFP+ память спрятана за микроконтроллером. У меня FTLX8574D3BCV и пара SNR-SFP+W73-3 писались обычным программатором в клетке, без всякой пайки. Так что сначала стоит проверить конкретный экземпляр, а уже потом лезть в обохд.
Заземление вывода write protect, кстати, тоже не универсальный рецепт: на модуле с микроконтроллером оно не даёт ничего, там отказ идёт не от памяти, а от прошивки контроллера. Смысл эта операция имеет только там, где стоит честная отдельная EEPROM, и делать её надо на обесточенном модуле, иначе легко получить кирпич вместо модуля.