2026-05-04

ELECOM WRC-X6000QS/GSD

以前よりMediaTek Filogic SoC搭載機であることを把握していたWRC-X6000QSと、それにハードウェア的にかなり近いらしいことから気になっていたGSDの2機種。前者は未所有で、後者は少し前にAmazonの欲しい物リストから寄付があり入手（感謝）。

先行してWRC-X6000QSのサポートが別の方によりオープン済みであり、それを基に改善と共通化を図る形でGSDの作業を行い、諸経緯によりQSも引き継いだ後マージされました。

まとめていきます。

仕様

どちらもMediaTek MT7986BLAを搭載するWi-Fi 6ミドルレンジ機種としては特段の癖が無く、率直な構成。DDR3 RAMはSoCパッケージ内に同封されており、基板上には無し。

共通仕様

SoC: MediaTek MT7986BLA
RAM: DDR3 512MiB（SoC内）
Flash: SPI-NAND 128MiB
UART: J1, 115200bps（三角側から3.3V, TX, RX, NC, GND）

WRC-X6000QS

WAN/LAN: 2.5Gbps x1/1000Mbps x4

WRC-X6000GSD

WAN/LAN: 1000Mbps x1/1000Mbps x4（メーカーファームウェア）, 2.5Gbps x1/1000Mbps x4（OpenWrt）

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

OpenWrt化

構造がサポート済のWRC-X3000GS3と同じであり、factoryイメージを仕立てられています。

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

備考

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

なお、OpenWrtではこの切り替えは自動的には行わず、手動で切り替えない限りは最初に導入された方を使い続ける。
ブート時にU-Bootにおいてシリアルコンソールに表示されるはずのブートメニューはメーカー出荷時点で無効化されており、kernelのブート開始を止めることはできない。OpenWrtを導入後、初めてsysupgradeを行う際に設定値の更新が行われ、ブートメニューが表示されるようになる。

作業時の色々

もうだいぶ前にサポートを行ったWN-DX1167Rが、1Gbpsに対応しているはずのLAN側ポートを100Mbpsまでに制限していた事例もあり、メーカーファームウェアから取り出したGSDのDeviceTreeを見てQSとほぼ同じであることに「もしかしたら」と思ってはいたものの、実際にGSDを入手して開けて見ると、1GbpsまでであるはずのWAN側に使用されているEthernet PHYが2.5Gbps対応のGPY211であり、予想が当たったことにある意味驚いた。
冒頭に書いた通り、既にオープン済みであった、他の方によるWRC-X6000QSのサポートをベースとしてGSDのサポートを追加する作業を開始した。いくつかQSの方でも修正や改善したい点があり、作業内で変更しつつ前述のPR内で指摘を行っていたところ、"引き継いでもらうことは可能か" という提案があったことから、こちらで所有していないWRC-X6000QSの仕様（ハードウェアの挙動など）の確認を行いつつ修正や改善等の取りまとめやGSDとのコード共通化を行い、新規にPRをオープンして（1点指摘を受けたのでそれも修正しつつ）マージされた。
上述の通りデュアルブートに対応しており、WRC-X3000GS3にて作成し投入したドライバで扱えるものであったことから、別の方によるWRC-X6000QSのサポートでもそれを利用して対応されており、GSDでも同様とした。

OpenWrt導入後は、sysupgrade用のスクリプト (/lib/upgrade/elecom.sh) を用いてブートに使用するパーティションを切り替えることで、メーカーファームウェアでのブートに戻すことができる。詳細については各サポートのコミットを参照。

色々

上述の通り、WRC-X6000QSと（恐らく）同じ基板を採用しつつ、GSDでは2.5Gbps対応のWAN側ポートを1Gbpsまでに制限していることに少し驚いた。

記事執筆時点では既に両機種ともディスコンとなっており、WRC-X6000QSは中古がいくらか安価になって来た印象。GSDは中古の出があまり多く無さそうではあるものの、選択肢が増える点は良し。

本機種も1つ前の記事のWSR-3000AX4P同様に、v25.12シリーズには入らず、その次のメジャーリリースからです。

2026-05-04

BUFFALO WSR-3000AX4P

OpenWrt/mediatek

前の記事と同じくAX3000クラスで、今回はBUFFALOのこの機種。発売からやや間は開いたもののファームウェアが公開され、MediaTek Filogic SoC搭載機であることを把握したものです。

某所で安価な出品があり、調達してサポートを実施。

OS用パーティションを2つ持つ構造ではあるものの、やや癖があり、解決し投げ込んでマージされました。

まとめていきます。

仕様

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

SoC: MediaTek MT7981B
RAM: DDR4 512MiB
WAN/LAN: 1000Mbps x1/1000Mbps x3
Flash: SPI-NAND 128MiB
UART: J1, 115200bps（三角側から3.3V, GND, TX, RX）

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

OpenWrt化

factoryイメージを生成するには少し込み入った変更が必要だった為、initramfsイメージを使用した2段階としています。

WSR-3000AX4PのLAN側にIPv4アドレス 192.168.11.2 を持つTFTPサーバを用意し、TFTP用データディレクトリに linux.ubi-recovery にリネームしたinitramfsイメージを置く
WSR-3000AX4PのAOSSボタンを押しながら電源投入し、7秒程度で離す
WSR-3000AX4Pが自動的に linux.ubi-recovery をTFTPサーバからダウンロードし、それを使用して自動的にブートを実行する
ブート後、sysupgradeイメージをアップロードし、それを用いてsysupgradeを実行
完了後再起動されOpenWrtで起動してくれば完了

備考

Flash内にはOSイメージ用領域が2組存在するが、メーカーファームウェアにおいては、1つ目のみがブートに使用され、2つ目は予備として1つ目の破損時やファームウェア更新のみに使用される。

なお、OpenWrtではメーカーファームウェア同様に1つ目のみをブートに使用し、2つ目は予備としても使用していない。
メーカーファームウェアへの戻し方については、サポートのコミットを参照。

作業時の色々

OpenWrt化 に書いた通り、factoryイメージは込み入った変更を加える必要があり、それよりかはBUFFALO機特有のAOSSボタンによるブート時のギミックを使用してしまう方が簡単だった為、factoryイメージについては無しとした。

大まかな構造としては、OpenWrtの "sysupgrade-tar" 形式に旧来からの buffalo-enc が施されているものではあるが、WSR-3000AX4Pのメーカーファームウェアにおいてはsysupgrade-tar形式に含まれる CONTROL ファイル内の文字列チェックがファームウェア更新時に行われている。

OpenWrt公式側ではこのチェックが行われておらず、CONTROL ファイル内に任意の文字列を配置する仕組みが存在していない故に、もしfactoryイメージを実現するにはこの点を変更する必要が生じる。
本機種のサポート開始に前後して、ブログにて "空き容量を優先してほしい" という要望を初めて直接受けた為、今回はこれまで方針としてきた "メーカーファームウェアにおけるレイアウトにできる限り準じ、メーカーファームウェアに戻す際などに影響が最小となるようにする" を少し緩め、本機種のメーカーファームウェアにおいて搭載されている "ネット脅威ブロッカー" が使用する WTB パーティションをrootfs/rootfs_data用パーティションとして使うよう構成した。

この WTB パーティションはメーカーファームウェアでKernelとRootFS用に使用されているパーティション (0x1a00000 = 26MiB)よりも大きく (0x2c00000 = 44MiB)、かつkernelが無くrootfs/rootfs_dataのみで使用可能である為、いくらか空き容量も大きくなる。（ただしUBIである関係上、その管理領域や予備領域で一定サイズを取られる為、パーティションサイズ全量を使用できるわけでは無いことに留意）

このパーティションは、メーカーファームウェアにてブートする際、 "ネット脅威ブロッカー" サービスが起動するときにチェックが行われ、正しい状態に無い場合はフォーマットと再構築が自動で行われる。

色々

ソフトウェア面でやや癖はあったものの、ひとまず解決しマージされたので一安心。

既にディスコンとなっているものの、中古価格はWRC-X3000GS3等と比べてやや高め。筐体は計4ポートに絞っていることもあってか比較的コンパクトで、取り回しは比較的良し。

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

2025-07-23

ELECOM WRC-X3000GS3

OpenWrt/mediatek

以前より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イメージを仕立てられています。

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

備考

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

なお、OpenWrtではこの切り替えは自動的には行わず、手動で切り替えない限りは最初に導入された方を使い続ける。
ELECOMのAX3000クラスに該当する機種は大まかに3世代存在するが、今回サポートされるのはGS3のみ。GS2は別のプラットフォームを採用しており、既に別途サポート済。GST2は未サポート。

2026/03/14追記: WRC-X3000GS4を追記。こちらはRealtek SoCであり、プラットフォーム自体がLinux KernelやOpenWrtにおいてサポートが無い為、機種のサポートも不可。
- WRC-X3000GS(N): Lantiq (Intel) GRX350/GRX550
- WRC-X3000GS(T)2: Qualcomm IPQ5018
- WRC-X3000GS3: MediaTek MT7981B
- WRC-X3000GS4: Realtek RTL8198D

作業時の色々

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

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

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

色々

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

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

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

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

2025-07-22

Check Point V-80, V-81

OpenWrt/mvebu

以前手広く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は無く、メーカーファームウェアでのコマンド操作など少々複雑な手順が必要です。

共通

V-80またはV-81を通常通り起動
メーカーのCLIにログインし（デフォルト: admin/admin）、 expert コマンドによってLinuxのCLIに遷移する

以下のコマンドを実行し、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};'

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

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

USB/SDブート

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

squashfs-sdcard.img.gz （または ext4-sdcard.img.gz）をgzip展開の上USBストレージまたはSDカードに書き込み
- Rufus等を使用する場合、gzipの展開が不要なこともある
イメージを書き込んだストレージをV-80またはV-81に接続し、起動する
OpenWrtで起動してくれば完了

eMMCブート

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

 initramfs.bin -------> Image
 dtb -----------------> V-80: armada-7040-v-80.dtb, V-81: armada-8040-v-81.dtb
 bootscript (.scr) ---> boot.scr

3種を投げ込んだUSBストレージを接続し、V-80またはV-81を起動する
OpenWrtで起動してきたら、 squashfs-sysupgrade.gz（または ext4-sysupgrade.gz）をデバイス上にアップロード（またはダウンロード）
USBストレージを切断し、アップロードしたsysupgrade用イメージを用いてsysupgradeを実行する
完了後再起動され、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

MastodonでLinux 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シリーズには入らない為、その次のメジャーリリースからとなります。

2025-07-22

I-O DATA WN-DAX3000GR

OpenWrt/qualcommax

これも以前から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イメージを仕立てられています。

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

備考

Flash内にはOSイメージ用領域が2組存在し、メーカーファームウェアにおいては、更新毎に他方へ書き込まれ更新後はそちらに切り替えられる。ブートに使用されるパーティションは 0:bootconfig と 0: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シリーズには入らず、その次のメジャーリリースからです。

2025-04-24

ELECOM WRC-X3000GS2

OpenWrt/qualcommax

以前から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イメージを仕立てられています。

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

備考

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

2025-04-24

NEC Aterm WG2200HP

OpenWrt/ath79

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が破損していて文鎮化した際などの復旧には loadb や loadx ほかシリアルコンソール経由の投入のみが利用可能。また、環境変数領域の保存に使用できるパーティションが存在しない為、 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ポートを搭載しているので余っている個体で遊んでみるには良さそうか。