Linux 6.18 remoteproc·rpmsg · 플랫폼별 지원 범위 확인

Linux 보조 CPU와 DSP·MCU 시작은 어떻게 다릅니까

remoteproc의 펌웨어 시작과 rpmsg의 메시지 전달을 분리해서 읽습니다.

같은 Linux를 실행하는 CPU인지 먼저 구분합니다

구분시작 후 무엇을 실행합니까?Linux에서 보는 대상
SMP 보조 CPU다른 CPU와 같은 Linux kernel의 실행 경로로 들어갑니다.scheduler가 작업을 배치할 CPU
별도 DSP·MCU 등별도 firmware·RTOS 또는 다른 실행 환경을 시작할 수 있습니다.remote processor 장치와 통신 서비스

PSCI CPU_ON이나 SBI hart_start로 CPU를 시작하는 설명을 모든 DSP·MCU에 그대로 적용할 수는 없습니다. 같은 칩 안에 있어도 실행 이미지, 주소 공간, reset·clock 제어, 통신 protocol이 다릅니다. Linux는 remoteproc을 통해 지원되는 remote processor의 firmware 적재와 실행 수명을 관리할 수 있습니다. Remote Processor Framework

firmware를 시작했다고 서비스 준비가 끝난 것은 아닙니다

remoteproc과 virtio rpmsg를 사용하는 구성의 예
  1. firmware와 메모리 준비

    firmware 형식·적재 주소·예약 메모리와 자원 요구를 확인합니다.

    플랫폼 driver가 실행 조건을 준비합니다.

  2. remote processor 시작

    지원되는 start 동작으로 reset·전원 등 필요한 제어를 수행합니다.

    별도 processor가 자기 firmware를 실행합니다.

  3. 통신 자원과 서비스 준비

    공유 ring·notification 경로와 protocol을 양쪽이 맞춥니다.

    rpmsg 채널 및 해당 driver를 연결합니다.

  4. 실제 요청과 응답

    서비스의 준비 상태를 확인하고 작업을 주고받습니다.

화살표는 준비와 의존 순서입니다. 모든 remoteproc firmware가 rpmsg를 제공하거나 CPU 시작 함수의 반환이 서비스 준비 완료를 뜻하는 것은 아닙니다.

resource table은 firmware가 요구하는 메모리·virtio 장치 등의 자원을 기술할 수 있습니다. firmware가 쓰는 device address를 주 CPU의 가상 주소와 혼동하면 안 됩니다. 플랫폼의 주소 변환과 실제 예약 영역을 함께 봐야 합니다. 이미 실행 중인 processor에 연결하는 지원 등도 플랫폼마다 다르므로 이 예를 유일한 시작 방식으로 단정하지 않습니다.

메시지를 보냈다는 것은 요청이 끝났다는 뜻이 아닙니다

rpmsg는 remote processor와 메시지를 주고받는 bus이며 endpoint는 메시지의 송수신 대상을 연결합니다. endpoint의 숫자 주소는 그 processor의 RAM 주소가 아닙니다. transport가 메시지를 받았다는 결과와 상대 서비스가 일을 끝내 보낸 응답을 구분해야 합니다. rpmsg 채널·endpoint·전송

확인하는 상태필요한 정보
전송 가능채널·endpoint·TX buffer 등 transport 상태
요청 수락상대 protocol이 정한 응답·오류 코드
작업 완료요청 ID와 연결된 완료 통지 및 결과
상대 재시작 이후기존 endpoint·진행 중 요청·공유 버퍼가 여전히 유효한지 여부

요청을 보내는 함수가 0을 반환해도 상대의 긴 계산이 끝났다고 해석하지 않습니다. timeout 뒤에는 늦은 응답이 올 수 있으므로 요청 번호와 객체 수명을 관리해야 합니다. 공유 메모리와 notification을 함께 쓸 때에는 데이터 준비와 상대 통지의 순서도 지켜야 합니다. 장치·CPU 사이의 메모리 순서

CPU online 목록만으로 DSP 상태를 판단하지 않습니다

현상다음 확인
Linux CPU 목록에 추가되지 않습니다.별도 firmware를 실행하는 장치라면 SMP CPU가 늘어나는 경로가 아닐 수 있습니다.
firmware 시작 로그는 있지만 채널이 없습니다.firmware·resource 설정, ring·notification, 서비스 발표와 driver match를 봅니다.
채널은 있지만 응답이 없습니다.protocol 버전·요청 형식·상대 실행 상태·공유 메모리 가시성을 봅니다.
remote firmware가 재시작했습니다.이전 요청의 취소·buffer 회수·서비스 재연결 순서를 확인합니다.

별도 processor가 접근할 수 있는 RAM과 peripheral 범위도 확인해야 합니다. 메시지 endpoint를 제한하는 것과 하드웨어 메모리 접근을 격리하는 것은 다른 문제입니다. remote firmware가 trusted execution environment가 되는 것도 아닙니다. TrustZone·IOMMU·방화벽 등 실제 보드의 보호 구성을 기준으로 판단합니다.