같은 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를 시작했다고 서비스 준비가 끝난 것은 아닙니다
- firmware와 메모리 준비
firmware 형식·적재 주소·예약 메모리와 자원 요구를 확인합니다.
플랫폼 driver가 실행 조건을 준비합니다.
- remote processor 시작
지원되는 start 동작으로 reset·전원 등 필요한 제어를 수행합니다.
별도 processor가 자기 firmware를 실행합니다.
- 통신 자원과 서비스 준비
공유 ring·notification 경로와 protocol을 양쪽이 맞춥니다.
rpmsg 채널 및 해당 driver를 연결합니다.
- 실제 요청과 응답
서비스의 준비 상태를 확인하고 작업을 주고받습니다.
화살표는 준비와 의존 순서입니다. 모든 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·방화벽 등 실제 보드의 보호 구성을 기준으로 판단합니다.