📚 课程目录第4章开发环境搭建

4. 开发环境搭建

高通SA8155平台属于典型的ARM64异构SoC，其显示子系统（DPU）、GPU（Adreno 640）以及各类外设驱动都运行在Linux内核态。宿主机（通常是x86_64 Ubuntu）无法直接编译出可在SA8155上运行的二进制，因此必须建立一套完整的交叉编译与调试环境。本章围绕工具链、内核源码、设备树和调试通道四条主线展开，帮助你把“能编译、能烧写、能看日志”这条链路一次性打通。

一、核心原理：为什么需要交叉编译

交叉编译的本质是“在A架构主机上生成B架构目标代码”。SA8155使用ARMv8-A 64位指令集，而开发主机是x86_64，两者的ABI、指令编码、系统调用约定都不同。工具链中的aarch64-linux-gnu-gcc负责把C源码翻译为目标架构汇编，再经汇编器、链接器生成ELF可执行文件；同时它还需要目标平台的glibc或musl库、内核头文件以及正确的--sysroot路径，否则会出现“编译通过但运行段错误”的典型问题。

对于内核模块（如显示驱动、GPU驱动），还必须使用与目标内核完全一致的源码树和.config，否则模块版本魔术数（vermagic）不匹配，insmod会直接拒绝加载。

二、方法流程：四步搭建可调试环境

安装交叉编译工具链：推荐使用Linaro或高通提供的aarch64工具链，并加入PATH。
获取内核源码：从高通CodeAurora或厂商BSP获取与SA8155匹配的msm-4.14/5.4内核树。
配置设备树：在arch/arm64/boot/dts/qcom/下修改对应DTS，描述显示、GPU、I2C等节点。
搭建ADB与串口调试：ADB用于文件传输与shell，串口用于早期启动日志和内核panic捕获。

提示：工具链、内核源码、设备树三者版本必须严格对应。建议用Git子模块或manifest文件锁定版本，避免“今天能编、明天报错”。

三、关键操作与配置示例

工具链安装与环境变量：

# 解压工具链到 /opt
sudo tar -xJf gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt
export PATH=/opt/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin:$PATH
export CROSS_COMPILE=aarch64-none-linux-gnu-
export ARCH=arm64

# 验证
aarch64-none-linux-gnu-gcc -v

内核源码获取与编译：

git clone https://source.codeaurora.org/quic/la/kernel/msm-4.14
cd msm-4.14
make ARCH=arm64 vendor/sa8155_defconfig
make ARCH=arm64 CROSS_COMPILE=$CROSS_COMPILE -j$(nproc)

设备树中显示相关节点的典型片段：

&mdss {
    status = "okay";
    qcom,mdss-has-dsc;
    dsi_0: qcom,dsi-display@0 {
        label = "dsi_panel";
        qcom,dsi-ctrl = <&mdss_dsi0>;
        qcom,dsi-phy = <&mdss_dsi_phy0>;
        qcom,panel-supply-entries = <&dsi_panel_pwr_supply>;
    };
};

ADB与串口调试环境：

# ADB连接（USB或网络）
adb devices
adb shell dmesg | grep -i "msm_drm\|adreno"

# 串口调试（115200 8N1）
sudo minicom -D /dev/ttyUSB0 -b 115200
# 或使用 picocom
picocom -b 115200 /dev/ttyUSB0

四、环境组件对照清单

组件	作用	关键参数/路径	常见问题
交叉工具链	生成ARM64目标代码	aarch64-none-linux-gnu-	sysroot缺失导致链接失败
内核源码	编译内核与模块	msm-4.14 / sa8155_defconfig	版本不匹配vermagic错误
设备树DTS	描述硬件资源	arch/arm64/boot/dts/qcom/	节点status未置okay
ADB	文件传输与shell	adb push/pull/shell	USB权限或驱动未安装
串口	早期日志与panic	/dev/ttyUSB0 115200	波特率或流控配置错误

五、案例场景：显示驱动首次点亮

假设你要验证DPU驱动是否加载成功。典型流程是：先用ADB把编译好的msm_drm.ko推送到/vendor/lib/modules/，然后adb shell insmod加载；同时打开串口终端观察内核日志。如果看到msm_drm: probe success和adreno: zap shader loaded，说明显示与GPU基础链路已通。若串口只输出到Starting kernel...就停止，则问题多半在设备树或bootargs，而不是驱动本身。

建议把串口日志重定向到文件：picocom -b 115200 /dev/ttyUSB0 | tee boot.log，便于后续用grep定位msm_drm、dsi、adreno等关键字。

六、误区与复盘

误区一：工具链越新越好。 内核4.14对高版本GCC兼容性差，建议使用厂商验证过的GCC 10.3或9.3。
误区二：设备树改完不重新编译dtb。 DTS修改后必须make dtbs并替换目标板dtb，否则改动不生效。
误区三：只依赖ADB看日志。 内核早期启动阶段ADB尚未就绪，必须依赖串口。
复盘要点： 每次环境变更后，用uname -a、cat /proc/version、adb shell lsmod三条命令确认内核版本、编译信息和模块加载状态，形成可复现的环境基线。