NEC Aterm WF1200CR

某氏によって投げ込まれたWG2600HP3に続き、OpenWrtのAtermに5機種目が加わりました。今回はWG1200CR同様にコンパクトなこの機種です。
少し前に東久留米のハードオフへ行った際、ジャンクでかなり安く転がっていたので衝動的に購入しました。
マージされたのでまとめます。

仕様

既にサポート済みのWG1200CRが搭載するQCA9563に近いQCA9561を搭載しています。SoC以外には、スイッチ用チップを搭載しない以外はおおよそ同じハードウェア構成です。
OpenWrtにおける無線機能の仕様は、 法律の関係上非推奨です

  • SoC: Qualcomm Atheros QCA9561(750MHz, 1C1T)
  • RAM: DDR2 SDRAM 128MB (Winbond W971GG6SB-25)
  • Flash: SPI Flash 8MB (Macronix MX25L6433F)
  • WAN/LAN: 100Mbps x1 / 100Mbps x1 (QCA9561)
  • UART: 115200bps(”JP1″ 側から3.3V, GND, NC, TX, RX)

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

OpenWrt化

メーカーファームウェアが1.3.2未満である場合、factoryイメージを利用して直接導入することができます。1.3.2以降はオフラインアップデート機能が廃止され手動での投げ込みが不可能となった為、この方法は使用できません。

WF1200CRを起動
WF1200CRに電源ケーブルを繋ぎ、普通に起動。
WebUIにアクセス
PCとWF1200CRをLANケーブルで接続し、 http://192.168.10.1/にアクセスしてファームウェア更新ページへ移動する
ファーム更新
WF1200CR用のfactoryファームを選択し、アップデートを実行
完了
Flashへの書き込みが完了後再起動され、OpenWrtで起動してくる

既知の問題

“POWER” 以外のLEDが使用できない
WF1200CRではWG1200CR同様に搭載するLEDの個数が多すぎるため、”POWER” に存在する緑/赤のLED以外は全て5GHz帯用に搭載されているQCA9888に接続されています。
ath10kドライバでは無線チップに搭載されるGPIOコントローラを制御する仕組みは提供されておらず、OpenWrtから制御できないため、そこに接続されるLEDは使用できません。

作業時の色々

  • WG1200CRの作業時に色々手こずったこともあり、今回はそれを踏襲できた為ある程度スムーズに作業を進められた。
  • QCA9561は初めてで、それにおけるネットワークの構成についても初めてではあったものの、OpenWrtで既存の機種を参考に構成できた。

色々

PRオープン後は1点のみ見落としによる問題があったものの、解決したうえで比較的早くマージされたので良し。
WG1200CRが今現在も販売中である一方WF1200CRは既に終了となっており、中古価格も大きく落ちてきているので低電力で速度を必要としない何らかを動作させる用途に良いかもしれない。

INABA Abaniact AML2-17GP

自分初のrealtek targetデバイス。
もうだいぶ前に吉川のハードオフで物色していた際、偶然見つけたもの。初対面ではこの機種の詳細を把握していなかったので一度見送り、メーカーサイトで調べたうえでVLANなど対応しているのは良いなと思い後日購入。
当時realtek target(注: 当初はrtl838x target)は姿形全く無く、あくまで普通のスイッチングハブとしての使用しか考えていませんでした。
色々な経緯を辿り偶然にもrealtek targetに属するSoCを搭載することからサポートを投げ込み、マージされました。
なかなか書くタイミングが無く遅くなったものの、まとめていきます。

仕様

Realtek SoCの中でも、スイッチングハブ向けであるRTL8382Mを搭載。SoCの8ポートのほか、RTL8218Bを1つ追加で搭載しもう半分の8ポートを、RTL8214FCでWAN/CONSOLEポートを担当しています。
UARTはボックスヘッダが使用されており、ケーブル側としてMolex 530470410の嵌合相手であるMolex 510210400が使用できます。

  • SoC: RTL8382M (500MHz)
  • RAM: DDR3 128MiB
  • Flash: SPI-NOR 32MiB
  • Ethernet: 1000Mbps x17
  • UART: J14, 115200bps(リア側から3.3V, GND, RX, TX、Molex 530470410互換)

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

OpenWrt化

仕様上squashfs形式のイメージを直接使用できないため、initramfs-kernelイメージを使用し2段階で導入します。

AML2-17GP
通常通り電源を接続して起動
ファームウェア設定ページを開く
PCをAML2-17GPの “WAN/CONSOLE” ポートに繋いで http://192.168.1.148 にアクセスし、ファームウェア設定ページ(”デュアルイメージ”)を開く
1番目のイメージをアクティブに設定
パーティション 0 のイメージをアクティブに設定する
ファームウェア更新
ファームウェア更新ページを開き、

  • アップグレード方式: HTTP”
  • アップグレードタイプ: イメージ
  • イメージ: アクティブ

と設定したうえでOpenWrtのinitramfsイメージを選択して更新を実行

再起動
更新完了後再起動するか聞かれるので、OKを押下して再起動
sysupgrade実行
OpenWrtのinitramfsイメージで起動するので、 “WAN/CONSOLE” ポートから “1” ポートに繋ぎ変えたうえでVLAN 100を設定して192.168.1.1にSSHでアクセス、sysupgradeイメージを使用してsysupgradeを実行
完了
Flashへの書き込みが完了後再起動され、OpenWrtで起動する

備考

  • AML2-17GPはフロントに “POWER” LEDがあるものの、GPIOには接続されておらず電源線直結であるため、OpenWrtから制御できない。従ってシステムステータスを表示できず、ブート中に点滅させたりできない為、経過時間からブートしたかどうか判断する。
  • 上記の導入手順からわかるとおり、OSイメージ2つをFlash内に抱えている。Realtek SoCを搭載するスイッチングハブでは一般的な仕様である模様。
    ファームウェア投入時、uImageヘッダに埋め込まれたデータサイズのみFlashに書き込まれる仕様であるため、squashfs形式のイメージを使用した場合、そのデータサイズが示すKernel部分のみ書き込まれRootFSは欠落する。この結果、ブート時にKernelがRootFSを見つけられずpanicしてbootloopを起こすため、一旦initramfsイメージを書き込む必要がある。
  • “WAN/CONSOLE” ポートはデフォルトではOpenWrt上で使用可能なポートとして割り当てていないため、必要な場合はネットワークのconfigを修正するなどして割り当てる。
  • マージされた時期の関係から、21.02リリースには含まれない。
  • フロントに配置されている “RESET” ボタンは、メーカーファームウェアにおいては再起動しか行われず設定初期化はできないが、OpenWrtでは通常のOpenWrtを投入したルータと同様に長押しで設定初期化、短い押下で再起動する。

作業時の色々

  • 雑記を見るとわかるとおり、確保した当時realtek target(旧rtl838x target)は存在せず、またRealtek SoCは無線機でもLinuxやOpenWrtでのサポートが無いことから、まずOpenWrtを動かすことなど考えていなかった。ただ、AML2-17GPに設定されていたパスワードを初期化するために開けたところLinuxを使用してはいたので、雑記に恒例のメモはなんとなく書いた。
    その後、偶然Forumでスイッチングハブ向けRealtek SoCにおけるOpenWrtサポートについてのtopicを見つけて、本当に偶然にこの機種が該当することに気付いて、試しに作業している方のコードを利用してOpenWrtを動かしてみるなどした。
    その縁からその方と一緒にいくらか作業することになり、当時その方のコードがベースとしていたKernel 4.19から、OpenWrt内で移行が進んでいたKernel 5.4への移植をある程度手伝うなどした。今振り返ると、わかる範囲であるものの自分でも驚くほどコード書き直したり整理したりしている。
  • 長らくUARTボックスヘッダの仕様が不明で、無理矢理クリップで繋いでアクセスしていたものの、ピン感覚が狭いため非常に面倒だった。
    さすがに面倒極まりないのでMastodonで詳しい各位に聞いたところ、 “製造が中国方面であるなら日本圧着端子製造かMolex互換が定番なのでその辺りではないか” という意見や、 “実物のおおよそのサイズからMolex 530470410が近いのでは” という意見があり、その後思い切ってMolex 530470410嵌合相手である510210400 (51021-0400) を千石電商で購入し試したところ、寸分違わずピッタリであった。
    なお、ケーブルが細い他コンタクトが小さく扱いが面倒であるため、可能ならば自前で圧着するよりもケーブル圧着済みのものを確保することを推奨。

色々

少々いくつかの問題がありサポート作業に時間がかかり、PRをオープンした後も少し時間を要したものの、マージされたので一安心。
ただしこの機種は、メーカーやブランドの位置付けからして住宅やアパート等向けと思われ、一度設置した後は故障するまでそのままとなることがほとんどとなりそうで、それ故にオークションやフリマ等検索しても見つからないのかもしれない。ハードオフで、しかも2つも見つけて入手できたのは運がよかったのかもしれない。
正直なところ、realtek targetの機種については、これまでルータが主なターゲットであったOpenWrtがスイッチングハブで動くという目新しさ、面白さが自分のモチベーションにかなり直結している。
機能面としては、AML2-17GPではメーカーファームウェアではSSHをサポートしないのでOpenWrtを導入することで利用可能になるほか、ほぼ汎用的なLinuxが利用できることからSoCの極端な負荷にならない範囲で様々なことができるようになる。その他の機種によっては、ネットワーク関連の機能で差別化などの意図からサポートされないものも利用できるようになるなどのメリットもあると思われる。

ELECOM WRC-1750GST2

いつも通り某フリマアプリを眺めていたところ、ジャンク扱いで¥1,000を切る出品があり衝動的に購入してしまったもの。
既にサポート済みのWRC-1750GS/GSVと一部を除き大方共通のハードウェアであるため、特に難なくサポートが完了し早いうちにマージされました。
まとめていきます。

仕様

前述の通り既にサポート済みのWRC-1750GS/GSVとほぼ同一のハードウェアであり、FlashとRAMの容量が異なるくらいの差。
法律の関係上、無線機能の使用は非推奨です

  • SoC: MT7621A (880MHz, 2C4T)
  • RAM: DDR3 256MiB
  • Flash: SPI-NOR 32MiB
  • WAN/LAN: 1000Mbps/1000Mbps x4
  • UART: J4, 57600bps(RJ45側から3.3V, GND, TX, RX)

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

OpenWrt化

この機種も既存のWRC-*GS/GSV/GST(2)と同一のファームウェアフォーマットであるため、factoryイメージの生成を行えています。

WRC-1750GST2を起動
通常通り電源を接続して起動。ルータモードを前提とする
WebUIからファームウェア更新ページを開く
PCとWRC-1750GST2を繋いで http://192.168.2.1 にアクセスし、ファームウェア更新ページを開く
ファームウェア更新
WRC-1750GST2のOpenWrtのfactoryイメージを選択し、アップデートを実行
完了
Flashへの書き込みが完了後再起動され、OpenWrtで起動する

備考

この機種も変な癖は特にないのであまり書くことが無い。

  • メーカーファームに戻す際は、公式サイトで公開されているアップデート用ファームウェアの先頭32byte(= 0x20、ヘッダ部分)を削って firmware パーティションに mtd コマンドで書き込む
  • マージ時点でOpenWrt 21.02用branchは既に切られた後だった関係で、21.02リリースにはWRC-1750GST2のサポートは入らない
    と思っていたものの、いつの間にか21.02用branchにcherry-pickされておりリリースに含まれる模様

作業時の色々

  • 毎回恒例となっているが、factory生成コードを今回も使いまわせているのでとても楽。
  • また、ハードウェア構成を記述するdts/dtsiファイルもWRC-*GS/GSV/GST(2)系列でおよそ大半のバリエーションをカバーできる状態になっており、今回WRC-1750GST2で追加したのはmtdパーティションのうち共通化できない一部のパーティションのみ。
  • 色々

    今回は本当にごくわずかな変更のみであったことから、購入後NCP-HG100の作業の合間に気分転換も兼ねてハードウェア確認とサポート組み上げ、投げ込みテストやその他チェックなど行ったがかなり短時間で済み、そのままPRを投げ込んだ。そしてPRも特にツッコミを受けることなくすんなりとマージされ、一気に完了。
    既にディスコンとなっているものの中古ではそこそこの数が出ており、時々ある程度価格が落ちてくることから扱いやすいWRC-*GS/GSV/GST2系列の中でもFlashとRAMの多い機種の選択肢として良いかもしれない。
    WRC-1900GST2は今のところ確保しておらず予定も無し。

    BUFFALO WSR-2533DHP2

    個人的に初となるMT7622 (ARM)搭載機。もう既に記憶が曖昧であるものの、masterが確かKernel 4.14であった頃某氏より提供頂いてずっと作業を続けていました。
    途中から同じく某氏より実機の提供を受けたOpenWrtのチームメンバーであるHauke氏が加わり、何度かやり取りしながら今回ようやくサポート入りとなりました。まとめていきます。

    仕様

    SoCにはaarch64であるMT7622(mips(el)のMT7621ではない)を搭載し、無線は2.4GHz帯をSoCの無線機能を、5GHz帯はMT7615を搭載してカバーしています。また、SoCとSwitchの間は2.5Gbpsで接続されており、帯域に比較的余裕があります。
    法律の関係上、無線機能の使用は非推奨です

    • SoC: MT7622B
    • RAM: DDR3 256MiB
    • Flash: NAND 128MiB
    • WAN/LAN: 1000Mbps/1000Mbps x4 (RTL8367S)
    • UART: J4, 115200bps(RJ45側から3.3V, GND, TX, RX)

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

    OpenWrt化

    今回Hauke氏がfactoryイメージを仕立てて下さったので、簡単に投入できます。

    WSR-2533DHP2を起動
    電源ケーブルを繋ぎ、通常通りWSR-2533DHP2を起動
    WebUIにアクセス
    WSR-2533DHP2の設定用WebUIを開き、ファームウェア更新ページへ移動
    ファーム更新
    WSR-2533DHP2のfactoryイメージ(”squashfs-factory.bin”)を選択し、アップデートを実行
    この際、”factory-uboot.bin” はU-Boot用でありWebUI用ではないので選択しないこと
    完了
    Flashへの書き込みが完了後再起動され、OpenWrtで起動してくる

    備考

    WSR-2533DHP3は非サポート
    WSR-2533DHP3はスイッチその他でDHP2とはいくつかの差異があることが予想され、その関係上DHP2用のファームウェアは使用不可
    21.02リリースには入らない
    マージ時点では既にOpenWrt 21.02リリース用branchが切られた後であったため、当該リリースには間に合わずWSR-2533DHP2のサポートは入らない
    “factory-uboot.bin” イメージはU-Bootとその他用
    WebUI用の “factory.bin” ともう一つ “factory-uboot.bin” が生成されるようになっており、後者はU-Bootからの書き込みのほか、何らかの理由によりKernelとRootFSを一括で書き込む必要がある場合に使用するもの
    例:

    • 将来的にKernelサイズが現在の4MiBから更に大きいサイズに変更された場合
    • Flash内にメーカーファームウェアが存在している状態でinitramfsイメージでブートした場合

    ただし、sysupgrade時に使用する場合は仕様上設定を引き継ぐことができない

    Flash内のOSイメージは2組存在
    Flash内部にはOSイメージ領域が2組存在しており、その関係上OpenWrtでKernel + RootFS + ユーザー領域で使用できる合計サイズは58MiB(= 0x3A00000)ほど

    作業時の色々

    • とにかくイーサネットスイッチ部分が長らく問題になっていた。
      WSR-2533DHP2はRTL8367Sを搭載するが、つい最近までOpenWrtではこのスイッチのサポートが存在せず。別のRTL8367S搭載機種のPRでハードウェア的に近いRTL8367(R)B用ドライバである既存のrtl8367bドライバを改変して部分的にRTL3867Sサポートを追加しようとするものもあったが、どうにも進展が無いまま時間だけが過ぎていた。
      結局最近になってELECOMの市販されていない機種のサポートが入った際、同時にMediaTekから出たらしいRTL8367Sドライバがmediatek targetに追加され、ひとまずそれを使用できるようになったのでWSR-2533DHP2のサポートでもそれを利用した。
      ただ、決め打ちの箇所がだいぶ多く、その上OpenWrtでは使用されないコードが大量にあるあまりに巨大なドライバであるので、正直印象としてはだいぶ微妙。
    • 上記のスイッチ部分に次いで問題になっていたのがOpenWrtでFlashに書き込むファームウェアのフォーマットだった。
      NAND搭載機であることからRootFSにはUBIを使用したいところであったものの、単純に組み合わせようとするとエラーも吐かずブートが止まる問題を起こした。これについてはHauke氏がbcm53xxで使用されている方法を活用して解決してくださり、問題無くブートできるようになった。
      また、WSR-2533DHP2では “trx” というフォーマットのMagicNumberに非標準のものを用いる必要があり、OpenWrtでブート時にこのフォーマットからKernelとRootFSを分離するドライバでは標準のMagicNumber以外を認識できないため、代わりにLinux Kernel内の parser_trx に非標準MagicNumberのサポートを追加したうえで利用することとなった。
      この非標準MagicNumberのサポートはWCR-1166DSのfactoryイメージがブートできない問題の解決に必要となるので、今後の状況を見つつ可能になったらその問題を修正する。
    • 上記で少し触れたとおり、WSR-2533DHP2のサポートは部分的に将来的なKernelサイズの増加に備えたものにした。今現在のところ4MiBで問題はないものの、今後Kernelバージョンが上がっていくにつれて増加していくため、もし必要に迫られたときに大量の変更が必要になるのを避けたかったのと、それの対処についてある程度方向性を示したかった。

    色々

    今回、WSR-2533DHP2のサポート本体は自分の割合が多いものの、動作に必要となる周辺パッケージの改変やアイデア、コードの修正や改善、その他様々な点でHauke氏にご協力頂きました。また、最後こちらはNCP-HG100に掛かりっきりになってしまっていたのもあり、Hauke氏によってMLへのpatch投げ込みとコメントを受けての修正、マージまでやって頂き、本当に感謝です。
    1年以上を要したものの、ようやくマージとなり肩の荷が下りた。aarch64としてはMT7622搭載機はハイエンドよりはミドルレンジ寄りであるほか、中古価格も最近だいぶ落ちてきており入手性としては良さそう。
    現在同じくMT7622を搭載するWSR-3200AX4Sのサポート作業も進行中です。WSR-2533DHP3は今のところ作業予定は全くありません。

    NCP-HG100進捗報告

    書こうかと言いつつ作業に没頭して忘れかけていましたが、書いておきます。
    なお、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モジュール認識(暇な人氏により確認済)
    • 現状限定的に動作するもの
      • RGB LED(筐体外周)
        OpenWrt内やKernel内の複数のドライバをベースにしてMCU本体とLEDのドライバを作成。現状ではごく基本的なLEDサポートのみで、本来MCUが持っている様々な点滅パターンの制御は行えない
        また、MCUのI2Cに対する反応速度の問題からRGB同時点灯の白色を単一のLEDとして使用することはできない
    • 現状動作しないもの
      • マイクミュート, 音量Up, 音量Down, Alexa呼び出しボタン
        タッチパネルを制御するCY8C PSoCのドライバが現状無く、システム起動中のモードから抜けて通常動作モードに移行させることができない為
      • ファンコントロール, 温度読み取り
        MCUドライバが現状LEDサポート部分のみである為
      • Bluetooth
        UARTに接続されていると思われるが、ドライバの有無やアクティブ化の方法が不明
      • オーディオ関連全般
        IPQ40xxが搭載するオーディオ関連機能は現状Linux KernelとOpenWrtどちらにもドライバが無く、KernelのMLには2016年にpatchが投げられているものの指摘を受けた後作者から反応が無く完全に停滞。現状マージされる見込みがない
        また、Conexant CX20924も同様にドライバが無い。KernelのMLにConexantからpatchが投げられているが、2017年を最後にやり取りが途絶えている

    作業での色々

    ノリと勢いで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チームからの反応待ち。