1. 课程导入
各位同学，欢迎来到这门实战课。我是老周，在嵌入式Linux和车规级系统调试这块摸爬滚打了十几年。今天咱们先聊聊汽车电子电气架构的演进，再看看QEMU在车规级开发里到底能干啥，最后把仿真环境搭起来。
说实话，我刚入行那会儿，车上一个ECU管一个功能，出问题拿JTAG焊线调试。现在呢？一台域控制器跑着Linux，上面挂十几个虚拟化实例。这变化太大了。你想想看，没有仿真工具，光靠真车调试，成本高、周期长，还容易把硬件搞坏。
1.1 汽车电子电气架构演进
汽车电子电气架构，说白了就是车上所有电子控制单元怎么连、怎么通信、怎么协同工作的体系。我把它分成三个阶段：
| 阶段 | 典型架构 | ECU数量 | 通信方式 | 软件复杂度 |
|---|---|---|---|---|
| 分布式 | 每个功能一个ECU | 50-100+ | CAN/LIN | 低 |
| 域集中式 | 域控制器+区域网关 | 20-50 | CAN FD / 以太网 | 中 |
| 中央计算式 | 中央计算机+区域控制器 | 5-10 | 车载以太网 / PCIe | 极高 |
我在2018年参与过一个项目，客户还在用分布式架构，一个车窗升降功能要跨三个ECU通信。调试时发现CAN报文丢帧，查了整整两周。后来换了域集中架构，问题自然消失了。这就是架构演进带来的好处——减少跨节点通信，降低调试复杂度。
核心观点：架构演进的核心驱动力是软件定义汽车。硬件趋同，软件差异化成为竞争焦点。而软件复杂度爆炸式增长，倒逼仿真工具成为刚需。
1.2 QEMU在车规级开发中的价值
QEMU是什么？它是一个开源的全系统仿真器。能仿真CPU、内存、外设，甚至整个SoC。在车规级开发里，它的价值体现在三个维度：
- 硬件不可用时的开发支撑——芯片还在流片，QEMU已经能跑Linux了。我有个项目，芯片延期三个月，全靠QEMU把BSP和中间件调通了。
- 故障注入与边界测试——真车上你不敢随便拔电源、断总线。QEMU里可以随意模拟这些故障，而且可复现。
- 性能分析前置——在QEMU上跑AGL或Android Automotive，提前发现启动慢、内存泄漏、中断延迟高等问题。
我的经验：QEMU不能完全替代真硬件，但能让80%的软件问题在仿真阶段暴露。剩下的20%，往往是时序敏感或硬件特性依赖的问题，需要上板调试。
为什么会这样？因为QEMU的仿真粒度是指令级的，它不模拟真实的时钟周期。所以像Cache miss、DDR带宽这类微架构行为，QEMU是看不到的。但系统级的行为——进程调度、内存管理、驱动框架——QEMU仿真得相当准。
1.3 搭建QEMU + AGL/Android Automotive仿真环境
好，理论说完了，咱们动手。下面这张图是整套环境的结构：
1.3.1 环境准备清单
我个人习惯用Ubuntu 22.04 LTS作为开发机。如果你用macOS或Windows，建议先装好Docker或WSL2。下面是必备软件清单：
| 软件 | 版本要求 | 安装方式 | 备注 |
|---|---|---|---|
| QEMU | ≥ 8.0 | apt install qemu-system-arm |
建议源码编译，开启KVM |
| AGL SDK | Quillback (14.0) | Yocto构建或预编译镜像 | 需要约80GB磁盘空间 |
| Android AOSP | android-14.0.0_r1 | repo sync + lunch | 需要约200GB磁盘空间 |
| 交叉编译工具链 | gcc-arm-11.2 | apt或Linaro官方 | aarch64-linux-gnu- |
避坑指南：我曾经在Ubuntu 20.04上直接apt安装QEMU 6.2，结果AGL的virtio-gpu驱动不兼容，折腾了两天。后来升级到QEMU 8.0，问题解决。所以，版本一定要按清单来。
1.3.2 快速启动AGL仿真
假设你已经下载了AGL的预编译镜像。启动命令很简单：
#!/bin/bash
# 启动AGL on QEMU (ARM64)
qemu-system-aarch64 \
-M virt -cpu cortex-a72 -smp 4 -m 4096 \
-kernel Image \
-dtb qemu-virt.dtb \
-drive file=agl-qemu-image.qcow2,format=qcow2,id=hd,if=none \
-device virtio-blk-device,drive=hd \
-netdev user,id=net0,hostfwd=tcp::2222-:22 \
-device virtio-net-device,netdev=net0 \
-device virtio-gpu-device \
-serial stdio \
-append "root=/dev/vda2 console=ttyAMA0"启动后，你会看到AGL的启动日志。第一次启动大概需要3-5分钟。嗯，这里要注意：如果卡在Waiting for root device，多半是设备树或根文件系统分区号不对。检查-append里的root=/dev/vda2是否匹配你的镜像分区。
调试小技巧：加上-serial stdio后，所有内核日志会输出到终端。如果系统启动后看不到图形界面，可以按Ctrl+Alt+F2切换到串口控制台，用ps aux检查Weston是否在运行。
1.3.3 Android Automotive仿真
Android Automotive的QEMU仿真稍微复杂些，因为需要模拟Goldfish平台或Cuttlefish。我个人推荐用Cuttlefish，它是Google官方维护的虚拟设备：
# 下载Cuttlefish预编译镜像
mkdir cuttlefish && cd cuttlefish
wget https://ci.android.com/builds/latest/branches/aosp-main/targets/aosp_cf_x86_64_auto-userdebug/view/cvd-host_package.tar.gz
tar xzf cvd-host_package.tar.gz
# 启动
HOME=$PWD ./bin/launch_cvd --vm_manager=qemu_cli \
--memory_mb=4096 \
--cpus=4 \
--enable_automotive=true启动后，通过VNC或WebRTC连接图形界面。你会看到Android Automotive的Launcher，包含车载专用的状态栏、空调控制、导航等HMI元素。
为什么推荐Cuttlefish而不是自己编译AOSP？因为AOSP编译一次要4-6小时，而且依赖项极多。Cuttlefish的预编译镜像每周更新，省去了搭建构建环境的痛苦。我在项目中就吃过这个亏——花了两天配环境，结果编译报错，最后发现是JDK版本不对。
1.3.4 验证环境是否就绪
环境搭好后，做几个快速验证：
- 网络连通性：从宿主机
ping 192.168.7.2（QEMU默认网关），能通说明网络正常。 - SSH登录：
ssh root@localhost -p 2222，能登录说明端口转发正常。 - 图形界面：VNC连接
localhost:5900，能看到桌面说明显示正常。 - 性能工具：在QEMU内运行
perf stat sleep 1，能输出说明perf可用。
我的建议：别急着往下走。花15分钟把这三个验证都跑一遍。如果哪个不通，先排查再继续。否则后面调试时发现环境有问题，你会怀疑人生。
好，环境准备就到这儿。记住，仿真环境是你的第一道防线。在真车上复现一个bug，成本可能是仿真环境的10倍以上。所以，把环境搭扎实了，后面的调试和性能分析才能事半功倍。