Page-1

# remoteprocessor(remoteproc) 서브시스템 구성 remoteproc 프레임워크는 Qualcomm 플랫폼의 오디오 디지털 신호 프로세서(aDSP) 및 컴퓨팅 디지털 신호 프로세서(cDSP) 같은 다른 서브시스템에 펌웨어를 로드하는 데 사용됩니다. remoteproc 프레임워크는 두 부분으로 나뉩니다. - 코어 프레임워크: 코어 프레임워크에는 공통 로직이 포함됩니다. 이 로직은 펌웨어를 로드하고, 원격 프로세서를 시작하거나 중지합니다. - Remoteproc 드라이버: 이 드라이버에는 해당하는 코어를 관리하기 위한 플랫폼별 작업이 포함됩니다. remoteproc 드라이버는 remoteproc 인스턴스와 일련의 작업을 코어 프레임워크에 등록합니다. 여러 이종 원격 프로세서가 SoC에 비대칭적 다중 처리(ASMP) 구성으로 존재합니다. 원격 프로세서는 펌웨어 또는 운영 체제의 서로 다른 인스턴스를 실행합니다. Qualcomm Linux가 다른 코어를 관리하기 위해 사용하는 표준 프레임워크에 대한 자세한 내용은 [Remote Processor Framework](https://www.kernel.org/doc/html/next/staging/remoteproc.html) 를 참조하세요. ## Qualcomm remoteproc 지원 퀄컴은 업스트림 PAS 드라이버를 사용하여 주변장치 펌웨어를 인증할 수 있는 remoteproc 프레임워크를 개선했습니다. Qualcomm Linux의 Remoteproc 드라이버는 Qualcomm SoC 기기의 원격 프로세서를 위한 TrustZone 기반 주변장치 이미지 로더인 PAS(Peripheral Authentication Service) 드라이버를 구현합니다. 자세한 내용은 [qcom_q6v5_pas.c](https://github.com/torvalds/linux/blob/master/drivers/remoteproc/qcom_q6v5_pas.c) 를 참조하세요. 원격 프로세서는 aDSP, cDSP, MPSS(Modem Peripheral Subsystem), WPSS(Wireless Processor Subsystem) 등과 같은 다양한 코프로세서의 수명 주기를 관리하는 데 사용됩니다. 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 서브 기기는 원격 프로세서 서브시스템 충돌 및 복구 시나리오를 위한 통신 컨텍스트를 관리합니다. 통신 컨텍스트 같은 엔터티는 원격 프로세서를 부팅하거나 종료하는 시기를 결정해야 합니다. 각 서브 기기는 두 가지 작업을 수행합니다. - remoteproc `start()` 후에 `probe()` 호출됨 - `stop()` 전에 `remove()` 호출됨 원격 프로세서에서 오류가 발생하면, 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 SoC는 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 코어 덤프 파일을 호스트 기기로 전송하고 문제를 디버그하려면 QCAP(Qualcomm Crash Analysis Portal)를 사용하세요. 참고 QCAP에 대한 자세한 내용은 [QCAP를 사용하여 RAM 구문 분석](https://docs.qualcomm.com/bundle/resource/topics/80-70020-12A/debugging_linux_kernel.html#parse_ram_dumps_using_qcap) 을 참조하세요. ## DT의 remoteproc 노드 및 펌웨어 로드 구성 remoteproc 기기는 DT 바인딩을 사용하여 각 기기 트리 파일에서 구성됩니다. 구성에는 DT 바인딩에 따라 호환되는 기기 이름, 메모리 영역, 인터럽트 설정, 클럭 참조가 `Documentation/devicetree/bindings/remoteproc/` 디렉토리에 포함됩니다. 다음 예시는 `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-3KO/topics/kernel-development.md) [Next Topic 메모리 구성 및 관리](https://docs.qualcomm.com/bundle/publicresource/80-70020-3KO/topics/memory.md)