3. 可靠性测试环境搭建

可靠性测试与普通功能验证最大的区别在于：测试往往要连续运行数小时甚至数天，期间需要反复编译测试程序、反复重启目标板、持续采集串口日志和网络数据。因此，环境搭建的目标不是"能跑一次"，而是"能稳定、可重复、可观测地跑很多次"。本节围绕 STM32MP1 系列（以 STM32MP157 为例）搭建一套完整的测试环境，包括交叉编译工具链、SDK、串口与网络调试通道、目标板启动方式以及测试主机侧的准备工作。

一、交叉编译工具链的选择与安装

STM32MP1 是 Cortex-A7 + Cortex-M4 异构架构，Linux 侧运行在 A7 上，因此测试程序需要在 x86_64 主机上交叉编译成 ARM 32 位代码。ST 官方推荐使用其配套的 SDK 工具链，而不是发行版自带的 gcc-arm-linux-gnueabihf，原因是官方工具链的 glibc 版本、内核头文件与 ST 发布的 OpenSTLinux 镜像严格匹配，能避免"编译通过但运行时报 GLIBC 版本不符"这类典型问题。

安装方式有两种：一是直接下载 ST 提供的 SDK 安装包（如 en.SDK-x86_64-stm32mp1-openstlinux-5.15-dunfell-mp1-22-06-28.tar.xz），解压后执行安装脚本；二是通过 Yocto 自行构建。对于可靠性测试，建议直接使用官方 SDK，减少变量。安装完成后需要 source 环境脚本：

# 解压并安装 SDK
tar xf en.SDK-x86_64-stm32mp1-openstlinux-5.15-dunfell-mp1-22-06-28.tar.xz
cd stm32mp1-openstlinux-5.15-dunfell-mp1-22-06-28/sdk
./st-image-weston-openstlinux-weston-stm32mp1-x86_64-toolchain-3.1-openstlinux-5.15-dunfell.sh

# 每次使用前 source 环境
source /opt/st/stm32mp1/3.1-openstlinux-5.15-dunfell/environment-setup-cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi

# 验证
echo $CC
arm-ostl-linux-gnueabi-gcc -v

验证的关键不是看命令是否存在，而是看 $CC 是否被正确设置为带 sysroot 的完整命令。如果 $CC 为空，说明环境脚本没有生效，后续编译会误用主机 gcc，产生 x86 可执行文件，烧到板子上会直接报 "Exec format error"。

二、SDK 配置与测试程序编译

OpenSTLinux SDK 本质上是一个 Yocto 生成的交叉编译环境，它通过环境变量 CC、CXX、CFLAGS、LDFLAGS 把 sysroot、头文件路径、链接参数全部预设好。编写测试程序时，推荐使用 Makefile 或 CMake，并显式使用 $(CC)，而不是硬编码 gcc。

# Makefile 片段
CC ?= arm-ostl-linux-gnueabi-gcc
CFLAGS += -O2 -Wall -Wextra -g
TARGET = stress_test

all: $(TARGET)
$(TARGET): stress_test.c
	$(CC) $(CFLAGS) -o $@ $< -lpthread -lrt

clean:
	rm -f $(TARGET)

编译完成后用 file stress_test 确认输出为 "ELF 32-bit LSB executable, ARM, EABI5"，这是判断交叉编译是否成功的直接依据。若显示 x86-64，说明工具链未生效。

三、串口与网络调试通道

串口是目标板最可靠的调试通道，即使网络崩溃、系统卡死，串口仍能输出内核 panic 和 oops 信息。STM32MP157 开发板通常通过板载 ST-Link 的虚拟串口（/dev/ttyACM0）或 USB-TTL 连接 UART4。主机侧使用 minicom 或 picocom：

# 串口连接，115200 8N1
picocom -b 115200 /dev/ttyACM0

# 或 minicom
minicom -D /dev/ttyACM0 -b 115200

可靠性测试中，串口日志必须落盘保存，否则长时间测试后无法回溯。推荐用 script 或直接重定向：

picocom -b 115200 /dev/ttyACM0 | tee -a serial_$(date +%F_%H%M).log

网络调试通道用于传输测试程序、采集性能数据、运行网络压力测试。目标板默认通过以太网 DHCP 获取地址，主机侧可用 scp 推送程序，用 ssh 执行远程命令。建议在目标板上配置静态 IP，避免 DHCP 租约变化导致测试脚本中断：

# 目标板 /etc/systemd/network/10-eth0.network
[Match]
Name=eth0
[Network]
Address=192.168.1.100/24
Gateway=192.168.1.1

四、目标板启动方式

STM32MP1 支持多种启动介质：eMMC、SD 卡、NAND、NOR，以及通过 USB/UART 的 DFU 和工程模式。可靠性测试建议使用 SD 卡启动，因为刷写方便、损坏后可直接更换，不影响板载 eMMC 中的出厂系统。启动模式由 BOOT 拨码开关决定，常见配置为 SD 卡启动（BOOT0=0，BOOT1=0，BOOT2=1，具体以板卡手册为准）。

启动流程为：ROM Code → TF-A（FSBL）→ U-Boot（SSBL）→ Linux Kernel → Rootfs。测试中若出现启动失败，应首先通过串口观察卡在哪一阶段：停在 "ROM Code" 说明启动介质或拨码错误；停在 U-Boot 说明镜像损坏；进入内核后 panic 则多为设备树或 rootfs 问题。

五、测试主机环境准备

测试主机需要具备以下能力：交叉编译、串口通信、网络传输、日志采集、时间同步。建议在 Ubuntu 20.04/22.04 LTS 上准备，安装必要软件包：

sudo apt update
sudo apt install -y build-essential git picocom minicom \
  openssh-client sshpass iperf3 tcpdump net-tools \
  python3 python3-pip ntpdate

# 时间同步，保证主机与目标板日志时间戳可比对
sudo ntpdate ntp.aliyun.com

时间同步在可靠性测试中常被忽视，但非常关键。如果主机与目标板时间相差数分钟，串口日志、网络抓包、性能采样三者的时间戳无法对齐，事后分析故障时序会非常困难。建议目标板也启用 NTP 或与主机对时。

此外，建议在主机上建立统一的测试目录结构，把工具链环境、测试程序源码、日志、脚本分开管理：

~/stm32mp1_reliability/
├── env/          # 工具链环境脚本
├── src/          # 测试程序源码
├── bin/          # 交叉编译产物
├── logs/         # 串口与网络日志
├── scripts/      # 自动化测试脚本
└── results/      # 测试结果汇总

完成以上准备后，测试环境应达到的状态是：主机能一键交叉编译测试程序，能通过 scp 推送、ssh 执行，能通过串口实时观察并落盘日志，目标板能从 SD 卡稳定启动并进入 Linux，主机与目标板时间基本一致。这套环境是后续所有可靠性测试（长时间运行、反复重启、网络压力、内存压力、异常注入）的基础，环境本身的稳定性直接决定测试结果的可信度。