2. Snapdragon硬件架构解析
双系统设备并不是把两套操作系统“装进同一块存储”那么简单。Android 与 Linux（或 Windows on ARM、QNX 等第二系统）要共享同一颗 Snapdragon SoC，就必须共享 CPU 时间片、GPU 渲染管线、DSP/NPU 加速器、内存控制器带宽以及片内总线。理解这些硬件单元在双系统下的资源归属与切换方式，是判断“能不能双系统、怎么切、切了之后性能如何”的基础。
一、CPU：大小核簇与启动核的归属
Snapdragon 8 系典型采用 1+3+4 或 1+4+3 的三簇结构，例如 1×Cortex-X 超大核 + 3×A7xx 性能核 + 4×A5xx 能效核，共享 L3，并通过 DSU（DynamIQ Shared Unit）连接。双系统下 CPU 的核心问题不是“有几个核”，而是哪个核负责启动、哪个核被哪个系统占用。
常见做法是：主系统（Android）运行在全部核心上，第二系统通过虚拟化（如 Gunyah Hypervisor）或 CPU 热插拔获得部分核心。若采用 Hypervisor 方案，通常把 CPU 划分为多个 vCPU，由 Hypervisor 在物理核上调度；若采用“双 boot”方案，则两个系统分时独占全部核心，切换时整机重启或进入休眠再唤醒。前者切换快（秒级），但两个系统同时运行时 CPU 缓存与频率策略会互相干扰；后者切换慢（数十秒），但每个系统都能拿到完整的 DVFS 与热管理策略。
实际配置中需要关注：CPU 亲和性（taskset/cpuset）、中断亲和性（IRQ affinity）、以及 cpufreq governor 的归属。如果第二系统只拿到小核，而 Android 仍占用大核，那么第二系统在编译、解码等重负载下会明显受限。示例参数：给第二系统预留 2×A5xx + 1×A7xx，Android 保留 X 核与其余性能核，可让第二系统在 1080p 软解时保持约 30fps，而 Android 前台仍流畅。
二、GPU：渲染上下文与显示通路的争用
Adreno GPU 在双系统下有两种典型模式：独占模式与分时/虚拟化模式。独占模式下，同一时刻只有一个系统持有 GPU 与显示控制器（DPU），切换时需保存/恢复 GPU 上下文并重新初始化显示管线；虚拟化模式下，GPU 通过 SR-IOV 或厂商虚拟化方案被划分为多个 vGPU，两个系统可同时渲染，但显存带宽与渲染队列会互相竞争。
对双系统影响最大的是显示通路：DPU 的图层混合器、DSI/DP 输出、以及 HDR/刷新率策略通常由主系统初始化。第二系统若想直接输出，需要接管或共享 DPU 的某个 CRTC/图层。实践中更稳妥的是让第二系统通过主系统的显示服务“窗口化”输出，或使用独立的物理接口（如外接 DP）。若强行让两个系统同时驱动同一 DSI 面板，容易出现时序冲突、闪屏或背光失控。
三、DSP 与 NPU：加速器的共享与隔离
Hexagon DSP（含 cDSP、ADSP）和 Hexagon NPU 是双系统中最容易被忽视、却最容易出问题的部分。它们通常由主系统的 ADSP/MPSS 固件加载并管理，第二系统若直接访问，可能触发固件崩溃或安全域（TZ）异常。合理路径是：第二系统通过 FastRPC 或厂商提供的 RPC 通道，向主系统的 DSP/NPU 服务提交任务；或者由 Hypervisor 将某个 DSP 子系统直通给第二系统。
NPU 的典型参数包括 TOPS 算力、支持的量化格式（INT8/INT16/FP16）、以及内存占用。双系统下若两个系统同时调用 NPU，需要约定优先级与超时。例如 Android 侧相机 AI 降噪占用 NPU 时，第二系统的推理任务应排队或降级到 CPU，否则会出现推理超时甚至 NPU 固件复位。
四、内存控制器与总线：带宽是双系统的硬约束
Snapdragon 的内存子系统由 DDR 控制器、系统缓存（SLC/LLCC）、以及 NoC（Network-on-Chip）总线组成。双系统同时运行时，两个系统的 CPU、GPU、DSP、NPU 都会通过 NoC 访问 DDR，带宽与延迟是共享的。典型 LPDDR5 带宽约 50–60 GB/s，看似充裕，但 4K 视频解码 + GPU 渲染 + NPU 推理叠加后很容易逼近上限。
因此双系统设计必须做带宽预算：给主系统预留显示与相机带宽，给第二系统限定 GPU/NPU 的并发任务数。可通过 QoS 寄存器、LLCC 分区、以及 NoC 优先级配置来隔离。若不做隔离，第二系统的大块内存拷贝会拉高 Android 侧显示延迟，表现为掉帧或触控不跟手。
五、对双系统方案的实际影响与判断依据
把上述单元放在一起看，双系统方案的选择可以归结为三条判断线：
- 切换速度 vs 资源完整性：Hypervisor 方案切换快，但 CPU/GPU/NPU 都是“分时共享”，重负载下两个系统都会降速；双 boot 方案切换慢，但每个系统独占全部硬件，适合对性能确定性要求高的场景（如车载仪表 + 娱乐）。
- 固件归属：ADSP、NPU、Modem 固件通常只能由主系统加载。第二系统若需要这些单元，必须走 RPC 或直通，不能自行加载固件，否则会触发安全域异常。
- 带宽与延迟：双系统同时跑视频、AI、显示时，DDR 带宽是硬上限。设计时应先做带宽预算表，再决定第二系统能开多少并发任务。
cat /sys/kernel/debug/clk/clk_summary 和 cat /proc/interrupts 确认 CPU/中断归属；再用 devfreq 与 llcc 节点观察带宽压力。若第二系统一跑大内存拷贝就导致 Android 掉帧，说明 NoC QoS 或 LLCC 分区未配置到位。示例配置片段（Hypervisor 场景，仅示意）：
# 为第二系统预留 CPU 与内存
cpuset.second_sys = 4-6 # 2×A5xx + 1×A7xx
mem.second_sys = 0x80000000,0x40000000 # 1GB 起始 2GB 处
# NoC QoS：第二系统 GPU 写优先级低于显示
qos.noc.gpu_second = 0x3
qos.noc.display = 0x7
# NPU 任务超时与降级
npu.task.timeout_ms = 50
npu.fallback_cpu = 1
判断双系统是否“跑得动”，不要只看能不能启动，而要看三个可观测指标：切换后首帧显示延迟、双系统并发时 Android 的帧率波动、以及 NPU/DSP 任务是否出现超时或复位。若这三项都在可接受范围内，说明 CPU、GPU、DSP、NPU、内存与总线的资源划分基本合理；否则应回到 Hypervisor 配置或 QoS 参数上逐项调整。