2、硬件与软件环境准备：熟悉BM1684/BM1688开发板、PCIe/SoC模式、SDK版本、驱动安装、交叉编译工具链及测试工具链的搭建
在开始BM1684/BM1688项目验收之前，必须首先完成硬件与软件环境的系统化准备。环境搭建的质量直接决定了后续帧率、延迟、准确率和稳定性测试数据的可信度。若环境不一致，不同团队或不同批次测试得出的数据将不具备可比性，甚至可能因驱动版本不匹配导致推理结果错误。本章将围绕开发板硬件认知、PCIe/SoC双模式差异、SDK与驱动管理、交叉编译工具链配置以及测试工具链搭建五个核心维度展开，帮助验收团队建立一套可复现、可追溯的标准化环境基线。
上图展示了从硬件平台到验收目标的完整链路。在实际操作中，环境准备并非一次性工作，而是需要形成文档化的基线记录。以下各节将逐一拆解每个环节的具体操作步骤、验证方法及常见问题。
2.1 开发板硬件认知与接口检查
核心原理：BM1684是算能科技推出的第三代TPU芯片，INT8算力达17.6 TOPS，FP32算力约2.2 TFLOPS；BM1688则面向更低功耗场景，INT8算力约16 TOPS。两者均支持PCIe Gen3 x4接口和SoC模式（片上系统）。在验收前，必须确认开发板的硬件版本、内存容量（BM1684通常搭配12GB DDR4，BM1688搭配8GB或16GB LPDDR4X）、eMMC存储大小以及散热方案是否满足持续满载测试需求。
操作流程：
- 外观与接口检查：核对开发板上的丝印版本号，确认PCIe金手指无氧化、供电接口无松动。使用万用表测量电源输入电压是否在额定范围内（PCIe卡通常为12V±5%）。
- 串口连接：使用USB转TTL模块连接调试串口（通常为3.3V电平，波特率115200），上电后应能看到U-Boot启动日志。
- 系统启动验证：SoC模式下，开发板应能独立启动Linux系统；PCIe模式下，开发板作为从设备，由Host主机识别。
2.2 PCIe模式与SoC模式的区别及选型
核心原理：PCIe模式下，BM1684/BM1688作为协处理器，通过PCIe总线与x86/ARM主机通信，利用主机内存和存储资源，适合需要复杂预处理或后处理的AI应用。SoC模式下，芯片独立运行Linux系统，所有计算在板内完成，适合边缘部署场景。两种模式在驱动加载方式、内存管理、数据交互路径上存在本质差异。
| 对比维度 | PCIe模式 | SoC模式 |
|---|---|---|
| 驱动安装位置 | Host主机（x86/ARM） | 开发板自身Linux内核 |
| 内存管理 | 通过DMA映射主机内存 | 使用板载DDR/LPDDR |
| 数据交互 | PCIe DMA + 中断 | 内部总线 + 共享内存 |
| 典型应用 | 服务器端视频分析 | 车载/安防边缘盒子 |
| 调试方式 | 主机侧gdb + dmesg | 板载串口 + 网络SSH |
| 功耗范围 | 25W-35W（含散热） | 15W-25W（被动散热） |
判断方法：验收前需明确项目部署形态。若测试目标为边缘设备，则必须使用SoC模式进行测试；若为数据中心场景，则采用PCIe模式。两种模式的帧率表现可能差异显著，因为PCIe模式下数据搬运存在额外延迟。
2.3 SDK版本选择与驱动安装
核心原理：算能科技提供BMNNSDK2（包含编译工具、运行时库、示例代码）和tpu-mlir（用于模型转换）。SDK版本与芯片型号、驱动版本存在严格对应关系。例如，BMNNSDK2.7.0支持BM1684，而BMNNSDK2.8.0及以上版本才支持BM1688。驱动模块（bmnpu.ko）负责管理TPU的算力资源、内存分配和任务调度。
操作流程：
# 1. 确认芯片型号
cat /proc/bm_version # SoC模式
lspci | grep -i "bm168" # PCIe模式
# 2. 安装SDK（以BMNNSDK2.8.0为例）
wget https://sophon-edge.sophon.cn/BMNNSDK2.8.0/BMNNSDK2.8.0-linux.tar.gz
tar -xzf BMNNSDK2.8.0-linux.tar.gz
cd BMNNSDK2.8.0
./install.sh --target=bm1688 --mode=soc # 或 --mode=pcie
# 3. 加载驱动（PCIe模式需在Host侧执行）
insmod /opt/bmnnsdk2/driver/bmnpu.ko
# 验证驱动
ls /dev/bm*
# 预期输出: /dev/bmdev0 /dev/bmctl0
# 4. 设置环境变量
export PATH=$PATH:/opt/bmnnsdk2/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/bmnnsdk2/lib案例拆解：某安防项目使用BM1688 SoC模式，误将BM1684的驱动包安装到系统中，导致调用bmrt_load_model时返回“Unsupported chip”错误。排查过程：通过dmesg | grep bmnpu查看内核日志，发现驱动版本与芯片ID不匹配。解决方法是卸载旧驱动，重新编译安装匹配的驱动模块，并验证bm_version输出正确。
2.4 交叉编译工具链配置
核心原理：SoC模式下，开发板资源有限，通常需要在x86主机上使用交叉编译工具链生成ARM架构的可执行文件。BM1688采用ARM Cortex-A53架构，需使用aarch64-linux-gnu-gcc工具链。PCIe模式下，若Host为x86，则使用原生gcc；若Host为ARM，则同样需要交叉编译。
配置步骤：
- 安装工具链：
sudo apt install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu - 验证编译环境：编写简单的hello.c，使用
aarch64-linux-gnu-gcc hello.c -o hello编译，通过file hello确认输出为“ELF 64-bit LSB executable, ARM aarch64”。 - 链接SDK库：编译时需指定
-I/opt/bmnnsdk2/include和-L/opt/bmnnsdk2/lib，并添加-lbmlib -lbmrt等链接选项。
set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc)，并确保SDK的lib目录下存在libbmrt.so和libbmlib.so的ARM版本。若使用PCIe模式且Host为x86，则无需交叉编译，直接使用gcc即可。
2.5 测试工具链搭建
核心原理：验收测试需要一套完整的工具链来采集帧率、延迟、准确率和稳定性数据。基础工具包括：bmrt_test（用于验证模型推理正确性）、bm-smi（监控芯片温度、利用率、显存占用）、perf（性能分析）、以及自定义的C++/Python测试程序。
工具清单与用途：
| 工具名称 | 用途 | 关键参数 |
|---|---|---|
| bmrt_test | 验证模型输出与参考结果一致性 | --input 输入数据 --output 输出目录 |
| bm-smi | 监控芯片状态 | watch -n 1 bm-smi |
| perf stat | 统计CPU/内存/上下文切换 | perf stat -e task-clock,context-switches |
| 自定义测试程序 | 测量端到端延迟和帧率 | 循环推理并记录时间戳 |
操作流程：
# 1. 运行模型正确性测试
bmrt_test --context_dir ./bm1688_yolov5s --input ./test_input.bin --output ./output
# 2. 监控芯片状态（另开终端）
watch -n 1 bm-smi
# 3. 运行自定义性能测试程序
./benchmark --model ./yolov5s.bmodel --loop 1000 --warmup 10案例拆解：在BM1684 PCIe模式下测试YOLOv5s模型时，发现帧率仅为预期的一半。通过bm-smi观察到芯片利用率仅40%，而CPU占用率高达90%。分析发现瓶颈在Host侧图像预处理（OpenCV缩放）未充分利用多线程。优化方案：使用cv::setNumThreads(8)并启用硬件加速（如IPP），最终帧率从45 FPS提升至82 FPS。
2.6 环境基线文档化与复现验证
核心原理：验收数据的可复现性依赖于环境基线的完整记录。基线文档应包含：硬件版本、SDK版本、驱动版本、内核版本、编译选项、测试工具版本、环境变量、以及所有依赖库的哈希值。
操作流程：
- 生成环境快照：
bm_version > env_snapshot.txt，uname -a >> env_snapshot.txt，md5sum /opt/bmnnsdk2/lib/*.so >> env_snapshot.txt。 - 将快照文件与测试代码、模型文件一并归档至版本控制仓库。
- 在另一台相同配置的机器上执行
./run_all_tests.sh，对比输出结果是否一致。
git tag管理SDK版本，并在测试报告中明确标注。
完成上述环境准备后，验收团队即可在统一、可控的软硬件基础上开展帧率、延迟、准确率和稳定性测试，确保所有测试结果具备横向可比性和纵向可追溯性。