IC-prog zwraca 256 bajtów zrzutu SFP, ale druga połowa to kopia pierwszej, strona A2 się nie czyta (HP 2530-24G)
Prowadzę sieć małego operatora, regularnie flashuję tanie moduły pod HP. Zadanie standardowe: wgrać do tanich chińskich modułów 1.25G WDM obraz firmowego modułu, żeby switch przyjmował je bez marudzenia. Dawca - J4859C, docelowy sprzęt - HP 2530-24G J9776A.
Co mam na stole:
- switch HP 2530-24G J9776A
- moduły OptiCin i Fiberstore, 1.25G WDM
- mini-USB programator NAG
- IC-prog pod Windows, czytam i piszę przez niego
Zrzut ma 256 bajtów, ale druga połowa pokrywa się z pierwszą bajt w bajt:
IC-prog, 0x00-0x7F: прочитано
IC-prog, 0x80-0xFF: тот же самый блок, байт в байт
на части модулей при чтении: No Acknowledge receivedCo już próbowałem:
- przekładałem moduł, czyściłem styki w gnieździe, zmieniałem zatrzask
- przegoniłem trzy moduły z różnych partii, obraz ten sam
- zmieniałem port USB, kabel i komputer, nic się nie zmieniło
Potrzebuję drugiej strony, gdzie są DDM i bajty serwisowe, i po prostu jej nie widzę. To ograniczenie IC-prog, krzywa płytka programatora czy same moduły tak się zachowują?
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 7
Tu są dwa niezależne babole i żaden nie siedzi w modułach.
Pierwszy - sam IC-prog. Ma liniowy model adresowania, nie umie przełączać stron i do A2 w ogóle się nie dostuka. To, co widzisz w drugiej połowie zrzutu, to ta sama A0, odczytana drugi raz. Błędu nie pokaże, bo z jego punktu widzenia wszystko się zgadza.
Drugi - płytka. W tym mini-USB programatorze VccR (pin 15) jest podciągnięty do +5 V, chociaż według SFF-8431 powinien zostać wolny, a poza tym zasilanie i masa są rozprowadzone tak, że część modułów nie wchodzi w normalny tryb. Stąd i
No Acknowledge received- nie na wszystkich pod rząd, tylko na tych, którym ten układ nie pasuje.Co działa normalnie:
i2cdump -y 3 0x50ii2cdump -y 3 0x51, jest otwarty skrypt w Pythonie, który czyta i pisze obie strony.Kryterium proste: jak tylko 0x51 zaczyna odpowiadać, dalej to zwykła praca z pamięcią modułu, a nie walka z narzędziem.
Rozdziel soft od żelaza, inaczej będziesz zgadywał do wieczora. Weź dowolnego Linuksa i sprawdź, czy moduł w ogóle odpowiada pod drugim adresem:
Numer magistrali podstaw swój. Jeśli 0x50 się czyta, a 0x51 milczy - pytanie już nie w tym, czym oglądasz zrzut, tylko czy do modułu w ogóle dociera normalne zasilanie. I napisz, co tym samym programatorem oddaje na pewno żywy donorski J4859C: jeśli u niego też druga strona się nie otwiera, tanie moduły nie mają tu nic do rzeczy, kopać trzeba w zestawie soft plus płytka.
Dawcę przegoniłem najpierw: żywy J4859C w tym samym sokecie i w tym samym IC-prog daje dokładnie ten sam obraz - 256 bajtów, druga połowa powtarza pierwszą. Czyli sprawa nie w tanich modułach. Sprawdziłem jeszcze pod Linuksem przez przejściówkę:
Firmowe narzędzie na tym samym module wypluwa
No Acknowledge received, a IC-prog spokojnie pokazuje kopię pierwszej strony i udaje, że wszystko jest w porządku. Docelowe moduły to OptiCin, obraz zdejmuję właśnie z tego J4859C.Dodam coś o samym zapisie. W 256-bajtowym zrzucie znaczące jest pierwszych 128 bajtów, dalej strefa producenta, zwykle w ogóle nie trzeba jej ruszać. Pod HP wrzucamy obrazy z J4858C i J4859C, dla WDM parę razy starczał zwykły obraz LX: switch przyjmował moduł i na długość fali nie patrzył.
Ale zapisuje się daleko nie wszystko. Na 3Com 3CSFP91 i 3CSFP92, tak samo jak na markowych Allied Telesis, zapis w ogóle nie poszedł: czyta się normalnie, a zapis nie przechodzi - zablokowany WP. Więc jeśli po zmianie programatora A2 się czyta, a zapis po cichu ginie w nicości, przyczyny szukaj nie w softcie.
Zastrzegę się co do „dalej to zwykła praca z pamięcią”. Zwykła ona nie wszędzie. Część modułów to w ogóle nie EEPROM: w Medick SFP-10G-BX siedzi mikrokontroler C8051F392, który emuluje A0/A2 i potrafi żądać hasła albo odpowiadać na challenge. Z zewnątrz wygląda jak normalna pamięć, dokładnie do momentu zapisu. Najcięższy przypadek, jaki mi się trafił, to interaktywny EEPROM u HP/Aruba z kluczami, tam bez gotowego narzędzia nie ma co robić.
A jeśli sam składasz adapter, nie pomyl nóżek: TX_Disable - pin 3, Mod_Abs - pin 6, VeeR - pin 9. Połowa „nieczytelnych” modułów u znajomych okazywała się krzywo złożonym gniazdem, a nie zabezpieczeniem producenta.
Z tego, czym się teraz posługują: SNR SFP Writer, seria SFPTotal Plus i samoróbki na CH341 - zwykle to po prostu płytka z gniazdami pod SFP, XFP, GBIC i QSFP, czasem w drukowanej obudowie. Uniwersalnego softu nie ma, pod każdego vendora osobne narzędzie, obrazy ciągnie się z baz firmware'u i z branżowych forów.
Dwie sprawy, które kosztują drożej niż żelazo. Pierwsza: w wielu modułach siedzi 4-bajtowe hasło, większość z nich dawno opublikowana, ale nie trafisz - dostaniesz cegłę z nietaniego modułu. Druga: zanim wejdziesz w pamięć, upewnij się, że moduł w ogóle żyje. Temperatura, napięcie, prąd polaryzacji i TX/RX z A0h/A2h,
show interfaces diagnostics opticsna Junosie albodisplay interface transceiverna Huawei, potem czyszczenie zatrzasków, styków i soczewek, potem wymiana na moduł na pewno sprawny. Część „martwych” modułów po tym ożywa bez żadnego przeszywania, a obciążenie sprawdzasz już później przez iperf3.Melduję wynik. Złożyłem płytkę na CH341, pod Linuksem 0x51 odpowiedział od razu, druga strona czyta się w całości, żadnych duplikatów pierwszych 128 bajtów. Wgrałem obraz J4859C do OptiCin, HP 2530-24G J9776A przyjął moduł bez słowa, DDM pokazuje sensowne wartości, dobę pod obciążeniem przepracował bez błędów.
IC-prog wywaliłem, żeby się więcej nie kusić. 3Com 3CSFP91, który się tu walał, faktycznie się nie zapisuje: czyta się, a zapis nie przechodzi, więc co do WP wszystko się zgadza. Dzięki, temat zamknięty.