書こうかと言いつつ作業に没頭して忘れかけていましたが、書いておきます。
なお、NCP-HG100には型番末尾に "/Cellular" が付くWWAN対応モデルと付かないWWAN非対応モデルがあり、手元にあるのはWWAN対応モデルである為、その仕様を前提として書いていきます。
仕様
オーディオ周りはSoCの機能からしてKernelとOpenWrtどちらにもドライバが無く、現状使用できません。
Model | NCP-HG100 |
---|---|
SoC | Qualcomm IPQ4019 |
RAM | SK hynix H5TC4G63EFR (DDR3 512MiB) |
Flash | KIOXIA THGBMNG5D1LBAIT (eMMC 4GB) |
WAN/LAN (switch) | 1000Mbps x1 / 1000Mbps x1 (QCA8072) |
WLAN | IPQ4019 (SoC, 2.4/5GHz) |
USB | USB 2.0 Type-A x1 |
Bluetooth | Qualcomm CSR8811 |
Z-Wave | Silicon Labs ZM5101 |
Amplifier | Realtek ALC1304 |
Voice Input Processor (for Amazon Alexa Voice Service (AVS)) |
Conexant CX20924 |
MCU | Nuvoton MINI54FDE (RGB LED, Fan, Temperature) |
Touch Sensor Controller | Cypress CY8C4014LQI |
RGB/White LED Driver | Texas Instruments LP55231 x2 |
Bootloader | U-Boot |
OS | QSDK (OpenWrt based), Linux Kernel 4.4.60 |
サポート作業状況
元々 "暇な人" 氏が先行して作業していたものを途中からこちらでも弄り始め、その後氏の事情による活動縮小に伴い本格的に作業を開始しました。コードベースとしては、現在おおよその体感として6-7割程度が氏によるものです。
現状、"ルータとして" 必要最低限程度に動作する状態です。また、現在も作業中でありマージされていないため、使用はおすすめしません。もし使用して何らかのトラブルが発生しても、私や暇な人氏は一切の責任を負いません。
devadd/ncp-hg100 devadd/ncp-hg100_mcu(MCUドライバ試行)
- 現状動作するもの
- initramfsイメージでのブート
- eMMCからのsysupgradeイメージでのブート(要U-Boot設定)
- sysupgrade時の設定保持
- イーサネット
- 無線(2.4/5GHz)認識(実動作未確認)
- LED(底面のLP55231によるもの)
- USB 2.0 Type-Aポート
- RESET, SETUPボタン
- WWANモジュール認識(暇な人氏により確認済)
- 現状限定的に動作するもの
- 現状動作しないもの
- マイクミュート, 音量Up, 音量Down, Alexa呼び出しボタン
タッチパネルを制御するCY8C PSoCのドライバが現状無く、システム起動中のモードから抜けて通常動作モードに移行させることができない為 - ファンコントロール, 温度読み取り
MCUドライバが現状LEDサポート部分のみである為 - Bluetooth UARTに接続されていると思われるが、ドライバの有無やアクティブ化の方法が不明
- オーディオ関連全般
IPQ40xxが搭載するオーディオ関連機能は現状Linux KernelとOpenWrtどちらにもドライバが無く、KernelのMLには2016年にpatchが投げられているものの指摘を受けた後作者から反応が無く完全に停滞。現状マージされる見込みがない また、Conexant CX20924も同様にドライバが無い。KernelのMLにConexantからpatchが投げられているが、2017年を最後にやり取りが途絶えている
- マイクミュート, 音量Up, 音量Down, Alexa呼び出しボタン
作業での色々
- ノリと勢いでMCUとRGB LEDのドライバを書いた
- NCP-HG100のMCU (Nuvoton MINI54FDE) は仕様に書いた通りRGB LEDを搭載しているが、それをLinux KernelのLEDクラスとして登録することでOpenWrtから扱いやすくできないかと考えた。stockファームウェアではあくまでMCUへ値を直接受け渡すだけのsysfsが提供されるのみのドライバであり、参考になる部分があまり多くないので厳しいかなぁと思ったものの、Linux Kernel内やOpenWrt内の色々なドライバを参考にとりあえず書いてみることにした。
結果、知識不足からKernel Panicさせたり色々手こずったりしたものの、OpenWrt内のath79ターゲットに存在するRouterBoard 4xx用ドライバを参考にMCU部分のドライバを、Linux Kernel内のleds-pwmドライバを参考にMCUにぶら下がっているRGB LEDのドライバをいずれもそれっぽいところまで動作するように作れた。勢いは偉大。 - fstoolsでの変更によってコンソールやネットワーク周りなどが壊れた
- Twitterとかでひたすら悩んでたのがこれ。
一度目におおよそ弄りたい範囲を終えてそろそろ投げ込めそうになった頃、念の為ビルドして動作確認してから暇な人氏に連絡取って確認してもらおうということでビルド実施した。ビルド終わってから投げ込んだところ、ブート途中のfailsafeに入るかどうか聞かれるタイミングまでは正常であるものの、それを過ぎるとシリアルコンソール上でEnterキーを押してもBusyBoxのash (shell)が立ち上がらず、OpenWrtのコンソールに入ることができなくなった。同時に、ネットワークもおかしくなっているのかWirelessNetworkWatcherで確認しても出てこない。SSHも繋がらない。
この問題で1週間くらい解決できず止まっていたが、Gitログひっくり返したり目に付くものrevert繰り返したりしてひたすら原因探しをした結果、全く予想外のfstoolsに入った変更が原因だった。
fstools: add partname volume driver git.openwrt.org Git - project/fstools.git/commit OpenWrtのサブプロジェクトであるfstoolsは、デバイスのブート中にユーザー領域としてOverlayfsでマウントする "rootfs_data" パーティション絡みの取り扱いなどを担当している。
SDカードやeMMCの場合、stockファームウェアでのパーティション構成を以下の例とする。"rootfs_data" というデータ保存用のパーティションが存在していることが多い。
OpenWrtにおいては、fstoolsの上記commit以前では "rootfs_data" と名付けられているパーティションを扱えなかった為、 "rootfs" と名付けられたパーティション内(正確にはKernelのcmdlineで指定されているrootデバイス)のSquashFSによるRootFSの後ろに、loopデバイスとしてext4によりフォーマットして "rootfs_data" と名付けた領域を置くことでそれをOpenWrtのユーザー領域として扱っていた。
本来の "rootfs_data" パーティションを使えない状態ではあるものの、2つOSイメージを抱える機種などではユーザー領域を個々のOSイメージ領域内に持たせてそれぞれ独立させることができるなど、有利な点もあった。
が、突如としてfstoolsに入った上記commitの変更により、ブート時に "rootfs_data" パーティションを扱えるようになった(1枚目のstockにおける構成と同じ状態)
ただしここで問題になるのが、NCP-HG100で元々OpenWrtで使用することを想定していたのはあくまで "rootfs" パーティション内に存在する "rootfs_data" のみであり、"rootfs_data" パーティションは全く想定しておらずstockファームウェアでのデータが残されていたこと。
その結果、"rootfs" パーティション内の "rootfs_data" に代わってこのパーティションがブート中にOverlayFSでマウントされてしまい、コンソールやネットワークなどを正しい状態に構成するためのファイルが欠落し、それらに問題を起こしていた。
ちなみに、ipq806xターゲットに存在するZyxel機では、このfstoolsでの変更に起因して4MiBしかない "rootfs_data" がマウントされ(ようとしてフォーマットに失敗するのでtmpfsが代わりに使用され、設定が保存できないので再起動するたびに初期化され)る問題を起こしていた。
NCP-HG100では "rootfs_data" パーティションが約1.6GBのサイズであり、fstoolsの変更が入る前の構成に戻そうとするよりは変更後の状態を活用する方がメリットが大きいと判断したため、sysupgrade周りのコードにおいて "rootfs_data" パーティションを扱うように手を加えて対処した。
NCP-HG100は手元にある /Cellular のサポートとして既に投げ込んでおり、OpenWrtチームからの反応待ち。