I-O DATA WN-DX1167R / WN-AX1167GR2

分けようかと思ったけど、内部構成似通ってるので1つの記事にしました。
去年9月末にPRをオープンして4か月と少し、やっとマージされました。I-O DATAで現在ミドルレンジ付近を担うこの2機種です。まとめていきます。

仕様

2機種とも、一つ世代が古く以前記事を書いたWN-AX1167GRと同じくMT7621Aを搭載しています。しかしそれ以外の内部構造は、この2機種ともWN-AX1167GRとは大きく異なり、全体的にイマドキな構成になった、という印象を受けます。
何より、どちらも128MiBのNAND Flashを搭載しているのが一番の衝撃。（まさか国内メーカーがこの価格帯で搭載してくるとは）
無線はいずれもMT7615Dを搭載し、2.4/5GHz両バンドを1チップでカバーしています。ただし、法律の関係上使用は非推奨です。

WN-DX1167R

SoC: MT7621A (880MHz, 2C4T)
RAM: DDR3 128MiB
Flash: NAND 128MiB
WAN/LAN: 1000Mbps x1/100Mbps x4
UART: J5, 57600bps（SoC側からVcc, TX, RX, NC, GND）

WN-AX1167GR2

SoC: MT7621A (880MHz, 2C4T)
RAM: DDR3 128MiB
Flash: NAND 128MiB
WAN/LAN: 1000Mbps x1/1000Mbps x4
UART: J5, 57600bps（SoC側からVcc, TX, RX, NC, GND）

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

注意事項

※2020/04/29 追記

本記事の2機種は、Snapshotファームウェアでの使用は全く推奨できません。ハードウェアに複数の特殊な点が存在し、それに起因してOpenWrtにおいてバグを踏んだりするなどしてブート不能に陥る事態を度々起こしているほか、特定の状況下でそうなった場合復旧が非常に困難であるためです。将来の20.xリリースに含まれることが予想されるため、それまで待つことを強く推奨します。

詳解

ブートに関して: WN-AX1167GR2, WN-DX1167Rは、上記仕様の通りNAND Flashを搭載している。ブート時、ここからKernelを読みだすのはU-Bootが直接行っているのではなく、 "Z-LOADER" がU-Bootから実行され、それがNAND Flashからの読み出しとLZMA圧縮されたKernelの展開及び実行を行っている。
この時、U-Bootは通常のMT7621機と異なり、よくある1～4などのメニューは表示されず、その他中断できるタイミングも無くZ-LOADERが呼び出され実行が移ってしまう。また、Z-LOADERもFlash内の特定箇所にある debugflag が無効である場合、中断を許容せずそのままKernelの展開と実行に移ってしまう。 debugflag はデフォルトで無効化され出荷されているため、Kernelの開始前にブートを止めることは一切不可能ということである。
この点はもし何らかのトラブルが生じてKernelがブートできなくなった場合、即座に復旧不能となることを意味するため、それを防ぐためにOpenWrtにおいては debugflag を有効化するように構成している。しかしながら、その有効化を行うのはどうしても "最初にブートされるOpenWrtが正常にブートを完了し、次のOpenWrtファームウェアへのsysupgradeが実行される" 際である。つまり、最初にブートされるOpenWrtファームウェアに何らかの問題が存在し、正常にブートせず止まってしまう、あるいはブートループとなる場合、debugflag を有効化することができず、復旧手段が無いまま文鎮となるということである。
OpenWrtにおいて、この2機種のサポートがマージされた後複数の原因により何度かこの "最初にブートされるOpenWrtファームウェアに問題がありブートが止まる" 問題を起こしており、現状では日々何らかの変更が行われるSnapshotファームウェアを使用することは全く推奨できない。
PCIeの問題: ramips/mt7621 subtargetがKernel 5.4に引き上げられた際、MT7621のPCIe関連のドライバがOpenWrtで抱えていたものからLinux Kernelに存在するものへ切り替えられた。この際、OpenWrt内に存在するほとんどの機種では全く問題は無かったが、WN-AX1167GR2, WN-DX1167Rの2機種ではPCIe周辺でハングしてブートが止まる問題が発生した。この2機種では無線にMT7615Dを搭載し、2.4/5GHz帯の両方を1チップでカバーしている。このMT7615Dはほとんどの類似機種ではMT7621の1番目のスロット (pcie0) に接続されているが、この2機種においては2番目のスロット (pcie1) に接続されている。この1番目と2番目のスロットは同一のphyによって提供されるものであるが、ドライバ側のバグにより、1番目のスロットが未使用である場合に2番目の有無にかかわらずphyの電源が切断されてしまい、2番目のスロットの処理が停止してハングするというものだった。
OpenWrtのMLで報告が上がってLinux Kernel側のドライバを担当した人へも報告が行き、しばらくして修正が行われた。
(ramips: mt7621: backport more pcie driver fixes · openwrt/openwrt@51c6b14)
Kernelサイズの問題: ramips/mt7621 subtargetがKernel 5.4に引き上げられた際、それまでのKernel 4.14のファームウェアと比較してKernelサイズが肥大化した。これに起因し、OpenWrtに存在する多くのMT7621機でU-BootがLZMAを展開する際にエラーとなる、あるいはエラーにならないまでも展開が不完全となって後部のデータが欠落し、Kernelがブート中にDeviceTreeのノードを見つけられずpanicしてブートが停止するという問題が発生した。これにはWSR-1166DHPほか国内メーカーの複数の機種も含まれ、また本記事の2機種も例外ではなかった。
WSR-1166DHPほか国内メーカーのMT7621機はおおよそ修正を行ってマージされたほか、WN-AX1167GR2, WN-DX1167Rについてもsysupgradeファームウェアの修正を行ってマージされた。しかしながら、修正作業中に確認した際正常に機能したinitramfsファームウェアについてもこの問題が存在することが後から判明し、~~現在修正作業中~~。
2020/05/25 追記: initramfsファームウェアの修正を行い、マージ済み。公式ビルドで正常にブートできることを確認済み。
(ramips: fix initramfs image for I-O DATA mt7621 devices · openwrt/openwrt@0a05d71)

OpenWrt化

initramfsイメージを使用してインストールできるようになっているものの、Flash内部にOSイメージを2つ持つ構成であるため2段階でのインストールが必要です。

WN-DX1167R（またはWN-AX1167GR2）を起動: 電源ケーブルを繋ぎ、普通に起動
WebUIにアクセス: PCとWN-DX1167R（またはWN-AX1167GR2）をLANケーブルで接続し、 http://192.168.0.1/ へアクセスしてファームウェア更新ページへ移動する
ファームウェア更新: 機種に合わせたOpenWrt initramfsイメージを選択し、アップデートを実行
sysupgradeを実行: 上の手順を実行後再起動されOpenWrtで起動してくるので、そこでさらにそれぞれの機種のsysupgradeイメージを用い再度ファームウェアの更新を行う。これを行わないとinitramfsイメージでブートした状態であるため、変更した設定などが保存されない。
完了: Flashへのsysupgradeイメージの書き込みが完了後再起動され、OpenWrtで起動してくる

備考

sysupgradeを行う際、 debugflag をチェックして無効になっている様であれば有効化するように構成した。これにより、もし何らかの原因によりKernelがブートしなくなっても筐体を開けてUARTを接続し復旧することが可能になる。
メーカーファームでは前述のとおり2つOSイメージのパーティションをFlash内に持っており、ファームウェアの更新が行われる度にその時起動していたのとは別のもう一方へ切り替えられ、交互に使用される。OpenWrtでは例外はあるものの基本的に片方のみを使用する必要があるため、1つ目のパーティションに固定した。sysupgradeが行われる際、debugflag と同様にブートするパーティションの指定を行う bootnum の値もチェックし、もし 2 が設定されている場合は 1 へ変更する。
繰り返しになるが、OSイメージのパーティションが2つ存在する関係上、OpenWrtがKernel, RootFS, ユーザー領域で使用できるサイズは合計で 50MiB (0x3200000) ほど。

作業時の色々

両機種ともメーカーファームではMSTCが手を加えたuImage形式のヘッダがKernelに付加されている。このヘッダに関しては、5ch方面で先にWN-AX2033GRの作業をされていた方がGPL ソースコードの開示請求を行い、それによって提供され公開されたコードにより知ることができた。某氏に非常に感謝。
当初このuImageはinitramfs, sysupgradeどちらのイメージでも使用することを考えたが、しかしながらその場合OpenWrtのmkimage周りに改変が必要になることから、Cの知識も怪しく悩ましく感じた。
その後色々調べていると、この改変済みuImageが必須であるのはメーカーファームによるチェックのみでU-Bootは通常のuImageでも特に問題無く起動できることがわかり、またgzipが作成したアーカイブ末尾にこの改変済みuImageに必要なファイルサイズとCRC32値を吐き出すことを知り、これを最終的に利用して済ませることができた。
mkimageに手は加えず、別途firmware-utilsに何らかを追加して加工することも考えたが、加工を行う必要があるのがinitramfsイメージのみであり、それだけのためにfirmware-utilsを追加するのもな、と考えてしまい、gzipを利用する方法を採った節もある。

色々

時間は掛ったが、やっとマージされひとまずホッとした。そしてだいぶ肩の荷も降りた。
この2機種はMT7621A搭載機としては比較的実売価格が安価であり、なおかつ同様なELECOM WRC-1167GHBK2-Sが製造終了となったため、今後新品での継続的な入手性ではこちらが優位。Flash容量も大きく、活用できる範囲はだいぶ大きいと思われる。