プログラマを買う代わりにRaspberry PiのI2Cバス経由でSFP EEPROMを読み書きする
自宅で抜き取ったSFPを棚に溜め込んでいて、それらのEEPROMを読み、チェックサムが壊れたモジュールを修復し、ときにはベンダー文字列にうるさいスイッチ向けに1つ再コーディングできるようになりたいと思っています。年に数個のモジュールのために商用プログラマを買うのはここでは割に合わないので、自作のリグが実際どこまでできるのか見極めようとしています。
作業台にあるもの:
- 自分で配線したSFPケージにI2Cバスを引き出したRaspberry Pi
- BIOS作業の余りのCH341A USBプログラマ基板
- 1Gと10GのSFP/SFP+モジュールいろいろと、ついでに見てみたいQSFP+モジュール2個
少なくともバス上で何かが応答するという意味では、読み取りはできています:
$ 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+スロットも駆動できるようなものはあるのでしょうか。そして自作リグで足りなくなる境目はどこにあるのでしょうか。
Comments 4
普通のSFP/SFP+の作業ならPiで十分です。モジュールは単に2つのI2Cデバイスにすぎず、それはまさにあなたのi2cdetectの出力が0x50と0x51に示している通りで、それ以上の魔法は何も起きていません。バイトを数える手間を省いてくれるのがsfppiで、PiのI2Cバスを駆動してフィールドをデコードしてくれるうえ、CC_BASEとCC_EXTをチェックし、書き込み後には修正も提案してくれます。それこそまさにCH341Aがやってくれない部分です。CH341Aが役に立たないわけではなく、読み書き自体は問題なくできますが、バイトの意味は一切理解していないので、チェックサムは全部あなたの問題のままです。
QSFP+については、はんだ付けしたケージでは役に立ちません。コミュニティで名前が挙がる設計はHubbleで、SFP用のスロットの隣にQSFPスロットを持つオープンなプログラマです。あの2つのモジュールに触りたいならそちらが方向性になります。書き込みを完全に拒否するモジュールのパスワードを総当たりするのに使われる、簡素なReveltronics製の自作機もあります。私自身は必要になったことがないので、あくまで参考程度に扱い、失っても構わないハードウェアで確認してください。
それはこちらで見えているものと一致します。2つ目のアドレスも生きていて、メモリの両半分とも読み出せる状態です:
ケージの配線をきちんとやり直して、手元に残したいものに触る前に、どうでもいいモジュールでチェックサムの手順を試してみます。QSFP+は今のところ保留です。年に2個のモジュールのために2つ目のケージを作るのは正当化しづらいので、Hubbleに手間をかける価値があるか決めるまではそれらは読み取り専用のままにしておきます。
誰もが自作するわけではないので、価格帯の反対側からも付け加えておくと、日常的に見かけるツールはSNR SFP Writer、SFPTotal Plusシリーズ、それにあなたが既に作業台に持っているのと同じチップであるCH341基板を使った各種の自作機です。
深く踏み込む前に知っておく価値があるのは、すべてのモジュールが素のEEPROMというわけではないということです。実チップを見せる代わりにA0/A2メモリをエミュレートする独自マイコンを積んでいるものもあり、内部にC8051F392を積んだMedick SFP-10G-BXがよく話題に上る例です。そうしたものは書き込みパスワードやベンダーチャレンジを実装している場合があり、バスをどれだけつついても単純なEEPROMには変わってくれません。人々が挙げる一番厄介なケースはキー付きのHP/Aruba対話式EEPROMです。
自作ケージ向けの実用的な注意点を1つ。ピン配置を正しくしないと幽霊を追いかけることになります。TX_Disableはピン3、Mod_Absはピン6、VeeRはピン9です。特にMod_Absは、そもそもモジュールが存在すると何かに信じさせられるかどうかを決めます。
そしてリスク側の話も。これは誰かのモジュールが死ぬまであまり語られないことなので。多くのモジュールは書き込みを受け付ける前に4バイトのパスワードを要求します。そうしたパスワードのほとんどは公開情報として出回っていて、万能のユーティリティは存在しないので、結局ベンダー固有のツールと、ファームウェアデータベースやメーカーから拾ってきたイメージの寄せ集めで対応することになります。どれか1つでも間違えれば、プログラマより高いモジュールを文鎮にしてしまいます。
ですのでEEPROMに触る前に、そもそもモジュールが本当に壊れているのか確かめてください。A0h/A2hからDDMの温度、電圧、バイアス電流、TX/RXパワーを読み、ラッチ・接点・レンズを清掃し、動作確認済みのモジュールに差し替え、iperf3でリンクの負荷テストをしてください。書き換えが必要だと思われているモジュールの半分は、単に清掃すれば済みます。
はんだ付けよりお金を払う方がいいなら、市販の機器には独自の縛りがあることを承知しておいてください。FS Boxは再コーディングがうまくでき、実際にFS SFP-GE-BXモジュールをその方法でautoselect付きのIntel X710上で動かせた人もいますが、これはFS製モジュールしかプログラムできず、FS以外のモジュールを挿入したユーザーは1週間のアカウントロックアウトを食らっています。