企业官网建设流程全解析

做嵌入式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解压后，一级目录大致如下，不同批次会有一点差异，但核心结构基本类似：

一开始我习惯性地直接去找编译脚本，结果在根目录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实测会碰到什么问题

实际在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 update

3.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和make，host工具编译要用
• flex bison：内核和u-boot配置阶段的词法/语法解析器
• bc：内核构建菜单里会调用，少了会报“bc not found”
• u-boot-tools：提供mkimage，制作uImage必需
• device-tree-compiler：编译设备树.dtb必需
• libncurses5-dev：menuconfig界面依赖
• libssl-dev：内核签名和相关模块编译依赖
• zlib1g-dev pkg-config：部分host工具链接时必需的库

这些包在18.04上都能直接装上。如果你选的不是18.04，在这步就会开始感受到痛苦，尤其是libncurses5-dev，20.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回车。我第一次装的时候等了三分钟没反应，差点Ctrl+C，后来旁边同事提醒说按个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/profile：

export PATH=/opt/hisi-linux/x86-arm/arm-mix410-linux-gnueabihf/bin:$PATH export ARCH=arm export CROSS_COMPILE=arm-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，最后打包成镜像。大致流程如下：

1. 环境检查：工具链路径、host依赖是否齐全
2. 解压并打补丁：把内核、u-boot源码展开到out目录
3. 编译u-boot：生成bootloader镜像
4. 编译内核：生成uImage和dtb
5. 编译rootfs：通过busybox构建根文件系统
6. 打包：生成各分区镜像和整包升级镜像

在8核16GB的虚拟机上，全量编译一次大概需要一个半小时到两个小时。如果机器配置低，时间还会拉长。第一次编译失败很正常，耐心看日志，大多数失败原因都在缺host依赖上，补上依赖后重新执行即可。

5.3 编译产物在哪个目录

编译完成后，镜像产物一般在SDK的out目录下，按子目录分类存放。常见路径大致是：

注意，不同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 ARCH=arm export CROSS_COMPILE=arm-mix410-linux-gnueabihf-

这样每次编译前都会有一个全新的、只含目标工具链的环境。

6.5 最终经验：一个项目一个env.sh

最后分享一个我后来一直沿用的习惯：不管做哪个海思平台，我都会在项目根目录放一个独立的env.sh，里面只export当前项目需要的PATH、ARCH、CROSS_COMPILE，并且unset掉LD_LIBRARY_PATH。每次开新终端先source它。别图省事把所有交叉工具链一股脑塞进全局PATH，否则哪一天你同时碰两个平台时，编译器版本和库路径错乱带来的“莫名链接不过”，会让你从头排查到崩溃。环境这个事情，前期多花十分钟规范一点，后面省下的就是几个小时起步的排错时间。