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

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

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

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

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

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

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

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

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

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

STM32MP25의 M33 적재·인증·reset 담당자를 구분합니다

STM32MP257F-DK의 Cortex-A35에서 Linux를, Cortex-M33에서 별도 펌웨어를 실행하는 구성에서도 최종 제어 주체는 하나로 고정되지 않습니다. 2026년 10월 30일 확인한 Zephyr 보드 가이드의 A35가 M33 이미지를 적재하는 예를 모든 보안·부팅 구성의 공통 절차로 읽으면 안 됩니다. ST 문서에서는 trusted-domain 구성과 이미지 관리 경로를 먼저 나눕니다.

ST Linux remoteproc 문서의 M33 구성에서 서명 이미지용 Linux DT는 IPC 공유 영역을 남기고 reset 선언을 제거합니다. 반면 OP-TEE 쪽 DT 예는 펌웨어용 메모리와 reset/hold-boot 관리를 보안 쪽에 둡니다. Linux DT와 OP-TEE DT는 같은 역할의 복제본이 아닙니다. 펌웨어·TF-M 링커 주소, 예약 메모리와 OP-TEE 자원 격리 설정을 같은 구성으로 맞춰야 하며 파일 확장자만 바꿔 경로를 전환할 수 없습니다. 해당 OP-TEE 문서는 M33-TD에는 적용되지 않는다고 명시합니다.

부팅 로그와 RPMsg 서비스 준비는 별도 증거입니다

STM32MP257F-DK 실습 글의 blinky 구간에는 resource table 관련 경고 뒤 M33 시작 로그가 나옵니다. 이는 그 글에서 보고한 실행이며 여기서 재현한 결과는 아닙니다. 경고 문구 하나로 ELF 섹션의 실제 내용까지 확정하거나 모든 플랫폼에서 resource table이 불필요하다고 일반화하지 않습니다.

예를 들어 Linux v6.18.37의 공통 ELF 테이블 로더는 테이블을 찾지 못하면 오류를 반환합니다. 같은 버전의 STM32 플랫폼 parse 콜백은 그 오류를 경고로 남기고 계속하는 예지만, 이 파일의 compatible 목록은 STM32MP1 M4입니다. 이 코드가 실습 글의 M33 BSP 코드와 같다고 주장하지 않습니다. 실제 판단에는 해당 보드 BSP의 parse 경로와 펌웨어·통신 자원 구성이 필요합니다.

ST RPMsg 설명은 서비스 발표·이름 매칭과 클라이언트 드라이버를 구분합니다. M33이 running이거나 LED가 깜빡여도 RPMsg 채널·TTY 서비스가 준비됐다는 증거는 아닙니다. IPCC 인터럽트를 받았다는 사실만으로 TTY 노드가 자동 생성된다고 해석하지 않습니다. 이 절에서는 기존 펌웨어를 중지하거나 교체하지 않았고, 키·TrustZone·DT 설정을 바꾸거나 실제 RPMsg 통신을 시험하지 않았습니다.

이어서 읽기

• PSCI·SBI·x86의 보조 CPU 시작
• RISC-V 보조 hart의 레지스터 값
• 오디오 DSP 경로
• 완료 통지와 객체 수명
• CPU를 깨우는 전체 과정: Linux → TF-A → 새 CPU