深入Linux内核与Hi3536实战：PCIe BAR空间探测原理与验证指南
在嵌入式系统开发中，PCIe设备的地址空间管理是个既基础又关键的话题。每当我们需要为设备分配内存区域，或是调试驱动程序时，BAR(Base Address Register)空间的正确配置往往成为第一个需要攻克的堡垒。但你是否曾好奇过，Linux内核究竟是如何探测出这些BAR空间大小的？本文将带你从内核源码出发，结合Hi3536开发板的实际操作，一探PCIe设备地址空间背后的奥秘。
1. PCIe BAR基础与内核探测机制
PCIe设备的每个BAR都像是一块待开发的土地，而内核的任务就是测量出每块地的实际面积。传统教材告诉我们，内核通过"写全1再读回"的方式探测BAR大小，但这背后的数学原理和硬件交互细节却鲜有深入讨论。
Linux内核中，__pci_read_base函数是这个探测过程的核心。让我们拆解它的关键步骤：
pci_read_config_dword(dev, pos, &l); // 读取BAR原始值 pci_write_config_dword(dev, pos, l | mask); // 向BAR写入全1 pci_read_config_dword(dev, pos, &sz); // 读回修改后的值 pci_write_config_dword(dev, pos, l); // 恢复BAR原始值这个看似简单的操作序列，实际上完成了一次精妙的位操作魔术。当内核向BAR写入全1后，设备会保留可写位而将只读位恢复为0。通过分析读回值的比特模式，内核就能计算出地址空间大小。
关键的计算发生在pci_size函数中：
size = (size & ~(size-1)) - 1;这个位操作公式可以提取出地址空间的尺寸信息。让我们用Hi3536的BAR0实际值来验证：
- 写入全1后读回值：0xfc00000f
- 计算过程：
size = 0xfc00000f size_minus_1 = 0xfbffffff inverted = ~size_minus_1 = 0x04000000 masked = size & inverted = 0x04000000 final_size = masked - 1 = 0x03ffffff # 64MB
提示：这个计算过程实际上是在找出最低的有效位，从而确定地址空间的对齐要求和大小。
2. Hi3536开发板实战：寄存器级操作验证
理论需要实践验证，现在我们切换到Hi3536开发板环境，通过直接操作寄存器来重现内核的探测过程。
首先查看PCIe配置空间的初始状态：
hisilicon # md 0x1f000000 1f000000: 353619e5 00100146 04800001 00000000 1f000010: 0000000c 00000000 0000000c 00000000 1f000020: 00000000 00000000 00000000 00020000这里BAR0的初始值为0x0000000c，表明这是一个64位可预取的存储器空间。现在我们模拟内核的操作：
# 向BAR0写入全1 hisilicon # mw 0x1f000010 0xffffffff # 读取BAR0当前值 hisilicon # md 0x1f000010 1f000010: fc00000f读回值0xfc00000f与预期相符，其中低4位0xf表示存储器类型，而高26位(0x3ffffff)则揭示了地址空间大小。这与我们在代码分析中看到的结果一致。
有趣的是，当我们对BAR1进行同样操作时：
hisilicon # mw 0x1f000014 0xffffffff hisilicon # md 0x1f000014 1f000014: ffffff0f读回值0xffffff0f出现了"偏差"——理论上应该是全1。这种现象可能与Hi3536的特殊设计有关：
| 寄存器 | 预期值 | 实际值 | 差异分析 |
|---|---|---|---|
| BAR0 | 0xffffffff | 0xfc00000f | 正常，26位地址空间掩码 |
| BAR1 | 0xffffffff | 0xffffff0f | 可能涉及特殊硬件设计 |
3. 64位地址空间的处理艺术
现代PCIe设备经常需要超过4GB的地址空间，这就引入了64位BAR的概念。在Hi3536上，BAR0和BAR1组合形成了一个64位地址空间，让我们看看内核如何处理这种情况。
在__pci_read_base函数中，64位空间探测增加了以下步骤：
if (res->flags & IORESOURCE_MEM_64) { pci_read_config_dword(dev, pos + 4, &l); // 读取高位BAR pci_write_config_dword(dev, pos + 4, ~0); // 高位写入全1 pci_read_config_dword(dev, pos + 4, &sz); // 读回高位 pci_write_config_dword(dev, pos + 4, l); // 恢复高位 // 合并64位值 l64 |= ((u64)l << 32); sz64 |= ((u64)sz << 32); mask64 |= ((u64)~0 << 32); }对于Hi3536的配置：
- BAR0: 0x0000000c (低32位)
- BAR1: 0x00000000 (高32位)
- 组合后的64位地址: 0x000000000000000c
当向BAR1写入全1后读回0xffffffff，表明高位可以完全由主机控制。最终的地址空间计算仍然使用相同的pci_size公式，只是扩展到64位：
sz64 = pci_size(l64, sz64, mask64); // 返回0x0000000003ffffff4. 内核源码与硬件行为的深度对应
将内核行为与硬件实际操作对应起来，是理解PCIe设备初始化的关键。让我们建立这个映射关系：
内核操作序列：
- 读取-修改-写回-恢复
- 位运算计算空间大小
硬件响应行为：
- 对写入的1值，可配置位保持1，只读位恢复0
- 通过BAR_MASK寄存器控制可配置范围
Hi3536特殊处理：
- BAR_MASK寄存器位于0x1000偏移处
- 每个BAR有独立的掩码控制
例如Hi3536 uboot中的初始化代码：
__raw_writel(0x03ffffff, HISI3536_PCIE_CONFIG_BASE + 0x1000 + 0x10 + 4 * 0); __raw_writel(0x0, HISI3536_PCIE_CONFIG_BASE + 0x1000 + 0x10 + 4 * 1);这段代码设置了BAR0的掩码为0x03ffffff，正好对应我们探测到的26位地址空间(64MB)。而BAR1掩码为0表示它作为64位空间的高位部分。
5. 调试技巧与异常情况处理
在实际开发中，BAR空间探测不总是顺利的。以下是几个常见问题及解决方法：
情况一：读回值全为0或全为1
- 可能原因：BAR未启用或设备不存在
- 检查方法：
# 确认设备ID和厂商ID是否正确 hisilicon # md 0x1f000000 2 1f000000: 353619e5 00100146
情况二：读回值与预期有偏差
- 如Hi3536 BAR1的0xffffff0f
- 处理步骤：
- 检查BAR_MASK寄存器设置
- 确认是否涉及特殊硬件功能
- 参考芯片手册的异常情况说明
情况三：64位空间计算错误
- 验证方法：
// 在驱动中添加调试打印 dev_info(&pdev->dev, "BAR %d size: %llx\n", bar, resource_size(res));
注意：某些PCIe设备支持Resizable BAR功能，这会使探测过程更加复杂。在Hi3536上需要确认芯片是否支持此特性。
6. 从理论到实践：完整验证流程
为了确保我们的理解正确，让我们设计一个完整的验证流程：
硬件准备：
- Hi3536开发板
- 串口调试终端
- 可选逻辑分析仪(用于监测PCIe总线)
软件准备：
- 内核源码(重点关注drivers/pci/probe.c)
- Hi3536技术参考手册
- U-Boot或Linux下的工具集
验证步骤：
graph TD A[读取BAR初始值] --> B[写入全1] B --> C[读回修改值] C --> D[计算空间大小] D --> E[与理论值对比]结果分析点：
- BAR属性位(低4位)是否正确
- 地址空间大小是否符合预期
- 64位空间的高低位是否协调
在实际操作中，我发现Hi3536的BAR1返回0xffffff0f而非全1的现象，经过多次测试确认这是芯片设计的预期行为——高24位可配置，低8位固定。这也解释了为什么最终的空间计算仍然正确。
