3. 座舱驱动架构总览

好，咱们进入第三章。这一章是驱动开发的基石——硬件抽象层。说白了，就是给上层软件一个干净的接口，把底层硬件的复杂性藏起来。

我在R-Car上做第一个项目时，上来就踩了Memory Map的坑。地址配错了，系统直接挂掉。从那以后，我养成了一个习惯：写驱动前，先把Memory Map吃透。

3.1 R-Car Memory Map 深度解析

R-Car H3的地址空间是48位的。但实际映射，咱们重点关注这几个区域：

我个人习惯，在驱动初始化时，先打印出Memory Map的摘要信息。这样调试时心里有数。

3.2 MMU配置实战

MMU配置，是HAL的核心。R-Car的MMU支持4级页表，但咱们在裸机或RTOS环境下，通常只用一级或两级。

为什么？因为简单。一级页表，每个表项覆盖1MB空间。对于16MB的寄存器区域，只需要16个表项。查表快，配置也快。

下面是一个一级页表配置的代码片段：

// 一级页表基地址（必须1MB对齐）
#define L1_PAGE_TABLE_BASE  0xE600_0000

// 页表项属性
#define L1_SECTION          (0x2)      // 段映射
#define L1_AP_RW_RW         (0x3 << 10) // 读写权限
#define L1_SHARED           (0x1 << 16) // 共享属性
#define L1_CACHEABLE        (0x1 << 3)  // 可缓存
#define L1_BUFFERABLE       (0x1 << 2)  // 可缓冲

void mmu_init(void) {
    uint32_t *l1_table = (uint32_t *)L1_PAGE_TABLE_BASE;
    uint32_t va, pa, attr;

    // 清空页表
    for (int i = 0; i < 4096; i++) {
        l1_table[i] = 0;
    }

    // 映射寄存器区域：0xE600_0000 -> 0xE600_0000
    // 属性：非缓存、非缓冲、读写、共享
    attr = L1_SECTION | L1_AP_RW_RW | L1_SHARED;
    for (va = 0xE6000000, pa = 0xE6000000; va < 0xE7000000; va += 0x100000, pa += 0x100000) {
        l1_table[va >> 20] = pa | attr;
    }

    // 映射DDR区域：0x0000_0000 -> 0x0000_0000
    // 属性：可缓存、可缓冲、读写、共享
    attr = L1_SECTION | L1_AP_RW_RW | L1_SHARED | L1_CACHEABLE | L1_BUFFERABLE;
    for (va = 0x00000000, pa = 0x00000000; va < 0x10000000; va += 0x100000, pa += 0x100000) {
        l1_table[va >> 20] = pa | attr;
    }

    // 使能MMU
    __asm volatile(
        "MRC p15, 0, r0, c2, c0, 0\n"   // 读TTBR0
        "ORR r0, r0, #0x40\n"            // 设置页表基地址
        "MCR p15, 0, r0, c2, c0, 0\n"   // 写TTBR0
        "DSB\n"
        "ISB\n"
        "MRC p15, 0, r0, c1, c0, 0\n"   // 读SCTLR
        "ORR r0, r0, #0x1\n"             // 使能MMU
        "MCR p15, 0, r0, c1, c0, 0\n"   // 写SCTLR
        "DSB\n"
        "ISB\n"
    );
}

3.3 Cache一致性管理

Cache一致性，是驱动开发中的老大难问题。R-Car的Cortex-A57核心，L1 Cache是32KB，L2 Cache是2MB。如果驱动和DMA控制器同时访问同一块内存，数据就可能不一致。

举个例子：GPU渲染完一帧图像，放在DDR里。CPU去读取这个帧缓冲区，如果Cache里还存着旧数据，读到的就是残影。

解决办法？手动维护一致性。常用的API有：

• Clean Cache：将Cache中的数据写回内存。
• Invalidate Cache：将Cache中的标记为无效，下次访问时从内存重新加载。
• Clean & Invalidate：先写回，再标记无效。

下面是一个清理DMA缓冲区的函数：

void dma_buffer_clean_invalidate(void *addr, size_t size) {
    uint32_t start = (uint32_t)addr;
    uint32_t end = start + size;

    // 对齐到Cache Line大小（64字节）
    start &= ~0x3F;
    end = (end + 0x3F) & ~0x3F;

    for (uint32_t va = start; va < end; va += 64) {
        __asm volatile(
            "MCR p15, 0, %0, c7, c14, 1\n"  // Clean & Invalidate by MVA
            :
            : "r" (va)
            : "memory"
        );
    }

    DSB();
    ISB();
}

3.4 硬件寄存器访问封装

寄存器访问，是HAL最基础的接口。R-Car的寄存器是32位的，地址空间是32位对齐的。我建议封装成这样的接口：

// 读寄存器
static inline uint32_t reg_read(uint32_t addr) {
    return *(volatile uint32_t *)addr;
}

// 写寄存器
static inline void reg_write(uint32_t addr, uint32_t val) {
    *(volatile uint32_t *)addr = val;
}

// 置位寄存器中的某些位
static inline void reg_set_bits(uint32_t addr, uint32_t bits) {
    uint32_t val = reg_read(addr);
    val |= bits;
    reg_write(addr, val);
}

// 清除寄存器中的某些位
static inline void reg_clear_bits(uint32_t addr, uint32_t bits) {
    uint32_t val = reg_read(addr);
    val &= ~bits;
    reg_write(addr, val);
}

为什么用volatile？因为编译器会优化掉看似无用的读操作。加上volatile，告诉编译器：每次读都从内存取，别用缓存的值。

我个人习惯，在寄存器访问函数里加一个地址有效性检查。调试阶段打开，发布阶段关掉。这样既能发现问题，又不影响性能。

3.5 本章知识结构图

下面这张图，总结了HAL设计的核心逻辑：

3.6 避坑指南

最后，分享几个我踩过的坑：

• 地址对齐：R-Car的寄存器访问必须是32位对齐的。如果地址不是4的倍数，会触发对齐异常。
• Cache Line大小：A57的Cache Line是64字节。清理时一定要对齐到这个大小，否则可能漏掉数据。
• MMU页表位置：页表必须放在1MB对齐的地址上。我一开始放在0xE600_0100，结果MMU死活不工作。
• 寄存器备份：在修改寄存器前，先读出来备份。万一改错了，还能恢复。这个习惯救过我很多次。