Page-1

# リモート・プロセッサー（remoteproc）サブシステムを構成する remoteprocフレームワークは、ファームウェアをQualcomm上の他のサブシステム（オーティオ・デジタル・シグナル・プロセッサー（aDSP）やコンピュート・デジタル・シグナル・プロセッサー（cDSP）など）に読み込むために使用します。 Remoteprocフレームワークは2つの部分に分かれます。 - コア・フレームワーク：コア・フレームワークには一般的なロジックがあります。ファームウェアを読み込み、リモート・プロセッサーを起動または停止します。 - Remoteprocドライバー：ドライバーには、対応するコアを管理するためのプラットフォーム特有のオペレーションがあります。remoteprocドライバーは、remoteprocインスタンスと一連のオペレーションをコア・フレームワークに登録します。非対称マルチプロセッシング（ASMP）構成のSoCには複数の異種リモート・プロセッサーがあります。リモート・プロセッサーはファームウェアまたはOSの複数のインスタンスを実行します。 Qualcomm Linuxが他のコアを管理するために使用する標準フレームワークについては、[Remote Processor Framework](https://www.kernel.org/doc/html/next/staging/remoteproc.html) を参照してください。 ## Qualcommのremoteprocサポート Qualcommは、アップストリームのPASドライバーを使用する周辺ファームウェア認証のremoteprocフレームワークを強化しました。 Qualcomm LinuxのRemoteprocドライバーは、peripheral authentication service（PAS）ドライバーを実装します。これは、Qualcomm SoCデバイスのリモート・プロセッサー用のTrustZoneベースの周辺イメージローダーです。詳細については、[qcom_q6v5_pas.c](https://github.com/torvalds/linux/blob/master/drivers/remoteproc/qcom_q6v5_pas.c) を参照してください。リモート・プロセッサーは各種のコプロセッサー（aDSP、cDSP、モデム周辺サブシステム（MPSS）、ワイヤレス・プロセッサー・サブシステム（WPSS）など）の管理に使用されます。QCS6490ベースのボードとDragonwing™ RB3 Gen 2開発キットでサポートされているコプロセッサーはaDSP、cDSP、WPSSです。注釈サポートされているリモート・プロセッサー・サブシステムは、使用しているSoCによって異なります。 **ユーザーインターフェース：** Remoteprocフレームワークは、登録されたremoteprocデバイスを追跡し、デバイスの起動とシャットダウンのためのユーザーインターフェースを提供します。ユーザー領域は、以下の `sysfs` インターフェースを使用して、remoteprocの現在の状態のクエリと変更を行います。 remoteproc user space interface # start remoteproc: echo "start" > /sys/class/remoteproc/remoteprocN/state # stop remoteproc: echo "stop" > /sys/class/remoteproc/remoteprocN/state Copy to clipboard **図：Remoteprocのサポート** ## Remoteprocリカバリとサブシステムの再起動を構成する Remoteprocサブデバイスは、リモート・プロセッサーのサブシステムのクラッシュとリカバリのシナリオのための通信コンテキストを管理します。通信コンテキストなどのエンティティにより、リモート・プロセッサーが起動またはシャットダウンする時点を決定する必要があります。各サブデバイスには2つのオペレーションがあります。 - `probe()` ：remoteprocの `start()` の後に呼び出す - `remove()` ：`stop()` の前に呼び出すリモート・プロセッサーで致命的なエラーが発生すると、remoteprocドライバーはこれを処理して `rproc_report_crash()` を呼び出します。これにより、エラーが発生したリモート・プロセッサーのリカバリが実行されます。リカバリ・ハンドラーは以下を実行します。 **図：remoteprocクラッシュ・シーケンス** ユーザー領域からリカバリ `debugfs` ノードを使用してリカバリを有効または無効にするには、以下を実行します。 mount -t debugfs nodev /sys/kernel/debug echo disabled > /sys/kernel/debug/remoteproc/remoteprocN/recovery Copy to clipboard ## コアダンプを有効または無効にするリモートプロセッサーのコアダンプは、Qualcomm Linuxカーネルのdevcoredump機能を使用してサブシステムのクラッシュの問題をデバッグするために使用します。サブシステムでクラッシュが発生すると、devcoredumpは `/sys/class/devcoredump/devcdN/data` ノードのリカバリ用remoteprocのメモリのスナップショットを開示し、関連付けられたクラッシュの `uevent` がユーザー領域に送信されます。sysfsノードが読み取られると、sysfsはELFコンテナのセグメントを提供し、書き込み処理によりリソースが解放され、devcoredumpインスタンスが破棄されます。 debugfsノードが開示され、ユーザー領域からのコアダンプが有効または無効になります。 # Disable core dumps: echo disabled > /sys/kernel/debug/remoteproc/remoteprocN/coredump # Enable core dumps: echo enabled > /sys/kernel/debug/remoteproc/remoteprocN/coredump # # N represents the index number of the remote processor. Copy to clipboard 注釈完全なRAMダンプをクラッシュ分析用に収拾するため、Qualcomm SoCsはカーネルパニックをremoteprocクラッシュ（リモートプロセッサーの致命的なエラー）で実施します。カーネルパニックモードは、コアダンプが無効な場合のみ有効になります。 devcoredump `/sys/class/devcoredump/devcdN/data` ノードは、サブシステムでコアダンプが有効になっている場合のみサブシステムのクラッシュに作成されます。コアダンプを有効にするには、`echo enabled > /sys/kernel/debug/remoteproc/remoteprocN/coredump` コマンドを実行します。`devcdN/data` ノードは一時的なもので、タイムアウト後に削除されます。この問題をデバッグするには、`copy` コマンドを使用して `devcdN/data` ノードをローカルデバイスにコピーして、安全に使用できるようにします。削除タイムアウトは `base/devcoredump.c` で定義されます。以下は、コアダンプをコピーするためのコマンドの例です。 # Copy Core dump to a local device cp /sys/class/devcoredump/devcdN/data > /var/spool/crash/dump_file.elf # # N represents the index of core dump. It is incremented each time a new core dump is generated. Copy to clipboard コアダンプファイルをホストデバイスに転送して問題をデバッグするには、Qualcomm Crash Analysis Portal（QCAP）を使用します。注釈 QCAPの詳細については、[QCAPを使用してRAMダンプを解析する](https://docs.qualcomm.com/bundle/resource/topics/80-70020-12A/debugging_linux_kernel.html#parse_ram_dumps_using_qcap) を参照してください。 ## remoteprocノードとファームウェアの読み込みをDTで構成する remoteprocデバイスはDTバインディングを使用して、各デバイスツリー・ファイルで構成されます。この構成には、互換性があるデバイスの名前、メモリ領域、割り込み設定、クロック・リファレンスなどが、`Documentation/devicetree/bindings/remoteproc/` ディレクトリにあるDTバインディングに従って含まれます。以下の例は、`arch/arm64/boot/dts/qcom/qcs6490.dtsi` ファイルにあるQCS6490 aDSP remoteprocデバイスツリー構成を示しています。 remoteproc_adsp: remoteproc@3000000 { compatible = "qcom,sc7280-adsp-pas"; reg = <0x0 0x03000000 0x0 0x100>; interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack", "shutdown-ack"; clocks = <&rpmhcc RPMH_CXO_CLK>; clock-names = "xo"; }; Copy to clipboard パス `arch/arm64/boot/dts/qcom/sa8775p.dtsi` のIQ-9075デバイスツリー構成ファイルを確認します。注釈すべてのQualcomm SoCのデバイスツリー構成ファイルを取得するには、各プラットフォームのDTSIファイルを参照してください。すべてのファームウェア・ファイルは、`rootfs` の `/lib/firmware` ディレクトリにあり、関連する構成は対応するボードデバイスツリーの `arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts` ファイルで行われます。他のQualcommハードウェアSoCについては、`arch/arm64/boot/dts/qcom/-.dts` ファイルを参照してください。以下の例は remoteproc DT構成を示しています。 &remoteproc_adsp { firmware-name = "qcom/qcs6490/adsp.mdt"; status = "okay"; }; Copy to clipboard ### Remoteproc参照ログ以下のログは、remoteprocが正常に起動すると表示されます。 ** \# remoteproc success** "remoteproc remoteproc1: remote processor 4080000.remoteproc is now up" Copy to clipboard 以下のログは、remoteprocファームウェアの読み込みが失敗すると表示されます。 ** \# remoteproc failure** Error log: "remoteproc remoteproc0: Direct firmware load for qcom/qcs6490/modem.mdt failed with error -2" # Caused by: error loading firmware. # Solution: ensure that the modem firmware is copied to /lib/firmware/qcom/qcs6490 in rootfs. Copy to clipboard Last Published: Jan 01, 2026 [Previous Topic カーネルを開発する](https://docs.qualcomm.com/bundle/publicresource/80-70020-3JA/topics/kernel-development.md) [Next Topic メモリを構成および管理する](https://docs.qualcomm.com/bundle/publicresource/80-70020-3JA/topics/memory.md)