大破ログ

日々大破、それと側転少々。PC関連その他、気になったことなどをつらつらと。

ELECOM WRC-X3000GS3

WRC-X3000GS3 内部

以前よりMediaTek Filogic SoC搭載機であることを把握しており、最近比較的安価な中古出品があったことから確保したものです。

機種の仕様上少々手こずったものの、なんとか解決し投げ込んでマージされました。

まとめていきます。

仕様

MediaTek MT7981Bを搭載するWi-Fi 6エントリー寄り機種としては特段の癖が無く、率直な構成。

  • SoC: MediaTek MT7981B
  • RAM: DDR3 512MiB
  • WAN/LAN: 1000Mbps x1/1000Mbps x4
  • Flash: SPI-NAND 128MiB
  • UART: J500, 115200bps(三角側から3.3V, TX, RX, NC, GND)

その他詳細については、雑記を参照。

OpenWrt化

ヘッダの構造がWRC-X1800GSと近く、factoryイメージを仕立てられています。

  1. WRC-X3000GS3をルータモードで起動
  2. http://192.168.2.1/ のWebUIにアクセスしてファームウェア更新ページを開く
  3. factory.binイメージを選択し、"適用" ボタンを押下してファームウェアの更新を実行
  4. 完了後再起動されOpenWrtで起動してくれば完了

備考

  • Flash内にはOSイメージ用領域が2組存在し、メーカーファームウェアにおいては、更新毎に他方へ書き込まれ更新後はそちらに切り替えられる。ブートに使用されるパーティションpersist パーティション内に存在する bootnum の値によって制御される。

    なお、OpenWrtではこの切り替えは自動的には行わず、手動で切り替えない限りは最初に導入された方を使い続ける。

  • ELECOMのAX3000クラスに該当する機種は大まかに3世代存在するが、今回サポートされるのはGS3のみ。GS2は別のプラットフォームを採用しており、既に別途サポート済。GST2は未サポート。

作業時の色々

  • 上述の通りデュアルブートに対応しているが、これを実現している方法にやや癖があり、OpenWrtにおいて扱う為に追加のドライバを書く必要が生じた。

    ramips targetに存在するいくつかのELECOM/I-O DATA機でも使用できるようにしたが、仕様上少々説明の難しい点が発生し、その関係でマージされるまでに少々時間を要した。

    OpenWrt導入後は、sysupgrade用に追加したスクリプト (/lib/upgrade/elecom.sh) を用いてブートに使用するパーティションを切り替えることで、メーカーファームウェアでのブートに戻せるようにした。

色々

冒頭に書いた通り、ドライバの追加絡みで少々手こずったものの、マージされたので一安心。

現行機種ながら、WRC-X3000GS2より少数ではあるものの中古でも出回るようになり、時折3k台でも見かけるようになった機種。公式で謳う通りGS2よりも小型化され、有線5ポート機では比較的筐体サイズが小さい部類と思われることから取り回しは良さそう。

MediaTek機であることからOpenWrtにおけるネットワーク周りのハードウェア支援系に優れ、単純なNAT性能が欲しい場面に良いかもしれない。

本機種もv24.10シリーズには入らず、その次のメジャーリリースからです。

Check Point V-80, V-81

V-81 内部

以前手広くOpenWrtでサポート可能なデバイスを調べていた際、Check Point公式Forumかどこかであったり、OpenWrt ForumなどでMarvellの64bit SoCであることを知り、気になっていたものです。

Linux Kernelのバグであったり、OpenWrt側の実装不足であったりを修正や改善していて時間が掛かったものの、マージされました。

まとめていきます。

仕様

RAMは同じくMarvell機でサポート済みのFortiGateと同じ2GiBであるものの、SoCとしてaarch64かつ4コアである88F7040または88F8040を搭載。

共通

  • RAM: DDR4 2GiB
  • UART: 115200bps("CONSOLE", USB 1.1 Type-C, CP2102N)

V-80

  • SoC: Marvell Armada 7040 (88F7040)
  • WAN/LAN: 1000Mbps x1/1000Mbps x5
  • Flash: eMMC 4GiB

V-81

  • SoC: Marvell Armada 8040 (88F8040)
  • WAN/LAN: 1000Mbps x2 (RJ-45 x1, RJ-45/SFP x1)/1000Mbps x8
  • Flash: eMMC 16GiB

その他詳細については、雑記を参照。

OpenWrt化

諸々の都合によりfactoryは無く、メーカーファームウェアでのコマンド操作など少々複雑な手順が必要です。

共通

  1. V-80またはV-81を通常通り起動
  2. メーカーのCLIにログインし(デフォルト: admin/admin)、 expert コマンドによってLinuxCLIに遷移する
  3. 以下のコマンドを実行し、U-Boot環境変数にOpenWrtのブートの為に必要なものを追加する

    • V-80:

        fw_setenv bootcmd_ow_usb 'usb start; load usb 0:1 ${loadaddr} boot.scr && source ${loadaddr}'
        fw_setenv bootcmd_ow_emmc 'run set_mmc_internal; mmc read ${loadaddr} ${prim_header_mmc_blk} 4 && source ${loadaddr}'
        fw_setenv bootcmd 'run bootcmd_ow_usb; run bootcmd_ow_emmc; run bootcmd_part${activePartition};'
      
    • V-81:

        fw_setenv bootcmd_ow_usb 'usb start; load usb 0:1 ${loadaddr} boot.scr && source ${loadaddr}'
        fw_setenv bootcmd_ow_sd 'load mmc 0:1 ${loadaddr} boot.scr && source ${loadaddr}'
        fw_setenv bootcmd_ow_emmc 'run set_mmc_internal; mmc read ${loadaddr} ${prim_header_mmc_blk} 4 && source ${loadaddr}'
        fw_setenv bootcmd 'run bootcmd_ow_usb; run bootcmd_ow_sd; run bootcmd_ow_emmc; run bootcmd_part${activePartition};'
      

    注: 各コマンドの引数に付いている '(シングルクォーテーション)は必ず付加する

  4. 電源ボタン等により電源を切る

USB/SDブート

SDからのブートはV-81のみ

  1. squashfs-sdcard.img.gz (または ext4-sdcard.img.gz)をgzip展開の上USBストレージまたはSDカードに書き込み

    • Rufus等を使用する場合、gzipの展開が不要なこともある
  2. イメージを書き込んだストレージをV-80またはV-81に接続し、起動する

  3. OpenWrtで起動してくれば完了

eMMCブート

  1. initramfsイメージ, dtb, bootscriptを適当なUSBストレージのルート階層にリネームの上でコピーする

     initramfs.bin -------> Image
     dtb -----------------> armada-8040-v-81.dtb
     bootscript (.scr) ---> boot.scr
    
  2. 3種を投げ込んだUSBストレージを接続し、V-80またはV-81を起動する
  3. OpenWrtで起動してきたら、 squashfs-sysupgrade.gz(または ext4-sysupgrade.gz)をデバイス上にアップロード(またはダウンロード)
  4. USBストレージを切断し、アップロードしたsysupgrade用イメージを用いてsysupgradeを実行する
  5. 完了後再起動され、OpenWrtで起動してくれば完了

備考

  • V-81に於いては、共通手順の最後で電源を切るまでに、イメージを書き込んだMicroSDは挿入しない。

    電源断前に挿入した場合、メーカーファームウェアにおいてログファイル等の保存に使用する為、1番目のパーティション内の全データが削除される。

  • V-81における "DMZ" ポートのRJ-45及びSFPポートは、接続状況による切り替えは無いようである。切り替えはethtoolコマンドによって行う。

    例: ethtool -s eth1 port fibre

    なお、起動時にSFPポートに接続されている場合は、最初からSFPポートに切り替えられているようである。

    ただ、RJ-45/SFPポートそれぞれに存在するLEDは内部GPIOによって切り替えられる仕様であり、自動的には切り替わらない。そのまま既にアクティブな方で現示させるか、あるいは接続状況により手動で切り替える。

  • V-81のSFPポートにおける最大の電力供給値は 2,000mW (Power Level III) とした。Check PointからこのポートやV-81オプション品として紹介があるDSL-SFPの詳細な仕様は出ていないものの、一般的なDSLモジュールでは大体が3.3V/700mAを仕様としており、単純計算で少なくとも 2,000mA は出せるはず、と判断した。

  • V-80に於いては、内部にMicroSDカードスロットとMiniPCIeスロットを搭載するものとしないものの2種類のハードウェアが存在する。

    現時点で明確にこの差異を示すものは見付かっていないものの、底面ラベルに記載されている Version がそれではないかと推測される。

    • 1.0.1: 無
    • 1.0.3: 有?

    この他、1.0にも実装されている可能性がある。

  • V-80とV-81のそれぞれにおいて、単一のサポートでeMMCやUSB, SDカード全てのブートに対応させる為、sysupgradeにやや制約が生じている。

    USB/SDカード用イメージを書き込んだストレージからブートした場合、eMMCに対するsysupgradeは行えず、現在実行中のブートに使用されたストレージ (USB/SD) へのsysupgradeのみをサポートする。逆に、USBストレージ内のinitramfsイメージ又はeMMCからブートした場合は、eMMCに対するsysupgradeのみをサポートする。

作業時の色々

  • 内部eMMCのパーティション分割には、eMMC内に持つGPTのテーブルではなく、ブートローダから渡された blkdevparts パラメータによって渡されたものを使用している。これが正しくLinux Kernelに渡らない場合、GPT側に抱えるパーティション1つしか認識されない問題が発生する。

    先行したV-80の作業に着手した当初のLinux Kernel 6.1では問題無かったが、その後の6.6において、blkdevparts を解釈するドライバが壊れており、前述の問題が発生した。

    memo205.hatenablog.jp

    MastodonLinux Kernelに詳しい方から色々と教導を受けつつ修正を行って投げ込み、マージされたことでなんとか解決した。

  • 備考で触れたとおり、単一のサポート内でeMMC, USB, SDカード全てのブートをサポートする為、ブートデバイスの切り替えの為にスクリプトが必要となり、eMMC用イメージにおけるkernelデータの構造がやや変則的となっている。搭載されているU-BootでFlattened Image Treeがサポートされていれば、もういくらかマシな状態にできた。

  • シリアルコンソールはリア側にあるUSB Type-Cポートを介して接続する。UARTはV-80/V-81内部でCP2102NによってUSBに変換されている。

色々

eMMCのパーティション絡みが壊れていたり、OpenWrt側の実装の不足絡みでだいぶ手こずったものの、ようやくマージ達成。

V-80で言えば、既にサポートされているFortiGate/FortiWiFiと筐体サイズが大体同じながら、SoCがかなり強力であり、より負荷の掛かる環境にお勧めできそうである。しかもヤフオク等ではOEM品も含め、Cortex-A72 SoC搭載機としてはかなり安くなっている。

この機種でDebianをブートした猛者もいる模様。

www.junk-labs.com

そしてV-81はSFPポートを搭載し、LAN側のポート数が非常に多い点が魅力であるものの、どうも国内における流通数は非常に少ないらしく、中古にもほとんど流れて来ないようである。レア中のレア。

両機種とも、v24.10シリーズには入らない為、その次のメジャーリリースからとなります。

I-O DATA WN-DAX3000GR

WN-DAX3000GR 内部

これも以前からIPQ5018搭載機であることを把握しつつ、何度か確保を迷って先送りにしていたものです。

WRC-X3000GS2を確保したこともあり、ついでにIPQ50xx搭載機も、となって確保しました。

まとめていきます。

仕様

IPQ5018搭載機としては特段尖った点は無く、ath11k世代の無線を搭載する機種のRAMとしては少ない256MiBであったWRC-X3000GS2に対して、こちらは512MiBを搭載。

  • SoC: Qualcomm IPQ5018
  • RAM: DDR3 512MiB
  • WAN/LAN: 1000Mbps x1/1000Mbps x4
  • Flash: SPI-NAND 128MiB
  • UART: J3, 115200bps(三角側から3.3V, TX, RX, NC, GND)

その他詳細については、雑記を参照。

OpenWrt化

ヘッダの構造がWRC-X3000GS2とほぼ同一である為、factoryイメージを仕立てられています。

  1. WN-DAX3000GRをルータモードで起動
  2. http://192.168.0.1/ のWebUIにアクセスしてファームウェア更新ページを開く
  3. factory.binイメージを選択し、"更新" ボタンを押下してファームウェアの更新を実行
  4. 完了後再起動されOpenWrtで起動してくれば完了

備考

  • Flash内にはOSイメージ用領域が2組存在し、メーカーファームウェアにおいては、更新毎に他方へ書き込まれ更新後はそちらに切り替えられる。ブートに使用されるパーティション0:bootconfig0:bootconfig1 内のインデックスによって制御される。

    なお、OpenWrtではこの切り替えは行わず、最初に導入された方を使い続ける。

  • FlashストレージとしてMacronix MX35UF1G24ADを搭載するが、Linux Kernelに登録されている仕様上本来ECC strength=8でも問題無いはずが、実際のアクセス時にI/Oエラーを引き起こす為、1段階下げたECC strength=4でのサポートとしている。

    この関係上、ブート中にSPI-NANDを認識する際 nand: WARNING: (null): the ECC used on your system is too weak compared to the one required by the NAND chip という警告が出るが、無視しても問題無い。

作業時の色々

  • 基板のサイズは然程大きくは無いが、アンテナの設置場所の関係か、はたまた他機種とのある程度の共通化故か、筐体が基板サイズに対してだいぶ大きい。

  • WRC-X3000GS2同様にデュアルブートの挙動にやや癖があり、sysupgrade時の処理はWRC-X3000GS2用に作成したスクリプトを利用するようにした。

  • 基板上に何故かスルーホールでUSB 2.0が用意されている。スルーホールはハンダで埋められていることもあり、これを利用するには筐体の開封とハンダ付けが最低限必要であることから利用機会に乏しいと判断し、Device Treeで無効のままとした。

色々

中古市場ではWRC-X3000GS2よりも少数の印象があるものの、11ax (Wi-Fi 6)世代機でありながら、ミドルレンジ帯故か現在では中古価格が大きく下がり、入手しやすくなった機種。

ハードウェアとソフトウェアの両面でWRC-X3000GS2に非常に近いことから、サポートに伴う新規コード量が抑えられたので良し。

本機種もv24.10シリーズには入らず、その次のメジャーリリースからです。

ELECOM WRC-X3000GS2

WRC-X3000GS2内部

以前からIPQ5018搭載機であることを把握しつつ、元々は確保する予定は無かったものの、事情により確保に至ったものです。

まとめていきます。

仕様

IPQ5018搭載機としては特段尖った点は無いものの、ath11k世代の無線を搭載する機種としては少ない256MiBのRAMを搭載。

共通

  • SoC: Qualcomm IPQ5018
  • RAM: DDR3 256MiB
  • WAN/LAN: 1000Mbps x1/1000Mbps x4
  • Flash: SPI-NAND 128MiB
  • UART: 115200bps(バーコード側から3.3V, TX, RX, NC, GND)

その他詳細については、雑記を参照。

OpenWrt化

必要なヘッダの構造を解くことが出来た為、factoryイメージを仕立てられています。

  1. WRC-X3000GS2をルータモードで起動
  2. http://192.168.2.1/ のWebUIにアクセスしてファームウェア更新ページを開く
  3. factory.binイメージを選択し、"適用" ボタンを押下してファームウェアの更新を実行
  4. 完了後再起動されOpenWrtで起動してくれば完了

備考

  • ath11k (11ax/Wi-Fi 6)世代機としては少ない256MiBしかメモリを搭載しておらず、無線機能によって大量のメモリが消費されてOOMを引き起こすのを防止する為、無線機能はDevice Treeで完全に無効化している。
  • Flash内にはOSイメージ用領域が2組存在し、メーカーファームウェアにおいては、更新毎に他方へ書き込まれ更新後はそちらに切り替えられる。ブートに使用されるパーティション0:bootconfig0:bootconfig1 内のインデックスによって制御される。

    なお、OpenWrtではこの切り替えは行わず、最初に導入された方を使い続ける。

  • FlashストレージとしてMacronix MX35UF1G24ADを搭載するが、Linux Kernelに登録されている仕様上本来ECC strength=8でも問題無いはずが、実際のアクセス時にI/Oエラーを引き起こす為、1段階下げたECC strength=4でのサポートとしている。

    この関係上、ブート中にSPI-NANDを認識する際 nand: WARNING: (null): the ECC used on your system is too weak compared to the one required by the NAND chip という警告が出るが、無視しても問題無い。

作業時の色々

  • 本機種の搭載するメモリは256MiBであり、これはath11k (11ax/Wi-Fi 6)世代機としては少ない。OpenWrtにおいて現在使用されているath11kドライバはメーカーファームウェアほどの最適化はされておらず、メモリ使用量が極めて大きい為に、256MiBでは完全にメモリ不足であり、WRC-X3000GS2において無線機能が有効な状態で起動した場合、ユーザーが使用できるメモリは50MiB未満程度しか残らない。

    作業中に無線機能が有効なinitramfsイメージで起動した際、ユーザーが使用できる領域が30MiB前後にまで落ち込み、LuCIにアクセスした際OOMを引き起こしてシステムプロセスが死亡し、最終的にPanicするなどの事象を引き起こした。

  • デュアルブートの挙動にやや癖があり、少々手間ではあったもののOpenWrtでsysupgrade時に上手く扱うようスクリプトを作成し、対応させた。このスクリプトはメーカーファームウェアに切り替える場合にも使用可能。

色々

11ax (Wi-Fi 6)世代機でありながらも、ミドルレンジ帯故か現在では中古価格が大きく下がり、入手しやすくなった機種。

一部SPI-NAND Flashの関係でドライバも少し弄ることになった為、マージされるまでに多少時間を要するかと思っていたものの、実際にはあっさりマージされたので一安心。

本機種はv24.10シリーズには入らず、その次のメジャーリリースからです。なお、WRC-X3000GST2は現時点で作業予定はありません。

NEC Aterm WG2200HP

WG2200HP内部

WG1400HP/WG1800HP/WG1800HP2に前後して同じQCA9558搭載機であることを把握し、何度か迷いつつ確保し作業を行ったものです。

まとめていきます。

仕様

既に9年程前に発売されたQCA9558搭載機であり、AR9344搭載のWR8750N等よりはやや新しいとはいえ、全体的な構成は古めです。

法律の関係上、無線機能の使用は非推奨です

共通

  • SoC: Qualcomm Atheros QCA9558
  • RAM: DDR2 128MiB
  • WAN/LAN: 1000Mbps x1/1000Mbps x4
  • USB 2.0 Type-A x1
  • Flash: SPI-NOR 16MiB
  • UART: 9600bps(三角マークから3.3V, GND, NC, TX, RX)

その他詳細については、雑記を参照。

OpenWrt化

後述のメーカーファームウェアにおける仕様によりWebUIからの投入が不可能である為、シリアルコンソールでの操作が必要です。

手順はコミットを参照してください。

備考

  • 全てのLEDはSoCではなくI2Cのエキスパンダに接続されており、それ故にエキスパンダの認識が完了するまでは制御することができない。過去に同系統のエキスパンダを採用しているデバイスのサポートが投入された際、kernelのconfigによりドライバがビルトインされるよう構成されている為、幸いにもWR8750Nとは異なりブート中にステータス表示用のLEDとして使用できるようになっている。

  • 内部USBハブのRESETラインがLED同様にエキスパンダのGPIOに接続されており、こちらもLED同様にWR8750N等とは異なり早い段階で構成されUSBポートもすぐに使用可能になる。

  • メーカー出荷時に搭載されているブートローダは、WR8750N等やWG1400HP等と同様にファームウェア領域において特殊なファイルシステムを必要とする。このファイルシステムはOpenWrtで扱うことができず、sysupgradeイメージをFlashからブートすることができない為、initramfsベースのfactoryイメージでブートした際にブートローダをU-Bootへ入れ替える必要がある。

    • このU-Bootは利用できるパーティションサイズが 0x20000 (=128KiB) に限られる関係上、サイズ低減の為にネットワークサポートやその他様々な機能/コマンドを無効化しており、kernelが破損していて文鎮化した際などの復旧には loadbloadx ほかシリアルコンソール経由の投入のみが利用可能。また、環境変数領域の保存に使用できるパーティションが存在しない為、 saveenv コマンドは利用不可。

    • 元のブートローダで設定されている baudrate=9600bps では遅すぎることもあり、U-Bootでは baudrate=115200bps に設定し、Linux Kernelにもそれを渡すように設定済。なお、元のブートローダからinitramfs-factoryイメージをブートした場合は、9600bps で表示される。

作業時の色々

  • WG1800HPの複数バージョンと同様に、WebUIからのファームウェア投入時にファームウェアデータのサイズチェックが行われ、一定以上のデータ長である場合蹴られるようである。手元で確認したところ、現在公式サイトからダウンロードできる全バージョンでこのチェックが行われており、WG1800HPの様に古いバージョンへダウングレードすることによるこの制限の回避ができない。この為、OpenWrtの導入にはどうしてもシリアルコンソールを介した操作が必要となる。

    モチベーション次第では、将来的にU-Bootを使用したWebUIから投入可能な踏台用factoryイメージを独自に出す可能性が無きにしも非ず。

色々

WebUIから投入できない点は引っ掛かるものの、QCA9558を搭載するNetBSDベースなAtermシリーズとしては最後の1つも投入でき、やり切った感が大きい。

モノとしてはこの機種も既に古い為、積極的に確保して使うようなものではないものの、USBポートを搭載しているので余っている個体で遊んでみるには良さそうか。

XikeStor (Seeker) SKS8300-8X

SKS8300-8X 内部

去年(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については、現状作業予定はありません。

NEC Aterm WG1400HP/WG1800HP/WG1800HP2

WG1800HP2内部

2019年頃にWR8750N等に続いて手を出したものの、サードパーティのU-BootにすらSoCのサポートが無いなどの理由で中止し、長らく放置していたものです。

今回WR8750N等に続いてリトライし、何度か文鎮化を乗り越えてサポート作業を完了しマージされました。

まとめていきます。

仕様

いずれも既に10数年前に発売されたQCA9558搭載機であり、AR9344搭載のWR8750N等よりはやや新しいとはいえ、全体的な構成は古めです。

法律の関係上、無線機能の使用は非推奨です

共通

  • SoC: Qualcomm Atheros QCA9558
  • RAM: DDR2 128MiB
  • WAN/LAN: 1000Mbps x1/1000Mbps x4
  • USB 2.0 Type-A x1
  • Flash: SPI-NOR 16MiB
  • UART: CN100, 9600bps(三角マークから3.3V, GND, NC, TX, RX)

その他詳細については、雑記を参照。

OpenWrt化

今回の3機種もWR8750N等と同じ手段でいけた為、2段階ではあるもののfactoryイメージを仕立てることができています。

注: OpenWrt v24.10.0のWG1400HP, WG1800HP, WG1800HP2サポートは想定漏れによる問題を抱えており、公式ビルドのinitramfs-factory.binがブートに失敗します。この問題は復旧にシリアルコンソールが必要な文鎮化を招く為、v24.10.0のinitramfs-factory.binの使用は避け、修正済みのv24.10.1以降を使用してください。

  1. WG1400HP/WG1800HP/WG1800HP2を起動
    なお、ルータモードに設定されていることを前提とする
  2. http://192.168.0.1/ にアクセスし、ファームウェア更新ページに移動
  3. WG1800HPは先にv1.0.2へダウングレード
  4. OpenWrtのfactory.binイメージを選択し、更新実行ボタンを押下
  5. アップデートが完了し再起動後にOpenWrt上にuboot.binとsysupgradeイメージをアップロード(あるいはダウンロード)
  6. uboot.binで "bootloader" パーティションを書き換えてブートローダをU-Bootへ置き換え

     mtd write <uboot.bin> bootloader
    
  7. sysupgradeイメージでsysupgradeを実行

     sysupgrade <sysupgrade.bin>
    
  8. Flashに書き込み後再起動され、OpenWrtが起動して完了

備考

  • 全てのLEDはSoCではなくI2Cのエキスパンダに接続されており、それ故にエキスパンダの認識が完了するまでは制御することができない。過去に同系統のエキスパンダを採用しているデバイスのサポートが投入された際、kernelのconfigによりドライバがビルトインされるよう構成されている為、幸いにもWR8750Nとは異なりブート中にステータス表示用のLEDとして使用できるようになっている。

  • 内部USBハブのRESETラインがLED同様にエキスパンダのGPIOに接続されており、こちらもLED同様にWR8750N等とは異なり早い段階で構成されUSBポートもすぐに使用可能になる。

  • メーカー出荷時に搭載されているブートローダは、WR8750N等と同様にファームウェア領域において特殊なファイルシステムを必要とする。このファイルシステムはOpenWrtで扱うことができず、sysupgradeイメージをFlashからブートすることができない為、initramfsベースのfactoryイメージでブートした際にブートローダをU-Bootへ入れ替える必要がある。

    • このU-Bootは利用できるパーティションサイズが 0x20000 (=128KiB) に限られる関係上、サイズ低減の為にネットワークサポートやその他様々な機能/コマンドを無効化しており、kernelが破損していて文鎮化した際などの復旧には loadbloadx ほかシリアルコンソール経由の投入のみが利用可能。また、環境変数領域の保存に使用できるパーティションが存在しない為、 saveenv コマンドは利用不可。

    • 元のブートローダで設定されている baudrate=9600bps では遅すぎることもあり、U-Bootでは baudrate=115200bps に設定し、Linux Kernelにもそれを渡すように設定済。なお、元のブートローダからinitramfs-factoryイメージをブートした場合は、9600bps で表示される。

作業時の色々

  • このQCA9558ベースの3機種もWR8750N等と同様に、元のブートローダファームウェア領域に置いて謎のファイルシステムを必要とし、通常のLinuxベース機と同じようなプレーンなファームウェアを書き込むと、エラーとして消し飛ばしてしまう。
    それ故、これらの機種も同様にブートローダの置き換えに迫られた。

    • 一番最初にWG1400HPに手を付けた当時、WR8750N等に使用していたサードパーティのU-Boot (pepe2k/u-boot_mod) にはQCA955x SoCのサポートが無く、WR8750N等と同じようにブートローダを置き換えることは不可能であった。
      それ故当時はinitramfsイメージによるブートでおおよそ動作する状態まで構成した後はほとんど放置になってしまった。その後ほとんど無知のままu-boot_modにQCA955x SoCのサポートを追加してみようとしたものの、当然ながら上手くいくことは無く、当時手元にあった個体を文鎮化させただけで終わった。
      今回WR8750NなどAR9344ベースの3機種のサポートを行うにあたり、どうせならQCA9558ベースのこちらもサポートしたいと思い立った。U-Boot公式のAR934xサポートとQCA956xサポートをじっくり読み込み、QSDKやtp-linkのQCA955x搭載機のGPLソースコードを見比べたりするなどして一つずつ組み上げ、SPI-NOR Flashを別基板にFlashライタを接続できる状態に分離して実機デバッグを繰り返し、ようやくなんとかブートが可能なコードを組み立てることに成功した(v2024.10用patch)。
  • U-Bootへの置き換えに絡んで、この3機種でも通常のLinux Kernelを使用している市販の無線LANルータではブートローダが初期化している箇所を、自前で初期化する必要が出た。

    • 具体的にはUSB PHYのRESETの制御が一部漏れていてUSBが使用可能な状態にならなかったり、SoCのEthernet 2本のうち片方のSGMIIが正しく初期化されていない為、もう1本のRGMIIしか使用できない状態であったりした。USBに関してはSoCのDeviceTreeで不足しているビットを追加して処理されるようにし、SGMIIについてはDeviceTreeにおいて必要なプロパティを追加してEthernetドライバによる追加の初期化が走るようにしたり、lzma-loaderにいくつかレジスタ操作を追加して、モード設定を行うようにした。
  • 念の為、sysupgrade実行時にブートローダがU-Bootへ置き換えられているかチェックを行い、もし置き換えられていない場合はsysupgradeを失敗させるように構成した。

  • WG1800HPのみ、WebUIからのファームウェア投入時にファームウェアデータのサイズチェックが行われ、一定以上のデータ長である場合蹴られるようである。手元で確認したところ、現在公式サイトからダウンロードできる3バージョンのうち新しい方の2バージョンはこのチェックが行われている為、OpenWrtのinitramfs-factoryイメージを通すにはチェックが無いらしいv1.0.2へ一旦ダウングレードする必要がある。
    WG1400HP, WG1800HP2ではこのチェックは無さそうである。

色々

もう長らく放置されていたWR8750NなどAR9344搭載機と、今回のWG1400HPなどQCA9558搭載機の両方ともマージを達成したことで、自分の中の達成感も非常に大きい。モノとしては前述の通り既に古い為、積極的に確保して使うようなものではないものの、USBポートを搭載しているので余っている個体で遊んでみるには良さそうか。

QCA9558搭載機についてはU-BootへのSoCサポートまで行うことができたので、過去に諦めた時からの知識の進歩を感じられ、感無量である。今後も諦め悪く色々挑戦して、一つ一つ知識を積み重ねていきたいところ。