RK3576 Linuxカメラの起動：センサードライバーから最初のフレーム表示まで

RK3576は、ロッキーチップ社が産業用ビジョン、スマートセキュリティ、AIビジョン端末向けに開発したプロセッサです。最大1600万画素に対応するISP V3.9（画像信号処理装置）および3つのMIPI CSI-2レシーバーモジュール（D-PHY V2.0モジュール2基とC/D-PHYモジュール1基）を内蔵しています。各D-PHYレーンは最大4.5Gbps、各C-PHYトリオは2.5Gsps、各CSIポートは4つの仮想チャネルをサポートします。

RK3576のカメラソリューションは、Linux MediaフレームワークおよびV4L2-subdevサブデバイスモデルに基づいて設計されています。完全なデータパスは以下の通りです：画像センサー → MIPI CSIレシーバーコントローラー → VICAPビデオキャプチャユニット → ISP V3.9。センサーは独立したサブデバイスとして動作し、MIPI CSI、VICAP、ISPと連携して、完全な画像取得パイプラインを構成します。

RK3576はMIPI CSI受信チャネルを3つ備えており、VICAPは複数の画像ストリームを同時に受信できますが、ISP V3.9はシングルチャネルのハードウェアであり、1つの画像ストリームに対してのみISPアルゴリズム処理を実行できます。

プロジェクトのデバッグ中に、I2C通信の異常、MIPIリンクの不安定、またはメディアパイプラインの確立失敗などの問題が発生し、結果として最初の画像フレームが出力されないことがあります。本稿では、エンジニアリング実装の観点から一貫したデバッグ手法を示し、組み込みビジョンシステムのデバッグにおける参考資料として活用できます。

1．ハードウェアおよびカーネルの準備：デバッグ着手前に低レベルのハードウェア問題を排除

ドライバーのデバッグにおいて、私たちが遭遇するほとんどの問題は、ドライバー自体のコードではなく、ハードウェアの配線、電源立ち上げ順序（パワーシーケンス）、カーネル設定の不足といった低レベルの要因に起因します。したがって、センサー用ドライバーの開発を開始する前に、まず基盤となるハードウェアおよびカーネル環境を確認・検証しておく必要があります。

主なハードウェア確認項目には、センサーの電源レール、I2Cバス、MIPI差動リンク、およびリセット／電源制御用GPIOピンが含まれます。

センサーの電源立ち上げ順序（パワーシーケンス）は、デバッグにおいて最も重要な要素の一つです。AVDD、DOVDD、DVDDなどの複数の電源レールは、センサー仕様書で定められた立ち上げ順序を厳密に守る必要があります。電源電圧の過剰なばらつきや、立ち上げ／立ち下げタイミングの誤りは、I2C通信の失敗やセンサーの異常動作を直接引き起こす可能性があります。

I2Cバス：ピンのマルチプレクシング設定およびセンサーのスレーブアドレスを確認し、I2Cプルアップ抵抗が正しく実装されていることを確認してください。

MIPI：ハードウェアで使用されるCSIチャネル、MIPIレーン数、および差動信号ラインにおけるインピーダンスマッチングを確認してください。また、RK3576から出力されるセンサ基準クロック（XVCLK）が正常に動作しているかを確認します。

リセット／パワーダウン制御ピン：アクティブレベルの論理（ハイアクティブ／ローアクティブ）を特定し、GPIO設定が回路図と一致していることを確認してください。

カーネル設定：メディアサブシステム、V4L2-subdevサブデバイス、MIPI CSIコントローラおよびPHYドライバ、VICAP、ISP V3.9に関するカーネルオプションを確認してください。必要なコンポーネントがカーネルに組み込まれていない、あるいはモジュールとしてビルドされているが正しくロードされない場合、メディアパイプラインはカメラハードウェアを認識できなくなります。カーネルのビルドおよび書き込み後に、まず各ドライバモジュールのロード状態を確認してください。dmesgログを確認し、モジュールの欠落や初期化失敗などのエラーがないことを検証します。

2．デバイスツリー（DTS）設定：デバイス間の接続確立

RK3576 カメラデバイスツリー：ハードウェアリソースを記述し、ポートおよびエンドポイントノードを用いて、センサー、MIPI CSI、VICAP、ISP 間の画像パイプライン接続を定義します。

センサーノードは対応する I2C バスノード配下に配置され、I2C スレーブアドレス、リセットピン、パワーダウン制御ピン、およびセンサー基準クロックを定義します。プロパティを設定することで、CSI PHY ハードウェアが準備完了するまでセンサーの初期化を遅らせることができ、PHY が未準備な状態によるタイミング競合を回避できます。センサーノード内のポートに含まれるエンドポイントは MIPI CSI 入力を指し、MIPI データレーン数を指定します。

MIPI CSI コントローラーのノードには2つのポートがあり、入力側はイメージセンサーに接続され、出力側はVICAPユニットに接続されます。その後、VICAPが画像データをISP V3.9に出力します。エンドポイント同士は双方向に相互参照する必要があり、両端のremote-endpointプロパティは1対1で対応しなければなりません。双方向のバインディングが一致しない場合、Mediaフレームワークは完全なデータパスを認識できません。DTSを修正・コンパイル・フラッシュした後は、まずdmesgログを確認し、すべてのデバイスノードが正常な状態であること、および持続的なdeferred-probeエラーが発生していないことを検証してください。繰り返されるdeferred probingは、通常、GPIO、クロック、または電源リソースの設定が誤っていることを示しています。

3. センサーサブデバイスドライバーの開発：V4L2-subdevモデル

RK3576プラットフォームのセンサードライバーは、V4L2-subdevフレームワークに基づいて開発されています。このセンサードライバーは/dev/videoノードを作成せず、メディアサブデバイスエンティティとしてのみ存在します。主な責務には、センサーのレジスタ設定、電源およびリセット管理、画像フォーマットの設定、およびストリームの開始／停止制御が含まれます。

このドライバーは主に5つのモジュールに分けられます：I2Cプローブ、電源／リセット制御、モードレジスタテーブル、パッドフォーマット設定、およびストリームの開始／停止制御。

ドライバーのプローブ段階において、I2Cを介してセンサーのチップIDが読み出され、チップが正しく認識されているかが確認されます。IDの読み出しに失敗した場合、トラブルシューティングはI2C、電源、リセットに関連するハードウェア障害に直接絞り込むことができます。電源／リセット機能は、センサーの起動（パワーアップ）および停止（パワーダウン）の全手順を実装しています。起動時には、各電源レールが順次有効化された後、指定された遅延時間だけリセットピンがアクティブ状態（ロー）になり、その後リセットが解除され、センサーが内部的に安定する時間を確保します。停止時には、これらの操作が逆順で実行されます。

モードレジスタテーブルには、異なる解像度、フレームレート、MIPI転送レートごとのセンサレジスタの完全な設定が格納されます。上位レイヤーがキャプチャパラメータを切り替えると、ドライバは対応する完全なレジスタセットを書き込みます。「パッドフォーマット」インタフェースでは、メディアバス上の画像フォーマットを設定します。このフォーマットは、センサが出力するベイヤー形式（例：BGGR、RGGB）と厳密に一致しなければなりません。誤った設定は、画像の色再現エラーを直接引き起こします。「ストリーム制御」インタフェースでは、`stream_on` を用いてセンサのMIPI画像出力を有効化するレジスタコマンドを書き込み、`stream_off` で画像伝送を停止します。ドライバの実装完了後、カーネルのKconfigおよびMakefileにビルドオプションを追加し、ドライバをカーネルに組み込むか、ロード可能なカーネルモジュールとしてコンパイルできるようにします。

4．段階的デバッグ：最初のフレームをステップ・バイ・ステップで取得

画像キャプチャを直ちに試みるのは推奨されません。3段階の階層型トラブルシューティング手法を用いてください：ドライバーのプローブが成功することを確認 → メディアパイプラインが完全に接続されていることを確認 → V4L2で生画像（raw image）をキャプチャします。

ステージ1：センサードライバーの正常なプローブを確認

システム起動後にdmesgの出力を確認し、センサードライバーから出力されたログメッセージを検索してください。また、i2cdetectコマンドを用いて対応するI2Cバスをスキャンし、センサーのスレーブアドレスが検出されるかを確認します。

• I2Cデバイスが検出されない場合：センサーへの電源供給、リセット信号のロジック、I2Cハードウェアの実装（はんだ付け）、およびピンのマルチプレクシングを確認してください。
• I2Cアドレスは検出されるものの、チップIDの読み取り結果が異常な場合は、I2Cハードウェア経路は正常に動作しており、原因はレジスタアドレスの誤りまたはセンサーモデルの不一致である可能性が高いです。

ステージ2：メディアフレームワークのパイプラインを確認

Media-ctl を使用してメディアデバイスのエンティティ一覧を表示します。通常の状態では、センサー、mipi_csi、vicap、isp39 などのサブデバイスエンティティが表示され、それぞれのパッドポートも正しく認識されるはずです。

• センサーデバイスエンティティが表示されない場合：センサードライバーのプローブに失敗しています。
• エンティティは存在するがリンクが切断されている場合：DTS 内のエンドポイント双方向ペアリングが正しくありません。

デバッグ中には、media-ctl を用いてパイプライン全体を手動で設定できます。具体的には、各エンティティ間のリンクを確立し、各サブデバイスステージにおける画像フォーマット、解像度、レーン構成を設定します。media-ctl からのエラーは、通常、レーン数、メディアバスフォーマット、または解像度のいずれかのパラメーターがセンサーのハードウェア仕様を超えていたために発生します。media-ctl の設定が正常に完了した場合は、センサーから ISP までのソフトウェアパスが確立されたことを意味します。

ステージ 3：V4L2 を用いて画像をキャプチャし、最初の RAW フレームを取得

VICAP/ISP が /dev/video ノードを生成し、これがユーザースペースからの画像キャプチャのエントリポイントとなります。v4l2-ctl を使用して画像のピクセルフォーマットを設定し、mmap 経由で単一フレームをキャプチャしてベイヤー RAW データを保存します。生成された RAW ファイルのサイズが理論値と一致した場合、最初の画像フレームのキャプチャは正常に完了しています。その後、専門の画像解析ツールでこの RAW ファイルを開き、元のベイヤー画像を確認できます。

5. よくあるトラブルシューティング手法

• media-ctl によるリンク設定時にエラーが報告される場合：まず双方向 DTS エンドポイントのバインディングを確認し、次にメディアバスフォーマット、解像度、レーン数の各パラメーターを検証してください。
• V4L2 によるフレームキャプチャがタイムアウトし、画像データが出力されない場合：ドライバー内で stream_on が正しく実行されていること、CSI PHY がクロックロックを確立済みであること、およびセンサーが実際に MIPI データストリームを出力していることを確認してください。
• 画像の破損やストライプ状のノイズ：考えられる原因には、MIPIクロック周波数の不適切な設定、レーン数の誤り、ベイヤー配列の不一致、またはイメージセンサへの電源供給に過度なリップルが発生していることが挙げられます。
• 画像出力が断続的になる、あるいはフレームが sporadically（不定期に）欠落する：イメージセンサの電源投入／リセットタイミングが仕様要件を満たしていない可能性があります。また、ハードウェア側の電源が十分に安定していないことも原因として考えられます。

当社はRK3576向けに成熟したソリューションと、カスタム開発・ハードウェア対応・量産実装における専門的な技術力を有しています。さまざまなイメージセンサや解像度・フレームレートの要件に応じて、ハードウェアのリビジョン対応、ドライバのデバッグ、システム全体の最適化を提供し、産業用ビジョン、スマートセキュリティ、AIビジョン端末など、多様な用途におけるカスタマイズプロジェクトを効率的に支援します。お問い合わせは [email protected].