ARMv8嵌入式系统Linux下PCIe预取BAR对齐分配失败问题排查

一、无临时方案时的根因分析 #

你遇到的问题是内核5.4.93版本PCIe预取BAR分配逻辑的局限性，结合原始DTS地址布局的碎片化共同导致：

• 原始DTS的PCIe ranges配置使得预取地址空间被前期设备占用后，剩余空闲空间分割为两个不连续的4GiB块；
• 内核5.4.93的PCIe分配逻辑中，calculate_mem_align函数因检测到设备的对齐需求（aligns[0]=0x400000），采用了4GiB的对齐粒度划分空闲空间——该粒度下内核无法跨4GiB块合并空间，因此无法满足RX550显卡6GiB连续预取BAR的需求，最终导致桥2:1.0的预取窗口禁用，BAR显示<unassigned>。

这不属于严格意义上的内核bug，而是5.4.x稳定分支在处理大尺寸BAR+碎片化空间场景时的设计不足，后续内核版本（如5.10+）针对ARM64 PCIe空间分配做了优化，这类问题出现概率更低。

二、calculate_mem_align函数逻辑解释 #

该函数是内核PCIe子系统中用于确定预取BAR地址分配的对齐粒度的核心函数，作用是平衡设备的对齐需求与总线的最大连续空间利用，逻辑如下：

1. 输入参数解析：
   • aligns[]：存储总线上所有设备的BAR最小对齐需求（非零值表示对应设备需要特定粒度的地址对齐）；
   • max_order：总线硬件支持的最大分配阶数（对应总线能提供的最大连续空间粒度）。
2. 核心逻辑步骤：
   • 遍历aligns数组，提取所有非零对齐值，计算其对应的2的幂次阶数（比如0x400000对应2^22，即4MB对齐）；
   • 找出这些阶数中的最大值，记为dev_max_order；
   • 对比dev_max_order与传入的max_order：
     • 如果dev_max_order小于等于max_order，最终对齐粒度取max_order对应的空间大小；
     • 如果dev_max_order大于max_order，则取dev_max_order对应的空间大小（优先满足设备对齐需求）。
3. 你的场景差异解释：
   • 实际嵌入式系统中，aligns[0]=0x400000存在设备对齐需求，计算后最终对齐粒度被限制为4GiB（对应max_order的上限），导致空闲空间按4GiB块划分，形成碎片化；
   • QEMU虚拟主机中，aligns[]全为0（无设备强制对齐需求），函数直接采用max_order对应的8GiB作为对齐粒度，因此能预留出连续的8GiB空间满足RX550的需求。

内容的提问来源于stack exchange，提问作者bruin