📚 课程目录第3章开发环境搭建与工具链

3. 开发环境搭建与工具链

Snapdragon Ride 平台的开发环境不是“装一个 IDE 就能跑”的桌面式环境，而是一条从主机（Host）到目标板（Target）的跨架构工具链。典型主机是 x86_64 的 Ubuntu 20.04/22.04，目标板是 aarch64 架构的 SA8540P/SA8620P 等 SoC，运行 QNX、Android Automotive 或 Linux 中的一种或多种操作系统。因此本节的核心任务是：把 SDK、交叉编译器、调试器、仿真环境和目标板连接这五件事串成一条可复现的链路，并明确每一步的输入、产物和验证方式。

一、SDK 获取与目录结构

高通面向智能驾驶的软件包通常通过 Qualcomm CreatePoint / Chipcode 门户分发，需要企业账号与 NDA 授权。以 Ride 平台为例，常见组件包括：QNX 或 Linux BSP（含 bootloader、内核、设备树）、Hexagon SDK（用于 NPU/DSP 侧算子开发）、Snapdragon Ride SDK（含感知、规划等中间件与示例）、QAIRT/QNN（模型量化与推理运行时）以及 工具链压缩包。下载后建议按固定目录组织，避免后续脚本路径混乱：

~/ride/
├── sdk/            # 解压后的 SDK 与 BSP
├── toolchain/      # 交叉编译器
├── qairt/          # QNN / QAIRT
├── workspace/      # 自己的工程
└── images/         # 烧录镜像与产物

验证 SDK 是否完整，最直接的方式是检查关键文件是否存在，例如 BSP 中的 boot.img、system.img、设备树 *.dtb，以及 QNN 的 libQnnHtp.so。若缺少这些，后续编译或推理会直接失败。

二、交叉编译工具链

主机是 x86_64，目标板是 aarch64，因此必须使用交叉编译器。高通 BSP 一般自带预编译工具链，常见前缀为 aarch64-qnx 或 aarch64-linux-gnu。配置时把工具链的 bin 目录加入 PATH，并用 --sysroot 指向目标根文件系统，确保头文件和库来自目标侧而非主机：

export TOOLCHAIN=~/ride/toolchain/aarch64-linux-gnu
export PATH=$TOOLCHAIN/bin:$PATH
export SYSROOT=~/ride/sdk/sysroot
export CC=aarch64-linux-gnu-gcc
export CXX=aarch64-linux-gnu-g++
export CFLAGS="--sysroot=$SYSROOT -march=armv8-a"

验证方法：编译一个最小程序并检查其架构。若 file 输出为 ELF 64-bit LSB, ARM aarch64，说明工具链生效；若显示 x86-64，则说明仍在用主机编译器。

aarch64-linux-gnu-gcc hello.c -o hello --sysroot=$SYSROOT
file hello
# 期望：ELF 64-bit LSB executable, ARM aarch64

对于 CMake 工程，建议写一个 toolchain.cmake，把 CMAKE_SYSTEM_NAME 设为 Linux、CMAKE_SYSTEM_PROCESSOR 设为 aarch64，并指定 CMAKE_C_COMPILER 与 CMAKE_SYSROOT。这样工程无需每次手动传参，也便于团队统一。

三、调试器与调试通道

调试分两个层次：应用层用 gdbserver + 交叉 gdb，内核/底层用 Lauterbach TRACE32 或 OpenOCD + JTAG。应用层最常用：目标板运行 gdbserver :1234 ./app，主机运行 aarch64-linux-gnu-gdb ./app，再执行 target remote <板卡IP>:1234。若程序崩溃，先看 dmesg 是否有段错误记录，再用 addr2line 把地址翻译成源码行：

aarch64-linux-gnu-addr2line -e app -f -C 0x400a1c

对于 QNX 目标，调试器换成 gdb 的 QNX 版本，连接方式类似，但需注意 QNX 的进程模型与 Linux 不同，pidin 可用来查看进程状态。JTAG 调试则用于 bootloader 阶段或内核启动早期，此时网络和 gdbserver 尚不可用，必须依赖硬件探针。

四、仿真环境

在没有目标板或需要快速迭代算法时，仿真环境非常关键。常见做法有三类：QEMU 全系统仿真（可跑 aarch64 Linux 镜像，验证启动与基础库）、QNN 的 CPU/HTP 模拟后端（在主机上验证模型推理精度与算子支持）、以及传感器/车辆动力学仿真（如 CARLA 或自研场景回放）。QEMU 启动示例：

qemu-system-aarch64 -M virt -cpu cortex-a57 -m 4G \
  -kernel Image -append "console=ttyAMA0 root=/dev/vda" \
  -drive file=rootfs.ext4,format=raw -nographic

仿真能验证“逻辑是否正确”，但不能替代目标板验证“性能与实时性”。例如 NPU 的时延、内存带宽、DMA 行为，只有在真实 SA8540P 上才有意义。因此建议流程是：仿真先跑通功能，再上板做性能与稳定性验证。

五、目标板连接与烧录

目标板连接通常包括：电源、调试串口（UART，用于看 bootloader 与内核日志）、以太网（用于 SSH、NFS、gdbserver）、USB/JTAG（用于烧录与底层调试）。首次上电前，先用串口工具（如 minicom 或 picocom）以 115200 8N1 连接，确认能看到 U-Boot 输出。烧录常用 fastboot 或高通 QDL 工具：

fastboot devices
fastboot flash boot boot.img
fastboot flash system system.img
fastboot reboot

烧录后通过串口确认内核启动到登录提示，再用 ssh root@<板卡IP> 登录。若网络不通，先检查 ip addr 与路由，必要时用 udhcpc 获取地址。最后用 uname -a 确认内核版本与架构，用 cat /proc/cpuinfo 确认 CPU 核数，确保与 BSP 预期一致。

建议把上述环境变量、烧录命令和验证命令写成一个 setup_env.sh 与 flash.sh，每次换机器或换板卡时直接复用，减少人为路径错误。

把这条链路走通后，后续的模型部署、算子调试和实车集成才有稳定基础。建议每完成一个环节就记录一次验证结果，形成自己的环境检查清单，避免在真正开发时被环境问题反复打断。