📚 课程目录第4章 Marvell DPU软件开发套件与工具链

4. Marvell DPU软件开发套件与工具链

Marvell DPU（以 OCTEON 10 系列为代表）的软件开发并不是“装一个编译器就能跑”的简单过程，而是一套围绕 SDK、交叉编译工具链、固件镜像、调试通道和版本控制协同工作的工程体系。本节的目标是让读者能够从零搭建一个可编译、可烧录、可调试、可回退的开发环境，并理解每个组件在整条链路中的位置与作用。

一、SDK 的组成与职责划分

Marvell 为 OCTEON 系列提供的软件开发套件通常以 OCTEON-SDK 的形式发布，其核心目录结构决定了后续所有操作。理解目录职责，比记住安装命令更重要。

sdk/：SDK 主体，包含内核源码、驱动、BSP、板级配置文件与构建脚本。
tools/：交叉编译工具链，通常是基于 aarch64 的 GNU 工具链，包含 aarch64-marvell-linux-gnu-gcc 等。
target/：目标板相关的根文件系统、镜像打包脚本与烧录工具。
components/：可选组件，如 DPDK、OVS、VPP、OpenSSL 加速库等。
scripts/：环境初始化脚本，典型入口是 env.sh 或 setup-env。

SDK 的版本与 DPU 芯片型号、固件版本强绑定。例如 OCTEON 10 CN10K 系列通常对应 SDK 11.x 或 12.x 分支，混用版本会导致内核驱动与固件接口不匹配，表现为启动阶段卡在 BDK 初始化或网络端口无法枚举。

二、编译环境搭建

推荐使用 Ubuntu 20.04/22.04 LTS 作为宿主系统，并预留至少 100 GB 磁盘空间。基础依赖包括 build-essential、libssl-dev、device-tree-compiler、python3、git、flex、bison 等。

sudo apt update
sudo apt install -y build-essential libssl-dev device-tree-compiler \
  python3 python3-pip git flex bison libncurses-dev

tar -xjf OCTEON-SDK-12.1.0.tar.bz2 -C ~/
cd ~/OCTEON-SDK-12.1.0
source env.sh
echo $CROSS_COMPILE   # 应输出 aarch64-marvell-linux-gnu-

执行 source env.sh 后，环境变量 CROSS_COMPILE、PATH、OCTEON_ROOT 会被正确设置。此时可用 aarch64-marvell-linux-gnu-gcc -v 验证工具链是否可用。若输出中显示目标架构为 aarch64 且版本与 SDK 发布说明一致，说明编译环境基本就绪。

建议将 source env.sh 写入独立的 shell 会话，避免污染系统默认的 gcc 环境。每次打开新终端后重新 source 一次即可。

三、固件加载与镜像烧录

OCTEON 10 的启动链路通常为：BootROM → BDK/ATF → U-Boot → Linux 内核 → 根文件系统。SDK 编译完成后会生成若干关键产物：

u-boot.bin：引导加载程序。
Image 或 vmlinux：Linux 内核镜像。
*.dtb：设备树二进制。
rootfs.ext4：根文件系统镜像。
fip.bin 或 flash-image.bin：整合后的可烧录固件包。

烧录方式主要有两种：通过板载调试器（如 JTAG/OCD）写入 SPI Flash，或通过 U-Boot 的 tftp + sf 命令在线更新。以 U-Boot 在线更新为例：

setenv serverip 192.168.1.100
setenv ipaddr 192.168.1.50
tftp 0x20000000 flash-image.bin
sf probe 0
sf erase 0x0 0x2000000
sf write 0x20000000 0x0 0x2000000
reset

烧录完成后，串口应能看到 BDK 版本号、U-Boot 版本号以及内核启动日志。若卡在 Starting kernel ... 之后无输出，通常是设备树与板型不匹配，需要检查 *.dtb 是否选用了正确的板级文件。

四、调试工具与常用手段

调试分为三个层次：硬件层、引导层和系统层。

硬件层：使用 JTAG 调试器配合 Marvell OCD 工具，可单步执行 BDK/ATF，查看寄存器与内存。
引导层：通过串口进入 U-Boot，使用 md、mw、printenv、bdinfo 等命令检查内存映射与环境变量。
系统层：Linux 下使用 dmesg、ethtool、perf、gdb 以及 Marvell 提供的 octeon-tools 查看端口状态、队列统计和硬件加速单元。

一个典型的排障场景是：DPU 启动后网络端口未识别。此时应先在 U-Boot 中确认 ethact 与 PHY 地址，再进入 Linux 用 dmesg | grep -i cgx 查看 CGX 驱动加载情况，最后用 ethtool -S eth0 观察收发包计数是否增长。

五、版本管理与环境一致性

SDK、固件、内核、根文件系统四者版本必须一致。建议使用 Git 管理板级配置与自定义补丁，并在仓库根目录维护一份 VERSION 文件，记录 SDK 版本、固件版本、内核 commit 和根文件系统构建时间。

组件	示例版本	校验方式
SDK	12.1.0	`cat sdk/VERSION`
固件	12.1.0-fw	串口启动日志 BDK 版本
内核	5.10.104	`uname -r`
根文件系统	build-2024-06	`/etc/os-release`

不要在生产板上直接尝试未验证的 SDK 主分支。建议先在实验室板卡上完成烧录与回退验证，确认可回退到已知稳定版本后再批量更新。

六、环境搭建的完整闭环

将上述环节串联起来，一个可用的开发环境应满足：宿主工具链可编译内核与用户态程序；生成的镜像可通过 U-Boot 或 JTAG 写入目标板；串口与网络调试通道可用；版本信息可追溯、可回退。下面这张图概括了从 SDK 到目标板的完整数据流与工具链关系。

搭建完成后，建议做一次最小验证：编译一个简单的用户态程序，交叉编译后通过 scp 或 NFS 挂载到目标板运行，确认工具链、根文件系统和网络通道全部可用。只有这条链路完整打通，后续的 DPDK 移植、OVS 卸载和性能调优才有稳定的基础。