Wi-Fiモジュール交換：LinuxドライバーとDevice Treeの検証

ByLIU, ZHUOHUI

Linux製品のWi-Fiモジュール交換は、ハードウェア、ドライバー、ファームウェア、動作方針の変更です。同じフットプリントに収まっても、電源順序、ファームウェア、バス設定、ユーザー空間機能が変わる場合があります。スキャン成功は最初の確認点にすぎません。

本稿はSDIO、USB、PCIeのWi-Fi機器を使う組み込みLinux製品の技術検証を扱います。全モジュールが同じ無線スタックやDevice Tree方式を使うとは仮定しません。提案試験は受け入れ計画であり、実測速度、法規認証、無変更交換の保証ではありません。

1. ソフトウェア変更前に置換比較表を作る

旧品と候補品を完全な発注型番・ハードウェア版で比較します。ホスト接続、電源、I/O電圧、リセット・有効化、基準クロック、割り込み・ウェイク、アンテナ、共存信号を記録し、各端子を確認します。外形とコネクターの一致は電気互換性の証明ではありません。

Station、AP、同時インターフェース、休眠復帰、ローミング、必要ならBluetooth共存を列挙します。Station接続できても、必要なAPや同時構成を支えるとは限りません。ドライバー可用性を見る前にカーネルとBSPブランチを特定します。

供給元の組み込み資料とファームウェア再配布条件を入手します。基板専用校正・不揮発設定ファイルと実装基板の対応を記録します。チップ名が同じという理由だけで他製品の校正値を流用しません。

Wi-Fi置換の検証層：電気接続、バス認識、ドライバー・ファームウェア、無線役割、アプリケーション、復旧。
検証段階の例。交換成功を判断する前に、各層の独立した証拠が必要です。

2. ドライバーとファームウェアの基準を確立する

ドライバーが対象カーネル内、BSP提供、ツリー外管理のどれかを特定します。正確なcommit、設定、デバイスID、依存を記録します。別カーネル向け外部モジュールはAPI、設定、モジュール版の差で動かないことがあり、バイナリーコピーは移植方法にはなりません。

ホストドライバーと無線チップ内で動くファームウェアを分けます。LinuxのローダーAPIは名前でファームウェアを要求できますが、正しいファイルと基板設定は機器・ドライバー固有です。ファームウェア要求文書を参照します。無関係なバイナリーを警告が消えるまで改名せず、要求名と最初のprobeエラーを記録します。

カーネル、モジュール、DTB、無線ファームウェア、基板データ、ユーザー空間ネット設定を一覧化し、ルート内の実ファイルと照合します。開発環境で動いていても、クリーンな製品イメージで必要ファイルが不足する場合があります。

3. 関係するハードウェア記述だけを変える

SDIOでは、ホストコントローラー、幅、電源参照、端子、電源順序、着脱媒体扱い、帯域外割り込み・ウェイク配線を確認します。実際のカーネル内バインディングを使います。あるメーカーの属性が別ドライバーにも通じるとは限りません。

USB・PCIeは通常バスで列挙しますが、基板電源、リセット、ホスト資源の記述は必要な場合があります。USBドライバーを強制ロードするためだけに任意のWi-Fiノードを追加しません。まずバスで見えるか、IDが対象ドライバーに一致するかを調べます。

対象ツリーのツールで変更後のDevice Treeをコンパイル・検証します。Linuxバインディングガイドにはdtbs_checkなどが記載されています。通過は既存バインディングとの構造的一致であり、リセット極性、電圧、基板配線までは確認できません。

全変更ノードと回路図ネットまたは供給元要件を結ぶレビュー済みdiffを残します。改板が必要なら、その依存を明示し、ソフトウェアだけの交換と表現しません。

4. バス、probe、無線、ネットワークの順に調べる

最初はバス認識です。機器が見えなければ、認証より先に電源、リセット、クロック、ホスト設定を調べます。見えるがバインドしないならID、設定、モジュールを確認します。バインド後のファームウェア失敗なら、要求名、パッケージ、基板データ選択を調べます。

インターフェースができたら能力と現在リンクを確認します。標準nl80211対応なら以下の読み取りコマンドが役立ちます。名前は実機に合わせます。メーカー独自ドライバーには専用の対応ツールが必要な場合があります。

uname -r
ip link show
iw dev
iw phy
# Example interface name only:
iw dev wlan0 link
iw reg get

Linux Wirelessのiw文書は能力とリンク確認を説明します。表示された機能は、実装アンテナやアプリケーションの性能要件達成の証拠ではありません。

その後、無線関連付け、アドレス、ルーティング、DNS、アプリケーションを分けて確認します。リンク成功でもDHCPは失敗し得ます。ローカルping成功は必要なTLS接続先の到達や、証明書に必要な時刻の妥当性を保証しません。

5. 製品が使う正確な役割を検証する

実配備のAP機種とセキュリティ方式を使います。合法かつ対応範囲で必要な周波数帯・帯域幅を試します。APではクライアント接続、再接続、同時インターフェースを確認します。ローミングではAPアドレス変更だけでなく、アプリ中断とパケット動作を記録します。

距離、アンテナ向き、電波環境、転送方向、対向機設定を定め、速度、遅延、損失、CPU負荷、消費電力を同時測定します。ツールと版を記録します。遅いサーバーを無線限界と誤認しないよう、再現可能な有線基準経路を分けます。

Bluetoothとモジュールやアンテナを共有するなら、必要な同時使用を含めます。Wi-Fi単独試験は共存の証明になりません。条件と実測証拠なしに速度や到達距離を公表しません。

6. 復旧と異常系を含める

  • AP消失：再試行の上限、アプリのタイムアウト、AP復帰後の回復を確認します。
  • 不正認証情報：無限の高速再接続やログへの秘密露出を避け、対処可能な状態を表示します。
  • アドレスサービス不在：無線接続とDHCP不在を区別し、文書化された代替動作を試します。
  • ファームウェア欠落：破棄可能なイメージで、不足依存を起動診断が明示するか確認します。
  • 休眠・復帰：必要なウェイク要因をすべて試し、インターフェースとアプリの双方が戻るか確認します。
  • コールド・ウォーム起動：両方を試します。給電が残るモジュールは、不完全な冷起動順序を隠す場合があります。

許可された試験ネットワークで実施し、有線または物理的復旧経路を保ちます。唯一の遠隔管理回線で、復旧計画なしにドライバーを外したりファームウェアを交換したりしません。

7. 法規設定を独立した要件として扱う

配備国、許可チャネル、アンテナ、供給元制約は完成品に影響します。Linuxの法規設定は動作制限に役立ちますが製品認証ではありません。試験通過のために非対応チャネルや出力を強制しないでください。Linux Wirelessの法規文書は情報処理を説明します。製品固有の義務はモジュール供給元と適切な適合専門家が確認します。

交換判断に必要な証拠

比較表、回路図・Device Tree差分、ドライバー・ファームウェア一覧、起動ログ、役割別試験、異常時結果、既知制限を納品します。新旧比較は同じ治具と負荷で行い、避けられない差を明示します。

ObeitaのRK3528 Linuxネットワークゲートウェイ構成はAP6275Sの方向性と、Station/AP・Bluetoothの別ソフトウェア経路を挙げています。範囲例であって代替モジュールの互換証明ではありません。ファームウェア・BSP診断には新旧の完全型番、回路図、カーネル/BSP版、必要な無線役割を提供してください。

類似投稿