从设备树到DMA内存：手把手教你打通嵌入式驱动的关键一环
你有没有遇到过这样的问题？
明明代码逻辑没问题，但DMA传输就是失败——数据错乱、地址越界，甚至系统直接宕机。排查半天，最后发现是缓冲区内存被内核“偷偷”回收了。
这在高性能外设开发中太常见了：摄像头采集图像、网卡收发包、音频流实时播放……这些场景都依赖一块稳定、连续、可预测的物理内存作为DMA缓冲区。而现代Linux嵌入式系统里，这块内存从哪来？怎么用？靠的就是设备树 + 保留内存机制。
今天我们就来拆解这个“新手以为简单、老手不敢轻视”的核心技能：如何通过设备树定义并解析用于DMA的专用内存区域。
为什么不能直接kmalloc分配 DMA 缓冲？
先问个关键问题：既然内核提供了dma_alloc_coherent()，为什么不直接动态分配，非得搞个设备树节点这么麻烦？
答案很现实：
- 大块连续内存难申请：随着系统运行，物理内存碎片化严重，
kmalloc几乎无法成功分配几MB以上的连续页。 - 启动即需确定位置：某些硬件（如FPGA或DSP）固化了访问地址，必须提前规划好。
- 缓存一致性管理复杂：手动处理 cache flush/invalidate 容易出错，尤其在SMP或多级Cache架构下。
- 避免运行时延迟抖动：驱动初始化时突然申请大内存可能阻塞调度，影响实时性。
所以，更稳妥的做法是：在系统启动早期就划出一块“自留地”—— 这就是“保留内存”。
设备树里的“内存地图”：reserved-memory节点
想象一下，你在部署一个视频采集系统。传感器每秒产生上百兆原始图像数据，需要一块至少8MB的连续物理内存做环形缓冲。这块内存不能被任何人动，包括内核本身。
怎么办？打开你的.dts文件，加这么一段：
/ { reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; camera_dma_buf: region@80000000 { reg = <0x80000000 0x800000>; /* 128MB @ 2GB */ alignment = <0x100000>; /* 1MB 对齐 */ no-map; /* 不映射到内核虚拟地址空间 */ }; }; &camera { memory-region = <&camera_dma_buf>; status = "okay"; }; };就这么几行，完成了三件事：
- 在物理地址
0x80000000处预留了 128MB 内存； - 要求按 1MB 边界对齐（很多DMA控制器有此要求）；
- 告诉内核：“别给我建页表”，节省TLB资源。
⚠️ 注意：虽然叫“保留”，但它不会自动变成DMA可用内存！你还得在驱动里显式声明它是一块coherent DMA memory。
驱动怎么拿到这块“特权内存”？
现在轮到驱动登场了。我们的目标是从设备树中找到memory-region指向的那块内存，并把它变成CPU和外设都能安全访问的DMA缓冲区。
第一步：解析 phandle 引用
设备树允许节点之间互相引用，靠的是phandle。你可以把它理解为一种“指针”。当你写：
memory-region = <&camera_dma_buf>;实际上是在当前设备节点中插入了一个指向camera_dma_buf的句柄。
在驱动中，我们要把这个“指针”解开：
struct device_node *mem_np; mem_np = of_parse_phandle(np, "memory-region", 0); if (!mem_np) { dev_err(dev, "missing 'memory-region' property\n"); return -EINVAL; }如果返回 NULL，说明设备树没配或者拼错了名字。这是最常见的低级错误之一。
第二步：获取物理地址与大小
拿到device_node后，下一步是提取它的地址信息。这里要用到of_address_to_resource()：
struct resource res; if (of_address_to_resource(mem_np, 0, &res)) { dev_err(dev, "failed to get reserved memory address\n"); return -ENODEV; } phys_addr_t phys_base = res.start; size_t size = resource_size(&res); dev_info(dev, "Got reserved memory: %pa+%zx\n", &phys_base, size);注意：这里的res.start是物理地址，不是虚拟地址。你不能直接 dereference 它！
第三步：要不要映射成虚拟地址？
取决于你的使用模式：
| 使用方式 | 是否需要 ioremap | 典型场景 |
|---|---|---|
| CPU 只配置头尾，DMA 自己搬数据 | ❌ 不需要 | 网络报文接收环 |
| CPU 需要预填缓冲或后期处理 | ✅ 需要 | 图像算法前处理 |
如果你需要CPU读写，那就映射一下：
void __iomem *virt_base = ioremap(phys_base, size); if (!virt_base) return -ENOMEM;但如果设备树里写了no-map，那你就要格外小心——这意味着这片内存压根没有建立页表项，强行映射会失败。
第四步：告诉内核：“这是我的DMA内存！”
最关键的一步来了：调用dma_declare_coherent_memory()。
if (!dma_declare_coherent_memory(&pdev->dev, phys_base, // 物理地址 phys_base, // 总线地址（通常等于物理地址） size, DMA_MEMORY_EXCLUSIVE)) { dev_err(&pdev->dev, "failed to declare coherent DMA memory\n"); return -ENOMEM; }这一招的作用是：
- 让
dma_alloc_coherent()知道可以从哪里取内存； - 自动处理 cache 一致性（无需手动 flush）；
- 标记该区域已被占用，防止重复声明。
🛠️ 小贴士：
DMA_MEMORY_EXCLUSIVE表示独占；若允许多设备共享（极少见），可用DMA_MEMORY_SHARED。
实战调试技巧：怎么确认内存真的“保留”了？
写完了代码，怎么验证效果？别急着上电跑，先看这几处：
1. 查看/proc/iomem
系统起来后执行：
cat /proc/iomem | grep "reserved"你应该能看到类似输出：
80000000-87ffffff : System RAM, reserved 80000000-87ffffff : camera_dma_buf如果有，说明保留成功；如果没有，检查.dts是否正确编译进.dtb。
2. 用fdtdump或dtc -I dtb -O dts反编译 DTB
有时候你以为DTS改了，其实没进镜像。反编译一下最保险：
fdtdump -s system.dtb | grep camera_dma_buf确保节点存在且属性完整。
3. 加日志打印物理地址
在 probe 函数里加一句：
dev_info(dev, "DMA buffer mapped at physical %pa\n", &phys_base);然后串口抓日志，比对是否符合预期布局。
常见坑点与避坑指南
❌ 坑一：地址冲突导致系统崩溃
新手常犯的错误是把保留内存放在内核加载区（比如低于64MB）。结果刚启动就被覆盖了。
✅ 正确做法：
- 查阅 SoC 手册，避开 ROM、SRAM、kernel image、initrd 区域；
- 推荐起始地址 ≥ 512MB；
- 使用mem=参数限制可用内存测试边界。
❌ 坑二：忘了声明 coherent memory，导致 cache 错乱
即使你拿到了物理地址，如果不调用dma_declare_coherent_memory()，那么后续用dma_pool_alloc()或dma_alloc_coherent()仍可能失败或行为异常。
✅ 必须步骤：
-of_parse_phandle→of_address_to_resource→dma_declare_coherent_memory
顺序不能乱。
❌ 坑三：误用no-map却又尝试 ioremap
no-map的含义是“不要建立虚拟映射”。如果你设置了它，却又调用了ioremap()，就会失败。
✅ 解决方案：
- 若需CPU访问，去掉no-map；
- 若仅硬件访问，保留no-map，但不要映射，只将物理地址传给外设寄存器。
更进一步：支持 fallback 到 CMA
理想情况下我们希望用固定地址保留内存，但为了兼容不同板型，可以设计降级策略：
/* 尝试从设备树获取保留内存 */ if (of_find_property(np, "memory-region", NULL)) { if (setup_reserved_dma_memory(pdev) == 0) return 0; /* 成功则退出 */ } /* 否则 fallback 到 CMA 动态分配 */ dev_info(&pdev->dev, "Falling back to CMA allocation\n"); return setup_cma_dma_buffer(pdev);这样既能保证高端平台性能最优，也能让低端开发板跑起来。
总结：打通“设备树 → 内存 → DMA”的任督二脉
看到这里，你应该已经明白：
- 设备树不是装饰品，它是现代嵌入式系统的“硬件说明书”；
- 保留内存不是可选项，而是大吞吐量外设的刚需；
memory-region+phandle是连接设备与资源的桥梁；dma_declare_coherent_memory是开启高效DMA的大门钥匙。
这套机制不仅适用于摄像头、网卡，也广泛应用于 FPGA通信、AI加速器、工业总线控制器等场景。
更重要的是，它代表了一种思维方式：把资源管理和硬件描述交给系统去完成，而不是靠硬编码“蒙混过关”。
当你下次面对一个新的SoC平台时，不妨先问自己三个问题：
- 我的DMA缓冲有多大？是否需要提前保留？
- 物理地址范围是否受限制？要不要对齐？
- CPU要不要参与数据处理？是否需要映射？
想清楚这三个问题，再动手写DTS和驱动，你会发现，原来那些玄乎其玄的“底层问题”，其实都有章可循。
如果你正在调试DMA却始终不成功，不妨留言说说你的设备类型和现象，我们一起分析是不是内存配置出了问题。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
