做嵌入式Linux开发这些年我经手的海思平台一只手数不过来从早期的Hi3516A、Hi3516EV300一直到最近手里的Hi3516CV610。每一颗新片子拿到手最让我头疼的往往不是写业务代码而是先把SDK编译环境和交叉编译工具链跑通——这是所有开发工作的前置条件也是新人最容易卡住的地方。这两天正好在给一块Hi3516CV610的开发板从零构建海思SDK编译环境踩了不少坑也把工具链部署的完整流程重新捋了一遍。这篇文章就把整个过程写下来包括系统选型、依赖安装、SDK解包、交叉工具链部署、首次编译以及链接阶段的排错思路给后面要上车的人当一份实操参考。1. 先认清手里的SDK包和芯片型号再动手1.1 SDK包命名与CV610的实际对应关系拿到Hi3516CV610的资料包以后第一步不是急着解压而是先确认你手里的SDK包和这颗芯片是不是配套。海思的SDK包命名有时候会绕一下常见的有Hi3516CV610_SDK_Vx.x.x.x.tgz但也有可能你从代理商手里拿到的是同平台系列的其他前缀。我之前就遇到过拿错包的情况压缩包版本比芯片批次旧里面的DDR配置和默认设备树型号对不上编译出来的内核在板子上怎么起都起不来。CV610这颗芯片的定位是轻量级AI视觉SoC常见于IPC、AIoT边缘设备集成ISP、视频编解码和轻量NPU。它的SDK包解压出来不是单一工程而是把u-boot、kernel、rootfs、媒体驱动、示例代码全部聚合在一起的大集合。所以后面所有操作都需要围绕这套SDK的结构来不能拿着通用Linux开发思路硬套。1.2 SDK一级目录是理解整个构建流程的入口我手里这份SDK解压后一级目录大致如下不同批次会有一点差异但核心结构基本类似目录/文件作用doc芯片手册、SDK使用指南、FAQ务必最先看osdrvu-boot、kernel、rootfs三大件构建入口核心目录msp媒体处理平台库、头文件和部分sampledrv外设驱动、平台相关源码tools烧录工具、调试工具、toolchain安装包所在地platform芯片型号、DDR颗粒、管脚配置等板级配置smp安全特性与多核相关示例按需使用一开始我习惯性地直接去找编译脚本结果在根目录ls了一圈没看到明显的build.sh后来才发现真正的入口在osdrv目录下。SDK里那些脚本之间互相引用路径关系比较绕所以建议先花20分钟把doc里的《SDK使用指南》翻一遍尤其是目录结构和编译流程两章比瞎试命令有效率得多。1.3 编译主机的硬件底线编译环境不是随便找台机器就能舒服跑的。合入SDK、编译内核和rootfs时中间产物非常多。我的建议配置是CPU至少4核8核体验较好全量编译能省不少时间内存16GB比较稳8GB也能跑但并行任务要调低磁盘空闲空间至少60GB解压加编译很容易吃掉30GB以上系统Ubuntu 18.04.x是最省事的选项后面专门讲如果你是拿虚拟机做记得给磁盘预分配足够大小别用动态扩展到后面磁盘吃紧编译到一半报No space left on device是最折磨人的。2. Ubuntu版本先选对18.04是省心选择但不是唯一出路2.1 为什么海思SDK多数推荐Ubuntu 18.04海思SDK里大量构建脚本都是基于Ubuntu 18.04验证过的尤其是osdrv里那套内核和u-boot构建流程对宿主机的make、perl、python版本有隐性依赖。18.04自带的是GCC 7.5、make 4.2.1、perl 5.26刚好在海思工具链团队当时的验证范围内。很多新人容易忽略一件事交叉编译工具链本身虽然不依赖宿主机编译器版本但SDK的构建流程里混杂着宿主机编译步骤比如编译mkimage、dtc这类host工具生成设备树打包rootfs时调用一些perl脚本。这些环节只要宿主机组件版本偏差太大就会出现莫名其妙的报错。2.2 20.04和22.04实测会碰到什么问题系统版本主要表现结论Ubuntu 18.04.x官方验证充分old库齐全脚本能跑通首选Ubuntu 20.04缺少libncurses5部分脚本中python2调用失败make行为变化能跑但费时间Ubuntu 22.04上述问题加剧host工具依赖更容易缺失不推荐实际在20.04上最直观的问题就是apt install libncurses5-dev直接提示找不到包。内核menuconfig和编译rootfs里的busybox都会用到ncurses库缺了就得手动找deb包装上去。还有一些SDK自带脚本里写死了python命令但20.04默认只有python3你还需要手动做个软链。这些不是不能解决但要一个个补对只想快速跑通环境的人来说就是劝退。2.3 手边只有新版本系统怎么办如果你的电脑已经装了22.04或更新版本我建议直接用虚拟机装一个18.04镜像。不要想着在22.04里硬刚时间成本不值。用VirtualBox或VMware都行把CPU核数和内存给足编译速度损失不大。还有个方案是Docker镜像把18.04装成容器映射SDK目录进去编译。这个方案适合团队统一构建环境但第一次配置Dockerfile也有一点成本。我个人的建议是个人开发就用虚拟机简单直接团队开发就做Docker镜像保证大家环境一致。3. 装系统、换源、补依赖搭建可用编译主机的完整操作3.1 最小化安装Ubuntu 18.04如果你决定用虚拟机安装Ubuntu 18.04 Desktop时选择“最小安装”可以省掉LibreOffice等用不到的大件。如果不想装桌面直接装Server版本也行。SDK编译走命令行只要有终端就够。安装完成后第一件事是更新软件源。18.04的默认源是archive.ubuntu.com在国内速度不稳定我会习惯性切成可用镜像。修改/etc/apt/sources.list把archive.ubuntu.com替换成mirrors.aliyun.com或者你本地网络访问稳定的镜像源都可以。sudo sed -i s/archive.ubuntu.com/mirrors.aliyun.com/g /etc/apt/sources.list sudo apt update3.2 安装编译依赖一个都不能少海思SDK编译需要的基础依赖包如下我每次装完新环境都会跑一遍sudo apt install -y build-essential git flex bison bc u-boot-tools \ device-tree-compiler libncurses5-dev libssl-dev zlib1g-dev pkg-config这几个包分别干什么简单拆一下build-essential提供宿主机GCC和makehost工具编译要用flex bison内核和u-boot配置阶段的词法/语法解析器bc内核构建菜单里会调用少了会报“bc not found”u-boot-tools提供mkimage制作uImage必需device-tree-compiler编译设备树.dtb必需libncurses5-devmenuconfig界面依赖libssl-dev内核签名和相关模块编译依赖zlib1g-dev pkg-config部分host工具链接时必需的库这些包在18.04上都能直接装上。如果你选的不是18.04在这步就会开始感受到痛苦尤其是libncurses5-dev20.04之后彻底没了只能手动装老deb。3.3 用户、目录和权限规划我建议编译工作使用普通用户不要用root。海思SDK部分检查脚本对root环境会有警告而且万一脚本里有个rm -rf写得不严谨普通用户至少还能拦住一部分。目录规划方面我习惯把SDK放在~/work/sdk下面工具链安装路径由安装脚本默认放/opt/hisi-linux路径比较深但不用改改了反而容易出问题。sudo mkdir -p /opt/hisi-linux sudo chown -R $USER:$USER /opt/hisi-linux把/opt/hisi-linux所有者改成当前用户后续安装和调用工具链都不用反复sudo省心很多。4. 解包SDK与交叉工具链部署看着简单实际容易踩坑4.1 校验文件和解压拿到SDK压缩包先不要急着一键解压。海思SDK包比较大传输过程中文件损坏是常有的事。我一般先看一下有没有md5sum.txt之类的校验文件md5sum -c md5sum.txt校验通过后解压到工作目录mkdir -p ~/work/sdk tar xzf Hi3516CV610_SDK_Vx.x.x.x.tgz -C ~/work/sdk解压完成后别急着进目录乱转先看doc下面有没有《ReleaseNote》或《SDK使用指南》。不同批次的SDK在编译入口、默认配置上会有细节差异文档里通常会写明“快速开始”步骤。4.2 安装交叉编译工具链工具链安装包一般在SDK的tools目录可能是一个cross.install脚本加一个.tgz压缩包。我手里这份的工具链前缀是arm-mix410-linux-gnueabihf也有其他批次用不同前缀以你实际安装出来的为准。安装方式很直接cd tools chmod x cross.install sudo ./cross.install这里有个看起来特别像“卡死”的坑安装脚本在sudo环境下执行时终端的输出缓冲可能不刷新屏幕上什么都没显示你以为是死机了实际上脚本正在等你在License提示处输入y回车。我第一次装的时候等了三分钟没反应差点CtrlC后来旁边同事提醒说按个y试试果然就过了。安装脚本默认会把工具链放到/opt/hisi-linux/x86-arm/arm-mix410-linux-gnueabihf/目录结构大概是/opt/hisi-linux/x86-arm/arm-mix410-linux-gnueabihf/ ├── bin ├── lib ├── libexec ├── sysroot └── ...其中sysroot就是交叉编译时的根文件系统工具链找头文件和库都是在这个目录下找默认/opt/hisi-linux/x86-arm/arm-mix410-linux-gnueabihf/sysroot。4.3 PATH环境变量设置工具链装好之后需要把bin目录加进PATH编译时才能直接敲arm-mix410-linux-gnueabihf-gcc。我习惯在当前项目的env.sh里写而不是改全局/etc/profileexport PATH/opt/hisi-linux/x86-arm/arm-mix410-linux-gnueabihf/bin:$PATH export ARCHarm export CROSS_COMPILEarm-mix410-linux-gnueabihf-每次开新终端就source env.sh。验证工具链是否生效arm-mix410-linux-gnueabihf-gcc -v输出里能看到gcc version和Target: arm-...-linux-gnueabihf基本就说明工具链部署成功了。4.4 两套工具链同时存在时别用错海思SDK有时候会同时提供glibc和uclibc两套工具链还有可能你在同一台机器上同时开发多个平台装了不同版本的交叉工具链。这时候最忌讳把所有工具链的bin目录全部写进全局PATH编译器前缀一旦重复链接阶段会用到完全错误的库。我的经验是一个终端会话只绑定一套工具链开另一个项目前先source对应的env.sh。如果选择了glibc版本的SDK就只用glibc工具链编译应用uclibc工具链编译出来的程序链接库不匹配放在板子上大概率跑不起来。5. 第一次完整编译脚本入口、编译顺序与产物位置5.1 先找到真正的构建入口不同批次的海思SDK顶层构建入口不完全一样。有的在根目录放了一个build.sh有的则在osdrv目录里通过Makefile来组织。我这次用的SDK构建入口在osdrv目录下进入后执行cd osdrv make all第一次跑全量编译前最好先看一下osdrv/Makefile开头部分的配置选项通常会通过变量指定芯片型号、DDR型号、flash类型等。脚本可能会进入字符交互界面让你选择板卡配置按你手上开发板的实际型号选。5.2 全量编译的流程和耗时执行make all后系统会先做依赖检查和环境校验然后按顺序编译u-boot、kernel、rootfs最后打包成镜像。大致流程如下环境检查工具链路径、host依赖是否齐全解压并打补丁把内核、u-boot源码展开到out目录编译u-boot生成bootloader镜像编译内核生成uImage和dtb编译rootfs通过busybox构建根文件系统打包生成各分区镜像和整包升级镜像在8核16GB的虚拟机上全量编译一次大概需要一个半小时到两个小时。如果机器配置低时间还会拉长。第一次编译失败很正常耐心看日志大多数失败原因都在缺host依赖上补上依赖后重新执行即可。5.3 编译产物在哪个目录编译完成后镜像产物一般在SDK的out目录下按子目录分类存放。常见路径大致是产物位置示例用途u-boot镜像out/boot/烧录到boot分区内核与dtbout/kernel/烧录到kernel分区根文件系统out/rootfs/烧录到rootfs分区整包升级镜像out/下形如*_upgrade.img用烧录工具一键烧写注意不同SDK版本对out目录的命名可能略有差异最靠谱的方式是编译结束后看终端输出的“Image”路径提示或者用find out -name *.img全局搜一下。5.4 建议先单独编一次内核别上来就全量全量编译的耗时长出现问题后排查链路也长。我个人的习惯是第一次不要直接跑全量先单独验证内核链路把环境问题提前暴露出来。在osdrv目录下通常支持单独编译某个组件make kernel如果内核能顺利编译通过说明工具链和大部分host依赖都没问题再回头跑全量编译基本就是顺水推舟。单独编内核还有一个好处就是后面你在调试设备树、裁剪内核配置时不用每次等rootfs一起编。6. 链接阶段报错排查遇到cannot find -lxxx时我在做什么6.1 三步定位“找不到库”问题交叉编译应用时最常遇到的链接报错是cannot find -lmpp cannot find -lpthread看到这种报错我会按顺序做三件事而不是盲目加-L参数第一步确认库文件是否存在于工具链的sysroot或SDK的库目录里find /opt/hisi-linux -name libmpp* find ~/work/sdk -name libmpp*第二步确认工具链默认搜索路径arm-mix410-linux-gnueabihf-gcc -print-sysroot第三步在编译命令里通过-L显式指定库目录。海思SDK的media库通常编译后输出在msp/out一类的路径下编译sample时如果提示找不到库多半就是-L没指到正确位置。6.2 程序在板子上报“No such file or directory”的真正原因用交叉工具链编出一个可执行程序后放到开发板上执行如果出现./hello: line 1: ./hello: cannot execute binary file或者./hello: No such file or directory第一反应不应该是“文件没拷过去”。很多时候文件确实在但动态链接器的路径不对。用readelf看一下readelf -l hello | grep interpreter输出通常会显示类似[Requesting program interpreter: /lib/ld-linux-armhf.so.3]如果这套rootfs里动态链接器路径不是这里或者rootfs里压根没有这个文件就会出现“No such file or directory”。这个报错很迷惑人因为它不是“file not found”而是“加载器not found”。排查方向对了问题一下就解决了。6.3 头文件找不到时先确认内核头文件有没有导出编译应用或内核模块时提示某个内核头文件找不到比如linux/xxx.h很多人会直接把-I指向内核源码目录。但内核源码里很多头文件是编译过程中动态生成的直接指过去往往还是缺。海思SDK里通常有专门的命令导出内核头文件编译一次内核后out目录下会生成一份对外可用的头文件集合。我的做法是先确认内核单独编译过一次再用find out -name generated定位导出的头文件路径最后在应用编译脚本里把-I指到对应位置。顺序不能反否则就是白费功夫。6.4 别让LD_LIBRARY_PATH污染交叉编译环境交叉编译环境最容易被搞乱的操作就是把宿主机上的LD_LIBRARY_PATH一股脑引入。宿主机上的libc版本和工具链sysroot里的完全不是一回事一旦环境变量里混入了x86的库路径链接时就会出现各种符号不匹配的诡异报错。保持一个干净的环境变量集合很重要。我通常会在env.sh里显式unset LD_LIBRARY_PATH避免继承宿主机环境unset LD_LIBRARY_PATH export PATH/opt/hisi-linux/x86-arm/arm-mix410-linux-gnueabihf/bin:$PATH export ARCHarm export CROSS_COMPILEarm-mix410-linux-gnueabihf-这样每次编译前都会有一个全新的、只含目标工具链的环境。6.5 最终经验一个项目一个env.sh最后分享一个我后来一直沿用的习惯不管做哪个海思平台我都会在项目根目录放一个独立的env.sh里面只export当前项目需要的PATH、ARCH、CROSS_COMPILE并且unset掉LD_LIBRARY_PATH。每次开新终端先source它。别图省事把所有交叉工具链一股脑塞进全局PATH否则哪一天你同时碰两个平台时编译器版本和库路径错乱带来的“莫名链接不过”会让你从头排查到崩溃。环境这个事情前期多花十分钟规范一点后面省下的就是几个小时起步的排错时间。