Linux AMP 技术讲解一
01. Linux 为什么需要 AMP
Linux:适合复杂系统，多任务，网络/UI/AI
但 Linux:延迟不可预测，中断干扰较大,实时性不足
RTOS:延迟低，调度确定，适合实时控制
因此新架构AMP诞生了，AMP 核心思想：“复杂任务与实时任务分离”
02. 异构 SoC 架构
现代 SoC:通常包含多种不同核心
例如:Cortex-A、M、R，DSP，NPU
A Core:Linux，高性能，MMU，Cache，多任务
负责:GUI，Network，Filesystem
M/R Core:RTOS，Bare-metal，低延迟，实时响应
负责:PWM，GPIO，Motor
DSP:Audio，FFT，Radar
NPU:，AI Inference，Neural Network
异构 SoC 目标:“不同核心负责不同任务”
03. SMP 与 AMP 架构对比
SMP:多个 CPU，单 Linux，共享 Kernel，共享 Scheduler，共享 Memory
特点:高吞吐，易开发
缺点:实时性差，干扰较大
AMP:多个 CPU，多 OS，独立 Scheduler，独立 Runtime
特点:实时隔离，高可靠
AMP 本质:“分布式系统”
04. Linux AMP 整体软件栈
APP>RPMsg>VirtIO>remoteproc>Mailbox>Shared Memory>Remote CPU
1.APP:用户应用层
例如:ROS，IPC Service
2.RPMsg:消息通信层
负责:Channel,Endpoint,Message Routing
3.VirtIO:共享内存通信抽象层
负责:vring,descriptor,buffer queue
4.remoteproc:Remote CPU 生命周期管理
负责:load firmware,boot cpu,recovery
5.Mailbox:CPU 间通知机制
作用:通知远端 CPU 有新消息
6.Shared Memory:共享数据区
作用:Linux 与 RTOS通过共享内存交换数据
05. remoteproc 整体架构
Linux>remoteproc Core>Platform Driver>Remote CPU
remoteproc Core:统一管理 Remote CPU
Platform Driver:不同 SoC启动 CPU 方法不同
Remote CPU:M4、R5等，运行RTOS
remoteproc:负责底层 CPU 管理
RPMsg:负责上层消息通信
06. remoteproc 启动流程
rproc_boot()>request_firmware()>parse ELF>parse resource_table>alloc carveout>create virtio>boot remote cpu
Step 1:request_firmware()
Linux:从 /lib/firmware读取 ELF 固件
Step 2:parse ELF
解析:.text，.data，entry point
Step 3:parse resource_table
获取:carveout，vring，vdev，trace
Step 4:alloc carveout
申请:shared memory，vring buffer
Step 5:create virtio
创建:VirtIO Device，为 RPMsg 建立通信基础
Step 6:boot remote cpu
通过:reset release，mailbox，IPI启动 Remote CPU
