Programator zwraca WRITE FAIL na SFP+, który czysto się zrzuca: martwy EEPROM czy coś blokuje zapisy
Większość miesięcy przekodowujemy niewielką partię modułów pod hosty klientów, nic egzotycznego: odczytać oryginalną stronę, wpisać string producenta, jakiego chce host, wsadzić moduł do switcha i jechać dalej. Jeden moduł z bieżącej partii odmawia każdego zapisu, a odczytuje się przy tym bez zarzutu, i zanim go wyrzucę, chciałbym wiedzieć, czy jest jeszcze coś do spróbowania.
Stanowisko:
- programator USB klasy CH341 z płytką breakout do SFP
- moduł SFP+ z obsługą diagnostyki, czyta się dobrze na zimno i po cyklu zasilania
- ten sam zestaw zapisał trzy inne moduły z tej samej tacki godzinę wcześniej
Co narzędzie wypisuje w momencie zapisu:
WRITE FAIL
Ponowny odczyt zaraz po tym daje z powrotem oryginalną stronę bajt w bajt, więc nic w ogóle nie weszło, nawet częściowo.
Co już próbowałem:
- wyjąłem i włożyłem moduł ponownie i zamieniłem płytkę breakout na zapasową
- zapisałem pojedynczy bajt w obszarze, który mnie nie obchodzi, zamiast całej strony, ten sam efekt
- potwierdziłem, że odczyt jest stabilny przez kilka cykli zasilania, więc okablowanie nie jest niepewne
Czy moduł, który czyta się czysto, ale nigdy nie przyjmuje zapisu, jest po prostu zużyty, czy jest coś w samym module, co potrafi celowo odmawiać zapisów?
Comments 5
Czyta się czysto, zapisy odrzucone, oryginalna strona nietknięta potem. Tak normalnie nie zachowuje się zużyty EEPROM. Martwe komórki dają zły odczyt zwrotny albo stronę, która przyjęła połowę zapisu, a nie równy odrzut z niczym nietkniętym.
A skoro odbił się nawet ten pojedynczy bajt poza obszarem producenta, to nie jest zły region na chipie, tylko sam układ odrzuca zapisy hurtowo. Dwie rzeczy warto ustalić, zanim cokolwiek zdecydujesz. Po pierwsze, kto faktycznie zbudował moduł: patrz na string producenta w stronie, którą już zrzuciłeś, nie na to, czym oznaczona była tacka. Po drugie, czy zapis wchodzi, jeśli odpalisz go w momencie pojawienia się zasilania, zanim cokolwiek innego na magistrali zdąży odezwać się do modułu. Prawdopodobne wyjaśnienie różni się w zależności od tych odpowiedzi, i jedno z nich wcale nie jest usterką.
To brzmi bardziej jak ochrona hasłem niż uszkodzenie. SFF-8472 pozwala modułowi z obsługą diagnostyki wymagać 4-bajtowego hasła, zanim przyjmie jakikolwiek zapis. Nie wyślesz nic albo wyślesz złe, a moduł odpowiada na zapis błędem, podczas gdy odczyty zostają całkiem otwarte, co jest dokładnie twoim WRITE FAIL ze stroną wracającą bez zmian. To cecha danej części, nie objaw umierania.
Co to oznacza dla twojego stanowiska: programator, który o tym wie, pozwala wpisać hasło producenta albo hosta, a lepsze z nich brute-forcują nieznane hasło i przeliczają za ciebie sumy kontrolne po zapisie. Zestaw klasy CH341 nie ma w ogóle automatyzacji sum kontrolnych, więc nawet po przejściu hasła musisz sam poprawić sumy, inaczej skończysz z modułem, którego strona wygląda u ciebie dobrze, a host i tak odmawia.
Zwykłe zastrzeżenie: trafiłem na to na garstce modułów i tam droga przez hasło zadziałała, więc wypróbuj to na swojej sztuce, zanim cokolwiek spiszesz na straty.
Dodam do tego: u niektórych producentów te hasła wcale nie są tajne. W obiegu są udostępniane zbiory haseł do transceiverów Ubiquiti, z wpisami takimi jak 0x00001011 i zwykłymi stringami jak SFPX i QSFP, więc jeśli moduł wyszedł z tego ekosystemu, wypróbowanie znanych zajmuje pięć minut, zanim zbliżysz się do brute force'u.
A jeśli chcesz narzędzie, które już zna cały przebieg zamiast walczyć z generycznym programatorem, UACC-SFP-WIZARD to tania opcja, po którą ludzie sięgają. To nie jest instrument laboratoryjny, ale stronę modułu obsługuje jak trzeba.
Z pokrewnych spraw, z przekodowywania modułów pod hosty Huawei S5731 i S6730 oraz starego HP 6120XG. Kiedy to gniazdo albo breakout jest słabym ogniwem, a nie moduł, ludzie lutują bezpośrednio do pinów 4 i 7 na module, czyli linii I2C SDA i SCL, i sterują EEPROM z gniazdem całkowicie poza układem. Brzydkie, i robi się to tylko na sztukach, które jest się gotowym stracić, ale usuwa to całą klasę problemów ze stykiem.
Części, które tu przez to przeszły: Finisar FTLX8571D3BCV i FTLX8574D3BCV, moduły Intel SFP+ LR i SR, SNR-SFP+W73-3 i SNR-SFP+W37-3, plus HP J9150A.
W twoim przypadku odczyt jest już żelazny przez kilka cykli zasilania, więc kontakt to nie twój problem. Najpierw pogoń za wątkiem hasła.
Hasło to prawdopodobna odpowiedź, ale nie zostawiaj tego na „wpisz hasło i gotowe", bo zaraz potem gryzą ludzi dwie rzeczy.
Po pierwsze, w niektórych sztukach wpis trzeba podać ponownie po tym, jak moduł stracił zasilanie, więc skrypt zapisujący kilka stron po kolei musi być gotowy wpisać je ponownie, zamiast zakładać, że jedno odblokowanie starcza na całą sesję.
Po drugie, sumy kontrolne. Z programatorem klasy CH341 przeliczasz je ręcznie. Zostaw je nieaktualne, a moduł nadal będzie się czytał dobrze, twoje narzędzie zgłosi sukces, a host i tak po cichu odmówi modułowi, i wtedy wszyscy znowu zaczynają obwiniać sprzęt. Odczytaj stronę z powrotem i zweryfikuj sumy, zanim ten moduł trafi do switcha klienta.