3. 高通平台概述
说实话，做车载环视系统，环境搭建这一步最容易被低估。很多人觉得不就是装个SDK嘛，结果一上手就卡在交叉编译链上，一卡就是两三天。我当年第一次碰高通SA8155平台时，光是把QNX BSP的编译环境跑通，就折腾了整整一个周末。
这一章，我把这些年踩过的坑和总结的流程直接摊开讲。你跟着走，能省不少时间。
3.1 高通SDK与BSP获取
高通的车载芯片方案，比如SA8155、SA8295，它们的SDK和BSP不是公开下载的。你需要先拿到高通的授权，然后通过高通开发者网络（QDN）或者ChipCode门户获取。
| 组件 | 获取途径 | 说明 |
|---|---|---|
| LE SDK（Linux Embedded） | QDN / ChipCode | 用于Android或Yocto Linux开发 |
| QNX BSP | QNX Software Center / 高通交付 | 包含Board Support Package和Hypervisor |
| Qualcomm Camera SDK | QDN | 环视算法依赖的ISP和摄像头驱动 |
| FastCV / SNPE | QDN | 视觉算法加速库 |
release_notes.txt。里面通常会写明已知问题、依赖的编译器版本、以及补丁包。跳过这一步，后面编译报错你都不知道从哪查起。
3.2 交叉编译工具链配置
交叉编译，说白了就是在你的x86电脑上编译出能在ARM芯片上跑的程序。高通平台一般用aarch64架构。
3.2.1 工具链选择
高通官方推荐的是GCC Linaro或Android NDK。如果你做QNX开发，那就必须用QNX自家的QNX Momentics IDE自带的工具链。
# 以Android NDK为例，设置环境变量
export ANDROID_NDK_HOME=/opt/android-ndk-r25c
export PATH=$ANDROID_NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin:$PATH
# 验证工具链
aarch64-linux-android21-clang++ --version
3.2.2 CMake交叉编译配置
我个人习惯用CMake管理项目。写一个toolchain.cmake文件，一劳永逸。
# toolchain.cmake for Qualcomm SA8155 Android
set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_SYSTEM_VERSION 21)
set(CMAKE_ANDROID_ARCH_ABI arm64-v8a)
set(CMAKE_ANDROID_NDK /opt/android-ndk-r25c)
set(CMAKE_ANDROID_STL_TYPE c++_shared)
然后编译时这样调用：
mkdir build && cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake
make -j$(nproc)
3.3 ADB与Fastboot调试
这两个工具是Android平台调试的左右手。ADB负责运行时调试，Fastboot负责刷机和底层操作。
3.3.1 ADB常用命令
| 命令 | 用途 | 我的经验 |
|---|---|---|
adb devices |
查看连接的设备 | 如果设备列表为空，先检查驱动 |
adb logcat |
查看系统日志 | 配合 -s 过滤标签，比如 adb logcat -s SurroundView |
adb shell |
进入设备终端 | 调试环视算法时，我经常用这个看进程状态 |
adb push/pull |
文件传输 | 把编译好的so库推到设备里测试 |
adb forward |
端口转发 | 用于gdb远程调试 |
3.3.2 Fastboot刷机
做系统集成，刷机是家常便饭。Fastboot模式下，你可以刷写boot、system、vendor等分区。
# 进入Fastboot模式
adb reboot bootloader
# 刷写分区
fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash vendor vendor.img
# 重启
fastboot reboot
3.4 Qualcomm Debugger (QD) 与 Trace32 基础
这两个工具是调试硬核问题的利器。QD是高通自己的调试器，Trace32是Lauterbach的通用调试工具。做底层驱动和BSP移植时，你几乎离不开它们。
3.4.1 Qualcomm Debugger (QD)
QD通常和JTAG/SWD调试器配合使用。它可以让你在芯片级别单步执行代码、查看寄存器状态、分析内存。
我一般在以下场景用QD：
- 启动流程卡住，怀疑是PBL（Primary Boot Loader）问题
- 摄像头ISP初始化失败，需要看硬件寄存器配置
- 系统crash后，分析dump文件定位死机原因
# QD常用命令示例
# 连接目标设备
connect -device sa8155 -transport jtag
# 加载符号表
load -symbols /path/to/vmlinux
# 设置断点
breakpoint -set -address 0x80200000
# 单步执行
step -instruction
3.4.2 Trace32基础
Trace32功能更强大，但学习曲线也陡。说实话，我刚开始用Trace32时，光看那满屏的窗口就头疼。后来发现，你只需要掌握几个核心功能就行。
| 功能 | 操作 | 适用场景 |
|---|---|---|
| 加载ELF文件 | Data.LOAD.Elf |
调试裸机程序或RTOS |
| 设置断点 | Break.Set |
定位代码执行路径 |
| 查看内存 | Data.Dump |
检查摄像头buffer数据 |
| Trace记录 | Trace.Start |
分析时序问题 |
3.5 本章知识体系
下面这张图，把本章的核心内容串起来了。你可以把它当作环境搭建的路线图。
嗯，这一章的内容就这些。环境搭建看着琐碎，但每一步都关系到后续开发效率。工具链配好了，调试工具用熟了，后面做环视算法集成时才能得心应手。