프로그래머를 사지 않고 라즈베리파이 I2C 버스로 SFP EEPROM 읽고 다시 쓰기
집에 뽑아둔 SFP를 한 무더기 쌓아두고 있는데, EEPROM을 읽고, 체크섬이 깨진 모듈을 고치고, 가끔은 벤더 문자열을 까다롭게 따지는 스위치용으로 재코딩까지 할 수 있으면 좋겠습니다. 1년에 몇 개 안 되는 모듈 때문에 상용 프로그래머를 사는 건 말이 안 되니, 직접 만든 장비로 어디까지 갈 수 있는지 알아보는 중입니다.
작업대 위에 있는 것:
- 제가 직접 배선한 SFP 케이지로 I2C 버스를 뽑아낸 라즈베리파이
- BIOS 작업하고 남은 CH341A USB 프로그래머 보드
- 1G와 10G SFP/SFP+ 모듈이 뒤섞인 더미, 그리고 같이 들여다보고 싶은 QSFP+ 두 개
적어도 버스에서 뭔가 응답은 한다는 의미에서는 읽기가 됩니다:
$ 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 0x50지금까지 해본 것:
- A0h를 손으로 덤프해서 SFF-8472 필드 오프셋과 바이트를 대조함, 느리고 실수하기도 쉬움
- CH341A로 바이트 몇 개를 써봄: 쓰기는 되는데 체크섬을 알아서 재계산해주는 게 없어서, 직접 고치기 전까지는 모듈이 쓰레기 값으로 나옴
- QSFP+ 모듈은 손대지 않고 그대로 둠, 제가 만든 케이지가 SFP만 받기 때문
그래서 이런 작업을 위한 오픈 툴은 실제로 어떤 모습인가요? 메모리 레이아웃을 알고, 쓰기 후 체크섬 바이트를 검증하고, QSFP+ 슬롯까지 구동할 수 있는 게 있나요? 그리고 직접 만든 장비로는 어디까지가 한계인가요?
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
일반 SFP/SFP+ 작업이라면 Pi로 충분합니다. 모듈은 그냥 I2C 디바이스 두 개일 뿐이고, i2cdetect 출력에 0x50과 0x51로 정확히 그렇게 나오는 게 그 증거이며, 그 이상의 마법 같은 건 없습니다. 바이트를 일일이 세는 수고를 덜어주는 게 sfppi입니다. Pi의 I2C 버스를 직접 구동하고, 필드를 대신 디코딩해주고, CC_BASE와 CC_EXT를 검사해서 쓰기 후에 고쳐주겠다고 제안까지 합니다. 이게 바로 CH341A가 안 해주는 부분입니다. CH341A가 쓸모없다는 건 아니고, 읽고 쓰는 건 멀쩡히 되지만 바이트가 무슨 뜻인지는 전혀 모르기 때문에 체크섬은 전부 본인 몫으로 남습니다.
QSFP+ 쪽은 납땜한 케이지로는 답이 안 나옵니다. 커뮤니티에서 다들 가리키는 설계는 Hubble인데, SFP 슬롯 옆에 QSFP 슬롯이 딸린 오픈 프로그래머라, 저 두 모듈을 만지고 싶다면 그쪽이 방향입니다. 쓰기 비밀번호를 아예 거부하는 모듈에 대해 브루트포스로 뚫는 용도로 쓰이는 아주 단순한 Reveltronics 빌드도 있습니다. 저는 그건 써볼 일이 없었으니 참고 정도로만 여기시고, 잃어도 괜찮은 하드웨어에서 먼저 확인해보세요.
제가 보는 것과도 맞아떨어집니다. 두 번째 페이지도 살아 있어서 메모리 양쪽 다 읽을 수 있습니다:
케이지 배선을 제대로 다시 하고 나서, 남겨두고 싶은 것을 손대기 전에 아무래도 상관없는 모듈로 체크섬 경로부터 시도해볼 생각입니다. QSFP+는 당분간 보류합니다. 1년에 모듈 두 개 때문에 케이지를 하나 더 만드는 건 정당화하기 어려우니, Hubble에 그만한 노력을 들일 가치가 있는지 정할 때까지는 읽기 전용으로 남겨둘 겁니다.
다들 직접 만드는 건 아니니 가격대의 반대쪽 끝도 보태자면, 일상적으로 쓰이는 도구는 SNR SFP Writer, SFPTotal Plus 시리즈, 그리고 이미 작업대에 있는 것과 같은 칩인 CH341 보드 기반의 이런저런 자작 장치들입니다.
깊이 들어가기 전에 알아둘 만한 건 모든 모듈이 단순한 EEPROM은 아니라는 점입니다. 일부는 진짜 칩을 내놓는 대신 A0/A2 메모리를 흉내 내는 자체 마이크로컨트롤러를 품고 있는데, 안에 C8051F392가 들어간 Medick SFP-10G-BX가 계속 거론되는 사례입니다. 이런 것들은 쓰기 비밀번호나 벤더 챌린지를 구현할 수 있어서, 버스를 아무리 찔러봐도 멍청한 EEPROM으로 바뀌지는 않습니다. 사람들이 꼽는 제일 지독한 사례는 키가 걸린 HP/Aruba의 인터랙티브 EEPROM입니다.
직접 만드는 케이지에 대한 실전 팁 하나: 핀배열을 제대로 맞추지 않으면 헛것만 쫓게 됩니다. TX_Disable은 3번 핀, Mod_Abs는 6번 핀, VeeR은 9번 핀입니다. 특히 Mod_Abs가 모듈이 꽂혀 있다고 뭔가가 믿어주는지 아닌지를 결정합니다.
그리고 위험한 쪽 얘기도 하자면, 누가 모듈을 하나 죽이기 전까지는 잘 언급이 안 되는 부분입니다. 많은 모듈이 쓰기를 받아들이기 전에 4바이트 비밀번호를 요구합니다. 그 비밀번호 대부분은 공개적으로 떠돌고 있고 만능 유틸리티 같은 건 없어서, 결국 벤더별 도구와 펌웨어 데이터베이스나 제조사에서 뽑아온 이미지들을 잔뜩 끌어안게 됩니다. 그중 하나라도 잘못 건드리면 프로그래머보다 비싼 모듈을 벽돌로 만드는 겁니다.
그러니 EEPROM에 손대기 전에 모듈이 정말로 고장 났는지부터 증명하세요. A0h/A2h에서 DDM 온도, 전압, 바이어스 전류, TX/RX 파워를 읽고, 래치와 접점과 렌즈를 청소하고, 정상 동작이 확인된 모듈로 바꿔 끼워보고, iperf3로 링크에 부하 테스트를 해보세요. 재코딩이 필요하다고 여겨지는 모듈의 절반은 그냥 청소만 하면 됩니다.
납땜보다 돈으로 해결하고 싶다면, 상용 장비들도 나름의 조건이 붙는다는 걸 알아두세요. FS Box는 재코딩이 깔끔하게 되고, 그렇게 해서 FS SFP-GE-BX 모듈을 autoselect가 되는 Intel X710에서 동작시킨 사람들도 있지만, FS 모듈만 프로그램할 수 있고 FS가 아닌 모듈을 꽂으면 계정이 일주일씩 잠기는 대가를 치른 사용자들도 있습니다.