内核驱动与板级移植的分层测试
内核驱动与 BSP 移植直接依赖 MMU、DMA、中断控制器和物理总线。模拟器与单元测试可以覆盖寄存器计算、状态机和错误分支，却不能替代真实板卡上的中断时序、内存一致性、供电和热插拔验证。驱动发布前需要分层测试，并用目标硬件与代表性负载确认稳定性。
+-----------------------------------------------------------------------+ | Linux 内核驱动与 BSP 移植三级分层测试 | +-----------------------------------------------------------------------+ | v +------------------+ 集成层 +------------------+ 端到端层 +------------------+ | 内核单元测试 | ----------> | 硬件集成测试 | ----------> | 端到端与电源管理 | | KUnit 算子测试 | | DMA Coherent 校验| | Suspend/Resume | | Register Map 位 | | /proc/interrupts | | iperf3 长期打流 | +------------------+ +------------------+ +------------------+1. 单元测试层：利用 KUnit 守护纯内核逻辑与数据结构
KUnit 是 Linux 内核原生的单元测试框架，运行在内核空间（Kernel Space）。它的核心定位是：测试不依赖真实硬件物理外设的内核纯 C 逻辑。
在网卡驱动或 Char 字符设备驱动开发中，单元测试必须死守以下边界：
- 数据结构逻辑：Ring Buffer 的 Head/Tail 指针溢出与环形回绕计算。
- 校验和算法：IP/TCP 硬件 Offload 校验和软件计算的回退函数。
- 寄存器 bit 位掩码计算：打包与解包硬件 Status/Control 寄存器的辅助宏函数。
使用kunit.py在 UML（User Mode Linux）环境下秒级运行驱动单元测试：
./tools/testing/kunit/kunit.py run \ --kunitconfig=drivers/net/ethernet/custom_net/kunitconfig测试终端输出详细的算子测试报告：
[10:24:12] ========= drivers/net/ethernet/custom_net ========= [10:24:12] [PASSED] custom_net_ring_buffer_wrap_test [10:24:12] [PASSED] custom_net_checksum_calc_test [10:24:12] =================================================== [10:24:12] Testing complete. Passed: 2, Failed: 0, Errors: 0对应的 KUnit C 语言测试用例示例：
#include <kunit/test.h> #include "custom_net_driver.h" static void custom_net_ring_buffer_wrap_test(struct kunit *test) { struct ring_buffer ring; ring_init(&ring, 8); // 8 成员容量 for (int i = 0; i < 7; i++) { KUNIT_EXPECT_EQ(test, 0, ring_push(&ring, i)); } // 第 8 次 Push 应该成功且指针回绕到 0 KUNIT_EXPECT_EQ(test, 0, ring_push(&ring, 7)); KUNIT_EXPECT_TRUE(test, ring_is_full(&ring)); } static struct kunit_case custom_net_test_cases[] = { KUNIT_CASE(custom_net_ring_buffer_wrap_test), {} }; static struct kunit_suite custom_net_test_suite = { .name = "custom_net_driver_suite", .test_cases = custom_net_test_cases, }; kunit_test_suite(custom_net_test_suite);2. 硬件集成测试层：校验 DMA 内存一致性与中断分流
通过单元测试后，驱动代码进入真实 BSP 硬件集成测试阶段。这一层的核心在于校验驱动与 Linux 内核子系统（DMA、Interrupts、Device Tree、Clock Framework）的交互。
在真实的 i.MX8M 板卡上，经常出现的 Panic 根因在于 DMA 缓冲区未进行正确的 Cache Flush/Invalidate，导致 CPU 读到了 Cache 中的旧数据，或者 DMA 读到了 CPU 还没写入 DDR 的脏数据。
在驱动层，必须使用dma_alloc_coherent或在 Streaming DMA 中显式调用 API：
// 硬件集成层的 DMA 映射关键代码片段 dma_addr_t dma_handle; void *cpu_addr = dma_alloc_coherent(&pdev->dev, RX_BUF_SIZE, &dma_handle, GFP_KERNEL); if (!cpu_addr) { dev_err(&pdev->dev, "DMA 内存分配失败!\n"); return -ENOMEM; }在测试阶段，通过/proc/interrupts与ftrace工具实时观测硬件中断的分发与处理耗时：
# 监控千兆网卡硬件中断触发频次与 CPU 亲和度分配 watch -n 1 "cat /proc/interrupts | grep custom_net"同时开启内核dma-debug防线，拦截非法 DMA 越界操作：
# 在 bootargs 中增加 dma_debug=on，运行时查看 DMA 检查日志 dmesg | grep -i "DMA-API"如果驱动存在未释放的 DMA 映射或非法跨界，DMA-API防线会立即打印 Warning 堆栈，避免问题隐蔽泄漏到生产现场。
3. 端到端与电源管理测试层：高并发打流与休眠唤醒（Suspend/Resume）
端到端测试必须覆盖真实的生产极限制。BSP 移植最容易在电源管理（Power Management, PM）与长时间压力打流时崩溃。
常用的端到端测试命令包含三个维度：
- 高并发吞吐打流：使用
iperf3双向打满千兆带宽持续 12 小时，观察是否存在内存泄露与 Socket 卡死。 - 电源管理 Suspend/Resume 挂起唤醒循环：驱动必须正确实现
pm_ops钩子，关闭与恢复 PCIe 时钟。 - 震荡复位测试：在打流过程中随机执行
ifconfig eth0 down && ifconfig eth0 up。
使用 Shell 自动化脚手架对 BSP 进行 Suspend/Resume 压力轮询：
#!/bin/bash # 驱动 PM 端到端自动化测试脚本 ITERATION=100 INTERFACE="eth0" for ((i=1; i<=ITERATION; i++)); do echo "[E2E Test] ===== 循环 $i/$ITERATION: 启动 iperf3 打流 =====" iperf3 -c 192.168.1.100 -t 5 -P 4 > /dev/null 2>&1 if [ $? -ne 0 ]; then echo "错误: 打流过程中网络中断!" exit 1 fi echo "[E2E Test] 触发 RTC 唤醒定时器并进入 Suspend-to-RAM (mem)..." rtcwake -m mem -s 3 # 唤醒后立刻检查驱动状态 dmesg | grep -i "failed" | tail -n 5 ifconfig $INTERFACE | grep "RUNNING" > /dev/null if [ $? -ne 0 ]; then echo "致命错误: 系统唤醒后网卡驱动未恢复!" exit 2 fi done echo "[E2E Test] 100 次 Suspend/Resume 挂起唤醒测试全部成功通过!"不要相信单测通过就代表驱动可用的幻想。只有建立从 KUnit 单元层、DMA/中断集成层，再到 Suspend/Resume 端到端防线的三层测试体系，移植的 Linux BSP 才能真正达到生产级稳定。
