📚 课程目录第4章移植第一步

4、移植第一步：配置空间访问——从Linux pci_read_config_*到RTOS直接IO访问

PCIe配置空间是驱动与设备交互的起点。在Linux中，内核提供了标准化的pci_read_config_*/pci_write_config_*系列API，屏蔽了底层访问细节。而在RTOS环境下，这些API不复存在，开发者必须直接操作硬件寄存器——通过IO端口或内存映射IO（MMIO）完成配置空间的读写。本章将剖析这一转换过程的核心要点。

核心认知：移植的第一步不是复制代码，而是理解配置空间访问的硬件机制。Linux的封装层隐藏了ECAM（Enhanced Configuration Access Mechanism）和IO端口两种访问方式，RTOS移植需要根据目标平台重新实现这些底层操作。

4.1 配置空间访问机制对比

PCIe配置空间的访问方式经历了从传统IO端口到内存映射的演进。下表总结了两种机制在Linux与RTOS下的差异：

对比维度	Linux（内核态）	RTOS（裸机/嵌入式）
访问方式	pci_read_config_byte/word/dword	直接IO端口读写 / MMIO地址解引用
配置空间基址	由pci_bus结构体管理，自动计算	手动获取ECAM基地址（通常来自设备树或硬件寄存器）
总线/设备/功能编码	内核pci_dev结构体自动携带	手动组合BDF（Bus:Device.Function）
寄存器偏移	API参数直接传入offset	offset + BDF基址计算
同步/互斥	内核自带上锁（pci_lock）	需要自行加锁（如spinlock或mutex）
错误处理	返回PCIBIOS_*错误码	检查硬件状态寄存器或超时

4.2 ECAM：现代PCIe配置空间访问标准

从PCIe Gen1开始，配置空间访问统一采用ECAM（Enhanced Configuration Access Mechanism）。ECAM将配置空间映射到一段连续的物理内存地址区域，每个PCIe功能（Function）占用4KB空间，其中前256字节为标准配置空间（兼容PCI），后256字节为PCIe扩展配置空间。

  ECAM地址计算公式：

  addr = ecam_base + (bus << 20) | (device << 15) | (function << 12) | offset

  其中：bus范围0-255，device范围0-31，function范围0-7，offset范围0-4095。

下图展示了ECAM内存映射的结构：

4.3 Linux pci_read_config_* 内部机制

Linux内核的配置空间访问函数最终会调用架构相关的底层实现。以x86为例，其调用链如下：

应用层/驱动层：调用 pci_read_config_word(dev, offset, &val)
通用层：通过 pci_bus_read_config_word 分发到总线操作方法集
架构层：x86使用 pci_conf1_read（IO端口方式）或 raw_pci_read（MMIO方式）
硬件层：最终执行 outl/inl 指令或内存解引用

移植陷阱：Linux在x86上默认使用IO端口0xCF8/0xCFC访问配置空间（PCI Conf1机制），而ARM64等嵌入式平台几乎全部使用ECAM内存映射。RTOS移植时，务必确认目标平台的配置空间访问方式，不要硬编码x86的IO端口地址。

4.4 RTOS直接IO访问实现

在RTOS中，我们需要手动实现配置空间的读写函数。以下是一个基于ECAM的通用实现模板：

/* RTOS PCIe配置空间访问——ECAM方式 */
#include <stdint.h>
#include <stdbool.h>

/* ECAM基地址（通常由硬件平台定义或从设备树解析） */
#define ECAM_BASE_ADDR     0x40000000UL

/* 最大总线/设备/功能范围 */
#define MAX_BUSES          256
#define MAX_DEVICES        32
#define MAX_FUNCTIONS      8

/* 计算ECAM地址 */
static volatile uint8_t* ecam_get_addr(uint8_t bus, uint8_t dev, 
                                        uint8_t func, uint16_t offset)
{
    uint32_t addr = ECAM_BASE_ADDR 
                    | ((uint32_t)bus << 20) 
                    | ((uint32_t)dev << 15) 
                    | ((uint32_t)func << 12) 
                    | (offset & 0xFFF);
    return (volatile uint8_t*)addr;
}

/* 读配置空间——字节 */
bool pcie_read_config_byte(uint8_t bus, uint8_t dev, 
                           uint8_t func, uint16_t offset, uint8_t *val)
{
    if (offset > 0xFFF) return false;  /* 超出4KB范围 */
    volatile uint8_t *addr = ecam_get_addr(bus, dev, func, offset);
    *val = *addr;
    return true;
}

/* 读配置空间——字（16位） */
bool pcie_read_config_word(uint8_t bus, uint8_t dev, 
                           uint8_t func, uint16_t offset, uint16_t *val)
{
    if (offset > 0xFFE) return false;  /* 字对齐 */
    volatile uint16_t *addr = (volatile uint16_t*)ecam_get_addr(bus, dev, func, offset);
    *val = *addr;
    return true;
}

/* 读配置空间——双字（32位） */
bool pcie_read_config_dword(uint8_t bus, uint8_t dev, 
                            uint8_t func, uint16_t offset, uint32_t *val)
{
    if (offset > 0xFFC) return false;  /* 双字对齐 */
    volatile uint32_t *addr = (volatile uint32_t*)ecam_get_addr(bus, dev, func, offset);
    *val = *addr;
    return true;
}

4.5 移植适配检查清单

从Linux API切换到RTOS直接IO访问时，请逐项确认以下要点：

检查项	说明	常见问题
ECAM基地址获取	从硬件手册、设备树或Bootloader传递的参数中获取	硬编码地址与硬件实际映射不一致
BDF参数传递	RTOS驱动需要显式传递bus/dev/func	遗漏func参数（默认0），导致多功能设备访问失败
对齐访问	byte/word/dword必须遵守自然对齐规则	非对齐访问在ARM平台上触发异常
Cache一致性	ECAM内存区域必须配置为non-cacheable或device memory	使用cacheable映射导致读回陈旧数据
并发保护	多任务访问同一配置空间时需加锁	中断上下文与任务上下文竞争访问
错误处理	检测硬件是否返回全F（配置空间不存在）	未检查返回值，使用无效数据继续运行

4.6 从Linux API到RTOS的映射示例

以下是一个实际的移植对照案例，展示如何将Linux驱动中的配置空间访问代码转换为RTOS版本：

/* ========== Linux 原始代码 ========== */
#include <linux/pci.h>

static int my_driver_probe(struct pci_dev *pdev, 
                           const struct pci_device_id *id)
{
    u16 vendor_id, device_id;
    u8 revision;
    u32 bar0;

    /* 读取设备标识 */
    pci_read_config_word(pdev, PCI_VENDOR_ID, &vendor_id);
    pci_read_config_word(pdev, PCI_DEVICE_ID, &device_id);
    pci_read_config_byte(pdev, PCI_REVISION_ID, &revision);
    
    /* 读取BAR0基地址 */
    pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &bar0);
    
    /* 使能总线主控 */
    pci_set_master(pdev);
    
    return 0;
}

/* ========== RTOS 移植后代码 ========== */
#include <rtos_pcie.h>   /* 自定义PCIe访问头文件 */

/* 设备实例结构体 */
typedef struct {
    uint8_t bus;
    uint8_t dev;
    uint8_t func;
} pcie_device_t;

static int my_driver_init(pcie_device_t *dev)
{
    uint16_t vendor_id, device_id;
    uint8_t revision;
    uint32_t bar0;
    uint16_t command;

    /* 读取设备标识 */
    pcie_read_config_word(dev->bus, dev->dev, dev->func, 
                          PCI_VENDOR_ID, &vendor_id);
    pcie_read_config_word(dev->bus, dev->dev, dev->func, 
                          PCI_DEVICE_ID, &device_id);
    pcie_read_config_byte(dev->bus, dev->dev, dev->func, 
                          PCI_REVISION_ID, &revision);
    
    /* 读取BAR0基地址 */
    pcie_read_config_dword(dev->bus, dev->dev, dev->func, 
                           PCI_BASE_ADDRESS_0, &bar0);
    
    /* 使能总线主控：读取Command寄存器，设置Bus Master位 */
    pcie_read_config_word(dev->bus, dev->dev, dev->func, 
                          PCI_COMMAND, &command);
    command |= 0x0004;  /* PCI_COMMAND_MASTER */
    pcie_write_config_word(dev->bus, dev->dev, dev->func, 
                           PCI_COMMAND, command);
    
    return 0;
}

  关键差异总结：

  Linux使用 struct pci_dev * 隐式携带BDF信息；RTOS需要显式传递bus/dev/func
Linux的 pci_set_master() 封装了Command寄存器的读写；RTOS需要手动操作
Linux的配置空间偏移使用内核定义的宏（如PCI_VENDOR_ID），这些宏在RTOS中同样可用（值相同）

4.7 调试与验证方法

移植完成后，建议按以下步骤验证配置空间访问的正确性：

读取Vendor ID和Device ID：与硬件手册或lspci输出对比
读取Header Type：确认设备是Endpoint（0x00）还是Bridge（0x01）
遍历所有BDF组合：扫描总线0上的所有设备，验证全F返回（无设备）和有效ID返回（有设备）
读写非破坏性寄存器：如Status寄存器（只读），验证读回值合理
测试扩展配置空间：读取PCIe Capability结构（偏移0x100以上），验证扩展空间可访问

快速验证技巧：在RTOS启动早期，通过串口打印Bus 0 Device 0 Function 0的Vendor ID。如果读回0xFFFF，说明ECAM基地址或BDF计算有误；如果读回Intel（0x8086）或其它有效值，说明底层访问通路已打通。

配置空间访问是PCIe驱动移植的基石。只有确保这一步正确无误，后续的BAR空间映射、中断配置、DMA操作才能建立在可靠的基础之上。