Odczyt i przepisywanie EEPROM SFP po magistrali I2C Raspberry Pi zamiast kupowania programatora
Trzymam w domu półkę wyciągniętych SFP-ów i chciałbym umieć czytać ich EEPROM, naprawić moduł, któremu suma kontrolna się rozjechała, i od czasu do czasu przekodować jakiś dla switcha, który jest wybredny co do stringów producenta. Kupowanie komercyjnego programatora dla garstki modułów rocznie nie ma tu sensu, więc próbuję ustalić, jak daleko faktycznie zajdzie domowej roboty zestaw.
Co jest na stanowisku:
- Raspberry Pi z magistralą I2C wyprowadzoną do gniazda SFP, które sam okablowałem
- płytka programatora USB CH341A zostawiona po robocie przy BIOS-ie
- mieszana sterta modułów SFP/SFP+ 1G i 10G, plus dwa QSFP+, którym też chciałbym się przyjrzeć
Odczyty działają, przynajmniej w tym sensie, że coś odpowiada na magistrali:
$ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
$ i2cdump -y 1 0x50Co już zrobiłem:
- zrzuciłem A0h ręcznie i porównałem bajty z offsetami pól SFF-8472, co jest powolne i łatwo się pomylić
- zapisałem kilka bajtów CH341A: lądują, ale nic nie przelicza za mnie sum kontrolnych, więc moduł wraca jako śmieć, dopóki sam ich nie połatam
- zostawiłem moduły QSFP+ nietknięte, bo zbudowane przeze mnie gniazdo przyjmuje tylko SFP
Więc jak właściwie wygląda do tego otwarte narzędzie: czy jest coś, co zna układ pamięci, weryfikuje bajty sum kontrolnych po zapisie i potrafi też sterować gniazdem QSFP+? I gdzie domowej roboty zestaw przestaje wystarczać?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Do zwykłej roboty SFP/SFP+ Pi wystarczy. Moduł to po prostu dwa urządzenia I2C, co dokładnie pokazuje twoje wyjście i2cdetect pod 0x50 i 0x51, i poza tym nie dzieje się nic magicznego. To, co oszczędza ci liczenia bajtów, to sfppi: steruje magistralą I2C Pi, dekoduje pola za ciebie, sprawdza CC_BASE i CC_EXT i oferuje ich naprawę po zapisie. To dokładnie ten krok, którego CH341A za ciebie nie robi. CH341A nie jest bezużyteczny, czyta i zapisuje dobrze, po prostu nie ma pojęcia, co znaczą te bajty, więc każda suma kontrolna zostaje twoim problemem.
Do QSFP+ twoje lutowane gniazdo nie pomoże. Projekt społecznościowy, na który ludzie wskazują, to Hubble, otwarty programator z gniazdem QSFP obok gniazda SFP, więc to jest kierunek, jeśli chcesz dotknąć tych dwóch modułów. Jest też barebonesowa konstrukcja Reveltronics, używana do brute-forcowania haseł zapisu na modułach, które wprost odmawiają zapisu. Sam nigdy jej nie potrzebowałem, więc traktuj to jako wskazówkę i sprawdź na sprzęcie, który możesz sobie pozwolić stracić.
To zgadza się z tym, co widzę tutaj. Druga strona też jest aktywna, więc obie połówki pamięci są dostępne do odczytu:
Przerobię porządnie okablowanie gniazda, a potem wypróbuję ścieżkę sum kontrolnych na module, na którym mi nie zależy, zanim dotknę czegokolwiek, co chcę zachować. QSFP+ na razie zostaje odłożone, budowanie drugiego gniazda dla dwóch modułów rocznie trudno uzasadnić, więc te zostaną tylko do odczytu, dopóki nie zdecyduję, czy Hubble jest wart zachodu.
Dodam do tego z drugiego końca przedziału cenowego, bo nie każdy buduje własny: narzędzia, jakie widuje się w codziennym użyciu, to SNR SFP Writer, seria SFPTotal Plus i różne jednorazowe urządzenia budowane wokół płytek CH341, czyli ten sam chip, który już masz na stanowisku.
Rzecz warta wiedzy, zanim wejdziesz głębiej: nie każdy moduł to zwykły EEPROM. Niektóre niosą własny mikrokontroler, który emuluje pamięć A0/A2 zamiast udostępniać prawdziwy chip, a przykładem wracającym najczęściej jest Medick SFP-10G-BX z C8051F392 w środku. Takie potrafią implementować hasła zapisu albo wyzwania producenta, i żadne grzebanie w magistrali nie zmieni ich w głupi EEPROM. Najbardziej wredny przypadek, jaki ludzie podnoszą, to interaktywny EEPROM HP/Aruba z kluczami.
Jedna praktyczna uwaga do twojego własnego gniazda: dopilnuj pinoutu, bo inaczej będziesz gonił duchy. TX_Disable to pin 3, Mod_Abs to pin 6, VeeR to pin 9. Mod_Abs w szczególności decyduje, czy cokolwiek w ogóle wierzy, że moduł jest obecny.
A od strony ryzyka, bo rzadko się o tym wspomina, dopóki ktoś nie ma martwego modułu. Wiele modułów chce 4-bajtowego hasła, zanim przyjmie zapis. Większość tych haseł krąży publicznie i nie ma jednego uniwersalnego narzędzia, więc kończysz ze stosem narzędzi i obrazów specyficznych dla producenta, wyciąganych z baz firmware albo od producenta. Pomyl się w czymkolwiek z tego, a zamurujesz moduł, który kosztował więcej niż programator.
Więc zanim w ogóle dotkniesz EEPROM, udowodnij, że moduł faktycznie jest zepsuty: odczytaj z A0h/A2h temperaturę DDM, napięcie, bias current i moc TX/RX, wyczyść zatrzaski, styki i soczewki, podstaw znany dobry moduł i przetestuj link obciążeniowo przez iperf3. Połowa modułów, które rzekomo potrzebują przeszycia, potrzebuje po prostu czyszczenia.
Jeśli wolisz zapłacić, niż lutować, miej świadomość, że komercyjne skrzynki mają swoje własne haczyki. FS Box faktycznie ładnie przekodowuje, ludzie w ten sposób uruchomili moduły FS SFP-GE-BX na Intel X710 z autoselect, ale programuje wyłącznie moduły FS, a włożenie modułu spoza FS przyniosło użytkownikom tygodniowe blokady konta.