4、驱动安装准备：下载驱动包、校验文件完整性、安装依赖工具（gcc、make、dkms等）

BM1684作为算能科技推出的高性能AI推理芯片，其驱动安装是整个环境搭建链条中的第一块基石。驱动层负责管理芯片的PCIe通信、DMA传输、中断处理以及设备节点映射，若驱动安装不当，后续的SDK编译、Docker容器调用乃至模型推理都将无从谈起。本章节聚焦于驱动安装前的三大核心准备动作：获取正确的驱动包、验证文件完整性、以及构建编译驱动所需的系统工具链。这三步看似基础，却直接决定了驱动能否在目标机器上一次性编译通过并稳定加载。

上图清晰地展示了驱动安装准备阶段的三个并行且递进的环节。在实际操作中，这三个环节并非完全孤立，例如工具链的版本会影响驱动包的编译选项，而驱动包的完整性校验失败则意味着需要重新下载。下面我们将逐一深入每个环节的具体操作与判断标准。

4.1 核心原理：为什么驱动准备如此重要

BM1684驱动本质上是一组与Linux内核交互的模块（通常为bmdrv.ko、bmcdev.ko等），它们运行在内核态，负责将用户态程序（如SDK中的bmrt库）的请求转换为对芯片寄存器的读写操作。驱动模块的编译必须与当前运行的内核版本严格对应，因为内核的API（如copy_to_user、pci_register_driver）在不同版本间存在差异。因此，驱动包中通常包含源码，需要在目标机器上通过dkms或直接make编译生成与当前内核匹配的.ko文件。

驱动安装失败的常见原因中，超过60%源于准备阶段疏忽：下载了错误的驱动版本、文件在传输过程中损坏、或者缺少编译所需的gcc与内核头文件。理解这一点，就能明白为何要在安装前投入精力进行系统性的准备。

4.2 操作流程：从下载到校验的完整步骤

4.2.1 驱动包获取与版本匹配

首先，需要从算能科技官方渠道（如GitHub Releases、官方FTP或百度网盘）获取与目标硬件平台（如SC5、SM5模组）及操作系统（Ubuntu 18.04/20.04、CentOS 7/8等）匹配的驱动包。驱动包命名通常包含版本号与内核标识，例如BMNNSDK-4.7.0-driver-6.2.0-ubuntu20.04-x86_64.tar.gz。

下载完成后，建议将驱动包放置于/opt或/root目录下，避免路径中包含中文或空格。使用tar -xzf解压后，检查目录结构是否包含install.sh、src、dkms.conf等关键文件。

4.2.2 文件完整性校验

网络传输或存储介质问题可能导致文件损坏，而损坏的驱动包在编译时会抛出莫名其妙的语法错误或段错误。因此，必须进行完整性校验。官方发布页面通常会提供MD5或SHA256校验值。

# 计算下载文件的MD5值
md5sum BMNNSDK-4.7.0-driver-6.2.0-ubuntu20.04-x86_64.tar.gz
# 输出示例: 3f2a9c8e1b7d4f6a0e5c8b7a1d2e3f4a  BMNNSDK-4.7.0-driver-6.2.0-ubuntu20.04-x86_64.tar.gz
# 与官方页面公布的MD5值逐字符比对，确认一致。

# 更安全的SHA256校验
sha256sum BMNNSDK-4.7.0-driver-6.2.0-ubuntu20.04-x86_64.tar.gz

除了哈希校验，还应核对文件大小是否与官方标注一致。若文件大小相差几个字节，即使MD5碰巧一致（概率极低），也应视为异常。

4.2.3 安装依赖工具链

驱动编译需要完整的工具链。在Debian/Ubuntu系统上，执行以下命令安装基础工具：

sudo apt update
sudo apt install -y gcc g++ make dkms linux-headers-$(uname -r) build-essential

对于CentOS/RHEL系统，使用yum或dnf：

sudo yum install -y gcc gcc-c++ make dkms kernel-devel-$(uname -r) kernel-headers-$(uname -r)

其中linux-headers-$(uname -r)是编译内核模块的必需依赖，它提供了内核源码树中的头文件与生成文件。若该包安装失败，通常是因为内核版本过旧或软件源未更新。此时需要手动添加对应的软件源或从内核镜像站下载头文件包。

4.3 案例拆解：一次因内核头文件缺失导致的编译失败

背景与约束：某AI算法团队在一台配备BM1684加速卡的服务器上部署环境，操作系统为Ubuntu 20.04.3 LTS，内核版本为5.4.0-135-generic。团队按照官方文档执行./install.sh时，脚本在编译bmdrv.ko阶段报错，提示fatal error: linux/version.h: No such file or directory。

初始现象：安装脚本执行到make步骤时中断，错误日志指向/usr/src/linux-headers-5.4.0-135-generic路径下缺少version.h文件。

分析判断过程：团队首先检查了linux-headers-5.4.0-135-generic包是否安装完整。执行dpkg -l | grep linux-headers发现linux-headers-5.4.0-135（通用头文件）已安装，但linux-headers-5.4.0-135-generic（针对特定内核的模块头文件）未安装。进一步检查/usr/src目录，发现只有linux-headers-5.4.0-135文件夹，缺少linux-headers-5.4.0-135-generic。

实际操作步骤：

1. 确认当前内核版本：uname -r 输出 5.4.0-135-generic。
2. 尝试安装缺失包：sudo apt install linux-headers-5.4.0-135-generic。但系统提示“无法定位软件包”，因为该内核版本对应的头文件包已从Ubuntu 20.04标准源中移除（属于旧版本维护期外）。
3. 解决方案：从Ubuntu官方旧包存档（old-releases.ubuntu.com）下载.deb文件手动安装。使用wget获取linux-headers-5.4.0-135-generic_5.4.0-135.152_amd64.deb，然后sudo dpkg -i安装。
4. 安装完成后，重新执行./install.sh，驱动编译顺利通过，bmdrv.ko成功加载，ls /dev/bm*能看到/dev/bmdev设备节点。

结果对比与复盘：修复前，安装脚本在编译阶段耗时约2分钟后失败；修复后，整个安装过程仅需3分钟即完成。复盘发现，团队在准备阶段忽略了linux-headers-$(uname -r)的安装验证，直接使用了apt install linux-headers-generic（虚拟包），该包并未安装特定内核版本的头文件。经验是：安装后必须执行ls /usr/src/linux-headers-$(uname -r)确认目录存在且包含include/generated/autoconf.h文件。

4.4 常见误区与总结复盘