去年（2024年）5月頃にGitHub Sponsors経由で購入分をご支援頂き、確保したものです。
いくつかトラブルが解消できず保留にしていたものの、OpenWrt側でネットワーク周りの修正が行われ、問題が解消した為サポート作業を完了しマージされました。
まとめていきます。
仕様
8ポートものSFP+を搭載し、ツイストペアは非搭載という割り切った構成です。RAMは512MiBという大容量を搭載。
- SoC: Realtek RTL9303
- RAM: DDR3 512MiB
- LAN: SFP+ x8
- Flash: SPI-NOR 32MiB
- UART: "Console", 9600bps（所謂Ciscoケーブル互換）
その他詳細については、雑記を参照。
OpenWrt化
今回factoryイメージは無い為、initramfsイメージを使用しての導入が必要です。
少々長い為、コミットの説明を参照してください。
realtek: add support for XikeStor SKS8300-8X · openwrt/openwrt@0dc0b98
備考
OpenWrt導入時のinitramfsイメージでブートする際、稀にLinux KernelがIRQ絡みのエラーを吐いて再起動（あるいはそのまま固まる）することがある。
頻度は然程高くないこと、sysupgradeイメージ書き込み後は発生しないことから現状後回しとなっており、もし遭遇した場合は再起動してやり直す。
メーカーファームウェアではOSやユーザー設定を格納する領域全体にJFFS2が使用されており、各データファイルはその中に格納される形となっている。
U-Bootもブート時にそれを期待してJFFS2からkernelの読み出しを行うが、OpenWrtにおいてはKernelバイナリのみがJFFS2内に存在する状態としたこと、またRootFSの後ろに置かれるユーザー領域用のJFFS2がSKS8300-8XのU-Bootで対応していないフォーマットを使用しているらしく、読み出し時に警告をいくらか出すが、特段問題無くブートできる為現状放置としている。
国内のユーザーがXikeStorに問い合わせた結果、SFP+ 1ポート当たり最大2.9W前後、トータルで最大15.8Wをおおよそ供給できるという回答を得られた。この為、全てのポートに2.9Wを割り当てることはできないものの、可能な限り最大値を割り当てる為として、各ポートに対する割り当ては発熱も考慮して以下の通りとなっている。
port 1 2 3 4 5 6 7 8 max (W) 2.9 1.5 1.5 2.0 2.0 1.5 1.5 2.9 total:
15.8W =2.9 x2 + 2.0 x2 + 1.5 x4モジュールが要求する電力を下回るポートで使用した場合、モジュールが使用できる電力量が制限されたり、場合によってはLinux Kernelによって使用不可として扱われることがある為注意する。
小型ONUは1.5Wの要求に留まる為、どのポートでも正常に認識されるはずではある。
RTL930xのネットワーク関連ドライバは未だ発展途上にあり、未サポートになっている機能や、使用できないモジュール等がしばしば存在する。
メーカーファームウェアへの復元については、上記サポートコミットの説明を参照。
作業時の色々
SKS8300-8Xを調達し作業中、SFP+ポートへ接続されている SerDes (Serialize-Deserialize)がどうにも正しく立ち上がってこず、ネットワークの疎通を得られない状態に陥った。これを長らく解決できなかった為、Flash内のバックアップ等もできず、結果的に作業をしばらく保留とすることになってしまった。
その後しばらくしてRTL930xのネットワーク周りの改善などが行われた為、再度試したところ正常に機能するようになったことが確認できたことから作業を再開し、いくつか悩まされながらも完了して投げ込んだ。
前述の通り、KernelバイナリはJFFS2内に存在し読み出されることが期待される構造となっているが、このKernelバイナリは暗号化が施され、読み出した後先頭512 bytes (
0x200)のみ復号してブートに進む形になっていた。当初この暗号化方式は単純なxorかと推測したものの、実際には1byte毎の加減算であり、暗号化と復号においてキーはどちらも同じものが使用されるものの、処理の手順が一部異なっており、それの特定に少々時間を要した。
上記の暗号化方式のほか、Kernelバイナリを格納するJFFS2の生成方法にもかなり時間を取られた。
SKS8300-8XはSPI-NOR Flashを搭載しており、OpenWrtのrealtek/rtl930xではLinux KernelでSPI-NORのErase Sizeが64KiBで設定されているほか、mkfs.jffs2がサポートしている設定値も8KiBが最低値であったことから、何も考えず64KiBだろうと生成用コードを記述した。が、それで生成されたJFFS2を書き込んで試してみても、どうにもU-Bootにおいてfsloadがエラーは出さないのに正しく読み出せず、行き詰ってしまった。ひたすらオプションを弄って試したもののダメで二進も三進も行かなくなったが、ある時ふとSPI-NORの4KiBセクタについて思い出し、もしやと思って確認したところ、メーカーファームウェアではJFFS2のマジックナンバーが4KiB毎に存在しており、これが原因であることが判明した。
その後、OpenWrtがイメージ生成用として抱えるmkfs.jffs2では4KiB以上のErase Sizeをサポート済であることから、これを利用して生成を行い、実機に書き込んで正しくブートさせられることを確認した。
作業開始当初、どうにかしてU-Bootに入れないかと試行錯誤していたところ、誤ってブートローダ領域の一部を吹き飛ばし、ブート不可に陥らせてしまった。
止むを得ずもう1台調達の上、SPI用のFlashライタにより両方の個体から読み出して、故障機のダンプのブートローダ部分のみを正常機のものに入れ替えた上で故障機に書き込み、復旧した。
まずバックアップを取っておけという勉強代外部でWatchdogチップを搭載しており、ブートローダではRTL9303が持つハードウェア制御のシステムLED機能によって、点滅状態をkeepaliveとして送出することで当該チップを扱っていた。
このシステムLED機能に使用されるピンはGPIOに向けることもできる為、Linux KernelのGPIOベースなWatchdogを使用するよう変更しようとしたものの、どうにもドライバによる初期化タイミングに間に合わずブート中にリセットされてしまう為、諦めてシステムLED機能に任せることとした。
色々
旧Twitterにて話題になった頃に少々興味を惹かれつつ、見送っていたところに支援頂いて確保したものの、しばらく保留となってしまっていたので、マージ到達したことで一安心。
Linux Kernelにおいて意外とRTL930xのドライバ類の投入が進んでおり、そのうち素のLinux Kernelだけでもネットワーク周りを含めた十分な動作ができるようになれば面白いところ。
SKS8300-8XのSFP+ポートでモジュールの制御に使用されているI2Cドライバも既に上流でマージされていることから、時間のある時にbackportなどの変更を投げ込み予定。
12ポートモデルのSKS8300-12Xや、後継と思しきSKS8310-8Xについては、現状作業予定はありません。
