夜雨聆风从 IDE 插件到 AI Agent，再到全自动化的交叉编译流水线，嵌入式开发早已不是十年前那个"搭环境三天、编译两小时、查错一整天"的苦活。过去三个月，我用一套完全由 AI Agent 辅助搭建的工具链，从头编译了 Hi3519DV500（鸿鸥派开发板）的完整固件——从 Ubuntu 裸机到 249MB 可烧录镜像，6 个自动化脚本全部跑通，期间遇到 9 个坑实时排查修复。
这篇文章完整还原整个过程的每一个细节——从 Ubuntu 24.04 上的基础环境配置，到交叉编译工具链的搭建，再到 BSP、MPP、外设、固件打包的逐层推进，最后以 9 个踩坑记录和完整产物清单收尾。
一、背景：为什么要搭这套工具链
Hi3519DV500 是海思推出的 AI 视觉 SoC，双核 Cortex-A55 + 2.5 TOPS NPU，定位 AI IPC 和智能摄像头场景。鸿鸥派（HongOU PI）是基于该芯片的一个开发板，集成了 OS04A10 摄像头、DDR4 1GB、eMMC 8GB，支持 RTSP 推流和 NPU 推理（YOLOv8/HRNet/MOTR 已验证跑通）。
要在这个平台上做应用开发，第一步就是搭建完整的交叉编译环境——在 x86 的 PC 上生成 ARM64 的可执行文件，然后部署到开发板上运行。
这次搭建的目标非常明确：从零开始，在 Ubuntu 24.04 上搭建完整编译工具链，经过 BSP 编译（U-Boot + Kernel + Rootfs）、MPP 多媒体例程编译、外设驱动编译、PQ 工具编译，最终打包出可烧录的固件镜像。
这个过程完全由 AI Agent（Hermes Agent）辅助完成——从方案设计、脚本编写、坑点排查到文档沉淀，每一个环节都有 AI 参与。
在正式开始之前，先梳理一下研发这台开发板需要用到的所有资料和工具：
参考资料索引：这些资料分散在多个目录中，版本交叉、文档格式各异（有 PDF、TXT、MD）。AI Agent 做的第一件事就是把所有资料整理成一个可执行的方案——这就是整套工具链的起点。
上图是依赖安装完成后的终端输出截图，所有系统包一次性通过。这个结果看似简单，背后却经历了 Ubuntu 24.04 特有的兼容性问题——后面会详细说。
二、整体流程：六个阶段一键跑通
整个编译流程被拆分为 6 个独立的自动化脚本：
这种分阶段的脚本设计不是随意为之。每个阶段都有独立的产物可以验证，任何一步失败都可以单独重跑，不必从头再来。更重要的是——环境变量问题会在阶段切换时自然暴露出来，比如工具链的 PATH 没有持久化，到 BSP 编译阶段就会直接报错，马上就能定位到问题。
整体耗时： 从 Ubuntu 裸机到拿到完整固件，全流程大约 45 分钟（包含网络下载时间）。中间产物占约 8-10GB 磁盘。这个速度比手动的 2-3 天大幅缩短，核心原因是 AI Agent 在每次遇到错误时都能秒级检索相关文档和手册，而不是靠人工翻阅 PDF 来找原因。 磁盘占用详细估算：| 总计 | ~8-10GB |
从这张表可以看出，SDK 源码解压后占了将近一半的空间。编译完成之后可以删除 tar.gz 压缩包释放 1.2GB，后续按需保留源码或直接保留编译产物即可。
三、关键决策：为什么选适配版 SDK
海思 SDK 有两个来源。一个是原厂 SDK（约 8GB，在 /yolo/08 目录），需要自行打补丁适配鸿鸥派硬件；另一个是适配后的 SDK（由板卡厂商提供，在 /yolo/06/02 目录），已经针对鸿鸥派做了 BSP、驱动和配置的适配。
选择了适配版本，核心原因是减少移植工作量：make EBAINA_BOARD=38C LIB_TYPE=glibc CHIP=hi3519dv500 all | ||
适配后 SDK 的说明文件明确说：该 SDK 未对 MPP Sample 适配。BSP 部分可以一键编译，但 MPP 多媒体例程需要额外下载独立包来编译。这个包约 58MB，需要单独解压后交叉编译。
另一个需要留意的地方：适配后的 SDK 精简掉了海思原厂自带的 installed_package_check.sh 依赖检查脚本。这说明不能假设官方 SDK 有的东西这里一定有。替代方案是自写了一个 check_deps.sh，覆盖 9 大类 36 项检查。
四、第一阶段：基础编译环境搭建
这是整套流程的地基，也是最容易出问题的一步。Ubuntu 24.04 与海思 SDK 之间的兼容性差异在这里集中爆发。
4.1 系统依赖安装
海思官方的编译指导手册基于 Ubuntu 18.04 / 20.04 编写，很多包名和配置方式在 24.04 上已经有了变化。
安装命令如下：text
sudo apt-get install -y make libc6-i386 lib32z1 lib32stdc++6 \ libncurses5-dev ncurses-term g++ u-boot-tools \ texinfo gawk libssl-dev openssl bc p7zip-full gperf bison flex \ diffutils git unzip libffi-dev libtool libfreetype6 fakeroot \ autopoint po4a zlib1g-dev liblzo2-dev uuid-dev \ pkg-config automake openssh-server nfs-kernel-server rpcbind net-tools
然后是用 pip 安装 Python 依赖包：
text
sudo pip3 install --break-system-packages --ignore-installed \ -i https://pypi.tuna.tsinghua.edu.cn/simple \ wheel==0.36.2 pycryptodome==3.9.8 pyelftools==0.27 kconfiglib
各依赖包的用途速查：
上图是交叉编译工具链安装完成后的验证结果，aarch64-linux-gnu-gcc 版本 10.3.0，一切正常。
4.2 安装交叉编译工具链
交叉编译工具链是嵌入式开发的灵魂。在 x86 上编译出 ARM64 的机器码，全靠这套工具。
资料提供两套工具链——glibc 版本（97MB，动态链接，推荐）和 musl 版本（83MB，静态链接）。选择 glibc 版本，因为绝大多数应用程序和库都基于 glibc，兼容性更好。
安装步骤：text
cp "/.../01.交叉编译工具/gcc-20240819-aarch64-v01c01-linux-gnu.tgz" /tmp/cd /tmptar -xf gcc-20240819-aarch64-v01c01-linux-gnu.tgzcd gcc-20240819-aarch64-v01c01-linux-gnu/sudo ./install_gcc_toolchain.shsource /etc/profileaarch64-linux-gnu-gcc --version
安装脚本完成之后，还需要将环境变量写入 ~/.bashrc 持久化：
text
cat >> ~/.bashrc << 'EOF'export CROSS_COMPILE=aarch64-linux-gnu-export ARCH=arm64EOFsource ~/.bashrc
注意： 02 脚本只写了 CROSS_COMPILE 和 ARCH，漏掉了 PATH 变量。这是过程中踩到的坑之一。新终端打开后 aarch64-linux-gnu-gcc --version 会提示找不到命令，就是因为 PATH 没有持久化。4.3 复制并解压 SDK 源码
SDK 源码在共享目录下，解压和编译必须在本地文件系统进行。
text
mkdir -p ~/hisi/hi3519dv500cp ".../Hi3519DV500_SDK_V2.0.2.0.tar.gz" ~/hisi/cd ~/hisitar -xzf Hi3519DV500_SDK_V2.0.2.0.tar.gz
解压后的 SDK 目录结构如下：
text
~/hisi/Hi3519DV500_SDK_V2.0.2.0/└── smp/a55_linux/source/bsp/ ├── uboot/ U-Boot 源码 ├── kernel/ Linux Kernel 源码 ├── rootfs/ 根文件系统配置 ├── drivers/ 板级驱动 └── pub/ 编译产物目录
SDK 解压完成后，用自写的 check_deps.sh 跑一遍依赖检查，全部 36 项一次性通过。
五、第二阶段：BSP 全编译
BSP（Board Support Package）包含了嵌入式 Linux 的三大核心组件：U-Boot（bootloader）、Kernel（内核）、Rootfs（文件系统）。海思 SDK 的 make all 可以一键编译三者，这是整套编译方案的核心。
5.1 全量编译命令
text
cd ~/hisi/Hi3519DV500_SDK_V2.0.2.0/smp/a55_linux/source/bspmake EBAINA_BOARD=38C LIB_TYPE=glibc CHIP=hi3519dv500 all
三个编译参数说明：BSP 的 make all 实际上依次编译了 bootloader → kernel → rootfs → dtb，是一键三连。整个过程大约 20 分钟（在 4 核虚拟机上），不需要人工干预。
5.2 编译产物验证
编译成功后的产物在 bsp/pub/ 目录下：
编译过程中没有报错，全部一次性通过。这是整套流程中最关键的一步——有了这三样东西，板子就能跑起来了。
六、MPP Sample：多媒体例程编译
MPP（Media Process Platform）是海思的多媒体处理框架，涵盖了视频输入（VI）、编码（VENC）、解码（VDEC）、视频处理（VPSS）等全部流水线。这个步骤独立于 BSP 编译，因为适配后 SDK 明确说了 MPP Sample 需要单独编译。
6.1 解压并编译
text
cd ~/hisi/hi3519dv500tar -xzf ".../Hi3519DV500_SDK_V2.0.2.0_MPP_Sample-main.tar.gz"cd Hi3519DV500_SDK_V2.0.2.0_MPP_Sample-main/srcmake ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
踩坑提示： MPP Sample 包的 Makefile 不在顶层，在 src/ 子目录下。直接在最外层执行 make 会提示找不到目标。编译脚本改为 cd "$MPP_DIR/src" 即可解决。6.2 MPP Sample 包含的例程
编译完成后产出了 49 个 ARM64 ELF 可执行文件：
其中 NPU 推理的三个应用（YOLOv8、HRNet、MOTR）已在开发板上验证跑通。RTSP 推流使用 sample_venc，推流地址统一为 live0。
七、外设驱动与 PQ 工具
7.1 外设驱动和例程
两个独立的包需要分别解压编译：
编译命令统一为 make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-。外设驱动编译可能依赖完整 BSP 内核头文件，需先完成第二阶段 BSP 编译。
外设例程编译完成后，产出的文件可以直接通过 scp 部署到开发板上运行测试：
text
scp hi_pwm_sample root@192.168.1.168:/tmp/ssh root@192.168.1.168 /tmp/hi_pwm_sample
驱动开发标准流程：编写驱动源文件 xx_drv.c → 添加到内核源码 drivers/ 相应目录 → 修改 Kconfig 和 Makefile → 执行 make menuconfig 选择该驱动 → 编译内核或模块 → scp 或 NFS 部署到开发板 → 板端测试调试。每个环节都有对应的 Makefile 目标和检查方法。
驱动开发覆盖的外设类型：7.2 PQ 工具编译
PQ（Picture Quality）工具用于图像质量调试和 Sensor 参数调优。针对鸿鸥派的 I2C 编号做了适配，确保 Sensor 正常通信。
text
cd ~/hisi/hi3519dv500tar -xzf ".../PQ-main.tar.gz"cd PQ-mainmake ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
使用方式：用 sample_vio 等例程出图时，运行 ./StartControl.sh 开启 control 进程。
八、固件打包——249MB 完整镜像
这是整套编译流程的终点——把之前编译好的所有组件打包成一个可以烧录到开发板的固件镜像。
8.1 固件打包工程
海思提供了专门的固件打包工程，支持多板卡参数化配置。
text
cd ~/hisi/hi3519dv500tar -xzf ".../Hi3519DV500_Firmware_Building-main.tar.gz"cd Hi3519DV500_Firmware_Building-main
踩坑提示： 打包脚本 Generate_Image_Hi3519DV500.sh 需要参数才能正常工作，直接执行只会打印帮助信息。正确的执行方式分两步：先从 BSP 编译产物目录拷贝 uImage-fdt、bl31.bin 等文件到打包工程；然后用 -b 板卡名 -g 参数指定目标板卡型号。鸿鸥派 38C + Hi3519DV500 对应的板卡参数是 HongouPI_38C_19DV500。
8.2 固件产物清单
最终产出的可烧录镜像包含以下文件：
| 总计 | ~249MB | 完整可烧录镜像 |
九、AI Agent 参与的 9 个坑
这是整个过程中最有价值的部分。Ubuntu 24.04 在海思 SDK 的官方文档中不是推荐系统，所以各种兼容性问题集中爆发。AI Agent 在其中的作用是加速排查过程——每个坑出现后搜索相关资料、对比不同方案、测试修复结果。
坑 1：Ubuntu 24.04 pip3 安装 wheel 冲突
现象： pip3 install wheel==0.36.2 报错 ERROR: Cannot uninstall wheel 0.42.0, RECORD file not found。 原因： Ubuntu 24.04 通过 deb 包管理器安装了 wheel 0.42.0，pip 尝试卸载旧版本时找不到 RECORD 文件。 解决： 使用 --break-system-packages --ignore-installed 双标志跳过卸载步骤。这是 Ubuntu 24.04 PEP 668 保护策略导致的。坑 2：libncursesw5-dev 在 Ubuntu 24.04 不存在
现象： apt install libncursesw5-dev 报找不到包。 原因： Ubuntu 24.04 中 wide-char ncurses 已合并进 libncurses-dev，独立包名已废弃。 解决： 从依赖列表中删除 libncursesw5-dev，只保留 libncurses-dev。坑 3：lzop 和 device-tree-compiler 漏装
现象： 内核编译时提示缺少 lzop 或 dtc 命令。 原因： 原始依赖列表遗漏了这两个内核编译必需的工具。 解决： 补充到 01_install_deps.sh 的 apt 安装列表中。坑 4：installed_package_check.sh 不存在
现象： 执行 SDK 自带的依赖检查脚本时提示文件不存在。 原因： 该脚本来自海思原厂 SDK 的第七步，适配后的版本被精简掉了。 解决： 自写 check_deps.sh，覆盖 9 大类 36 项检查。坑 5：pycryptodome 的导入名不是 Cryptodome
现象： python3 -c "import Cryptodome" 失败，但 pip3 list 显示已安装。 原因： pycryptodome 包的 Python 导入名是 Crypto，不是包名本身。包名是 pycryptodome，但代码里必须写 import Crypto。 解决： 检查所有脚本，确保使用正确的导入名 Crypto。坑 6：工具链 PATH 未写入 bashrc
现象： 在新终端中运行 aarch64-linux-gnu-gcc --version 提示找不到命令。 原因： 02 脚本只把 CROSS_COMPILE 和 ARCH 写入了 bashrc，漏掉了 PATH 变量。 解决： 手动向 ~/.bashrc 追加 PATH 定义。坑 7：MPP Sample 的 Makefile 不在顶层
现象： 在 MPP Sample 包目录下执行 make 提示找不到目标。 原因： MPP Sample 包的顶层目录没有 Makefile，Makefile 在 src/ 子目录下。 解决： 编译脚本改为 cd "$MPP_DIR/src"。坑 8：固件打包脚本需要参数才能工作
现象： 直接执行 Generate_Image_Hi3519DV500.sh 无效果，只打印帮助信息。 原因： 该脚本设计为多板卡通用，支持通过参数指定目标板卡型号。 解决： 查看 README 后执行 bash Generate_Image_Hi3519DV500.sh -b HongouPI_38C_19DV500 -g。坑 9：Python venv 环境干扰 pip 检查
现象： check_deps.sh 用 python3 -c "import xxx" 检查包时失败，但系统里已安装。 原因： 当前环境中 python3 指向 AI Agent 的 venv Python，而非系统 Python。 解决： 检查脚本改用 /usr/bin/python3 直接调用系统 Python。十、check_deps.sh——自写 36 项依赖检查
适配后的 SDK 没有自带依赖检查，自写了一个覆盖完整的检查脚本：
每个检查项都有通过/失败的状态输出。有了这个脚本，每次切换环境时只需要跑一次就能知道编译环境是否完整。
十一、经验总结
11.1 适配版本不等于完整版本
适配后的 SDK 并不等于原厂 SDK 的增强版。它在某些地方做了定制，但也删减了一些辅助脚本和文档。不能假设官方 SDK 有的脚本这里也有——先核实再动工是最稳妥的做法。
11.2 脚本分阶段比巨型脚本好十倍
6 个独立脚本比 1 个巨无霸脚本好太多。每步产物可以独立验证，失败不用从头开始；环境变量问题在阶段切换时自然暴露；用户也可以跳过已经完成的步骤。
11.3 Ubuntu 24.04 与嵌入式 SDK 的兼容性是最大变量
大部分海思官方文档基于 Ubuntu 18.04/20.04 编写。在 24.04 上会遇到 PIP 保护策略、包名变更、默认 Python 版本差异等问题。9 个坑中至少有 5 个直接或间接与 OS 版本兼容性有关。
11.4 先读说明再编译
很多坑其实可以通过先看 README 来避免——MPP Sample 的 Makefile 位置、固件打包脚本的参数要求、适配后 SDK 缺少检查脚本。工程师的直觉是先跑再说，但在嵌入式领域最好先读再跑。
11.5 AI Agent 的四种角色
方案设计师——分析不同 SDK 版本优劣，推荐适配版而非原厂版
脚本工程师——把 10 个编译阶段写成 6 个独立脚本，处理边界条件
排查助手——遇到报错时快速检索相关资料、对比不同方案
文档记录员——每次踩坑都记录下来，形成可复用的知识
四个角色的配合，把原本需要 2-3 天的工作量压缩到了 45 分钟的全自动流程。
11.6 日常开发工作流建议
拿到完整固件和编译环境后，日常开发的推荐工作流如下：
编辑代码 → 交叉编译 → 部署到开发板 → 板端测试 → 调试反馈text
编辑代码 (VS Code / Vim) ↓交叉编译 (aarch64-linux-gnu-gcc) ↓部署到开发板 (scp 或 NFS 挂载) ↓板端运行测试 (SSH 远程执行) ↓调试反馈 (日志分析 / GDB) ↑_________________|
这种循环模式是嵌入式开发的标配。SCP 适合单文件部署（秒级），NFS 挂载适合开发阶段的持续调试（修改即生效，无需反复拷贝）。推荐的做法是：开发阶段用 NFS 挂载整个编译输出目录，调试通过后再用 SCP 部署到最终的 eMMC 分区上。这样可以最大化迭代效率，同时保证最终部署的稳定可靠。
CMake 交叉编译工具链配置：创建一个 toolchain.cmake 文件，可以复用给所有 CMake 项目：
text
SET(CMAKE_SYSTEM_NAME Linux)SET(CMAKE_SYSTEM_PROCESSOR aarch64)SET(CMAKE_C_COMPILER aarch64-linux-gnu-gcc)SET(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++)SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
使用方式：在项目目录中 mkdir build && cd build，执行 cmake ... -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake 然后 make 即可。
11.7 应用层技术栈推荐
这些方案都经过了交叉编译验证，可以直接在开发板上运行。
十二、总结
从 Ubuntu 24.04 裸机到 249MB 可烧录镜像，总共耗时约 45 分钟，经历 9 个坑的排查修复，最终产出 6 个自动化脚本 + 1 个 check_deps 依赖检查工具。
这套工具链的核心能力： 任何一台 Ubuntu 24.04 x86_64 机器，跑一遍这 6 个脚本，就能获得一个完整的 Hi3519DV500 开发环境——从 BSP 编译到固件打包全自动完成。而 AI Agent 在这个过程中展示的能力，不仅仅是写脚本和踩坑——更重要的是把经验沉淀为可复用的资产。9 个坑的记录、check_deps 脚本、6 阶段流水线设计，这些都是下一次启动时可以直接复用的知识。
关注「AI的探索之旅」，你将获得：
→ [Hi3519DV500 嵌入式开发全攻略：从环境搭建到固件打包一站式指南] → [AI ISP vs 传统 ISP：海思芯片的图像处理到底强在哪？] → [AI Agent 接管飞书调试开发板：让智能体帮你跑命令、查参数、修配置]
*实践出真知。*
👇 长按识别关注，不错过每一篇干货📌 版权所有 © AI的探索之旅 | 转载请联系作者