如何用设备树科学划分Flash存储空间？一位嵌入式老手的实战笔记
你有没有遇到过这样的场景：同一款硬件主板，因为换了更大容量的Flash芯片，结果不得不重新编译内核？或者OTA升级时一不小心刷坏了Bootloader，整台设备直接“变砖”？
这些问题背后，其实都指向一个被低估但至关重要的技术——设备树（Device Tree）中的Flash分区配置。今天，我就以多年嵌入式开发经验，带你从工程实践的角度，彻底搞懂如何通过设备树实现灵活、安全、可扩展的Flash管理。
为什么我们不再硬编码Flash分区了？
早些年做嵌入式Linux项目时，Flash分区表都是写死在内核源码里的。比如在arch/arm/mach-xxx/common.c中定义一个mtd_partition数组：
static struct mtd_partition partitions[] = { { .name = "bootloader", .size = 0x40000, .offset = 0x0, }, ... };这看起来没问题，直到你要支持多个硬件版本。
一旦某款产品用了16MB Flash，另一款用了32MB，你就得为每种组合维护一套内核镜像。更麻烦的是，哪怕只是调整了一下rootfs大小，也必须重新编译整个内核——效率低、易出错、难维护。
于是，设备树登场了。
它把硬件描述从代码中剥离出来，变成可配置的数据结构。现在你可以只改一个.dts文件，就能适配不同容量、不同布局的Flash，而内核完全不用动。
这才是现代嵌入式系统的正确打开方式。
设备树是怎么让Flash“活”起来的？
它不只是“描述”，而是“建模”
很多人以为设备树就是个配置文件，其实不然。它是对硬件拓扑的声明式建模。
举个例子：你的SoC通过SPI控制器挂了一颗MX25L12835F（16MB NOR Flash），这个关系在设备树里是这样表达的：
flash@0 { compatible = "jedec,spi-nor"; reg = <0x0 0x1000000>; // 起始地址0，长度16MB (0x1000000) spi-max-frequency = <50000000>; ... };其中：
-compatible告诉内核：“我是一个标准的JEDEC SPI-NOR Flash”，从而匹配到spi-nor.c驱动；
-reg明确了物理地址和大小；
-spi-max-frequency设置通信速率。
当内核启动时，会自动加载对应的MTD驱动，并探测这颗Flash的存在。
⚠️ 小贴士：如果你发现
/proc/mtd没有输出，第一步先检查compatible字符串是否准确。常见的坑包括拼写错误或缺少厂商前缀。
分区不是“切蛋糕”，而是“画地图”
接下来最关键的部分来了：怎么划分这块16MB的空间？
传统做法像是在代码里硬切几块内存；而在设备树中，我们是在绘制一张逻辑地图。
看这个典型配置：
partitions { #address-cells = <1>; #size-cells = <1>; partition@0 { label = "bootloader"; reg = <0x0 0x40000>; read-only; }; partition@40000 { label = "environment"; reg = <0x40000 0x20000>; }; partition@60000 { label = "kernel"; reg = <0x60000 0x400000>; }; };这里的命名规则partition@<offset>不是随便写的。@后面的十六进制数表示该分区的起始偏移，确保每个节点唯一且有序。
系统解析后会生成如下设备节点：
$ cat /proc/mtd dev: size erasesize name mtd0: 00040000 00010000 "bootloader" mtd1: 00020000 00010000 "environment" mtd2: 00400000 00010000 "kernel" ...每一个/dev/mtdX都是一个独立的MTD设备，应用可以单独操作它们。
MTD：别小看了这个“原始接口”
有人可能会问：为什么不直接用块设备？还要搞个MTD子系统？
答案是——控制粒度。
Flash和硬盘不一样，它有“擦除块”的概念。NOR Flash通常按64KB扇区擦除，NAND则还有坏块管理的问题。如果走通用块设备层，很多底层特性就被屏蔽了。
而MTD提供的是对Flash的裸访问能力，你可以：
- 精确执行
ioctl(MEMERASE)擦除某个扇区； - 使用
mtd_write工具烧录固件； - 在
user-data区保存设备序列号、校准参数； - 挂载JFFS2这类专为Flash优化的日志型文件系统。
更重要的是，MTD与设备树深度集成。只要你在.dts里定义了分区，内核就会自动注册对应的mtd_info实例，无需任何额外代码。
实战技巧：这些“坑”我都踩过
1. 分区不对齐？性能暴跌！
曾经有个项目，我把kernel分区设成了0x50000开始，结果每次烧写都特别慢。查了半天才发现——没有对齐到擦除块边界！
大多数SPI-NOR Flash的擦除粒度是4KB或64KB。如果你的分区跨了两个擦除块，写操作就会触发“读-改-写”循环，效率极低。
✅最佳实践：所有reg的起始地址和长度尽量对齐到最大擦除块尺寸。例如使用64KB块，则偏移应为0x10000的倍数。
2. 多机型共用内核？靠的就是设备树
我们做过三款IoT网关，分别用8MB、16MB、32MB Flash。要是以前，得维护三个内核镜像。
现在呢？一份内核 + 三个.dts文件搞定。
比如针对32MB型号，只需修改顶层reg和最后一个分区：
reg = <0x0 0x2000000>; /* 32MB */ partition@1f00000 { label = "user-data"; reg = <0x1f00000 0x100000>; };构建系统根据目标平台自动选择对应设备树，真正实现“一次编译，到处运行”。
3. OTA升级怕失败？A/B双系统来兜底
想做安全升级？设备树也能帮你。
思路很简单：定义两套kernel+rootfs分区，标记当前激活的是哪一组。
partition@60000 { label = "kernel_a"; reg = <0x60000 0x400000>; }; partition@460000 { label = "rootfs_a"; reg = <0x460000 0xb00000>; }; partition@960000 { label = "kernel_b"; reg = <0x960000 0x400000>; }; partition@e600000 { label = "rootfs_b"; reg = <0xe600000 0xb00000>; };升级时写入B分区，验证成功后再通过U-Boot环境变量切换启动目标。即使断电也不会变砖。
这套机制已经成为工业级产品的标配。
4. Bootloader防篡改？只读属性安排上
最怕什么？黑客刷掉Bootloader，植入恶意代码。
解决办法也很直接：在设备树中标记关键区为只读。
partition@0 { label = "bootloader"; reg = <0x0 0x40000>; read-only; // 内核将拒绝对该区域的写入请求 };虽然用户空间仍可通过某些手段绕过（如直接映射物理内存），但这已经能挡住绝大多数误操作和初级攻击。
配合U-Boot的签名验证功能，安全性再上一层楼。
工程建议：别让细节毁了整体设计
| 项目 | 我的经验之谈 |
|---|---|
| 命名清晰 | 别用partition@0这种名字，label = "factory-config"才是人看得懂的 |
| 预留空间 | 即使当前用不满，也在末尾留出5%~10%未分配区，方便未来加功能 |
| 版本控制 | 把.dts当代码管，提交Git时写清楚“增加user-data分区用于日志存储” |
| 动态调试 | 测试阶段可用fdtput /sys/firmware/fdt ...动态修改DTB，快速试错 |
| 文档同步 | 维护一张表格，记录各机型的Flash布局，避免团队混淆 |
还有一个高阶玩法：设备树签名。用U-Boot的FIT image机制对.dtb进行RSA签名，防止恶意篡改硬件描述。这在金融、医疗类设备中尤为重要。
写到最后：设备树不是终点，而是起点
掌握设备树配置Flash分区，看似只是一个技术点，实则是通向现代化嵌入式开发的大门。
它背后体现的思想是：将静态耦合转为动态配置，将重复劳动交给自动化工具。
未来随着RISC-V生态的发展，以及Devicetree Overlay技术的成熟，我们甚至可以在运行时动态加载新的硬件描述，实现“可重构硬件”的雏形。
所以，下次当你面对一颗新Flash芯片时，别急着改驱动代码。先问问自己：这件事，能不能用设备树优雅地解决？
如果你正在搭建新项目，不妨试试从设备树开始设计存储架构。你会发现，系统的灵活性、可维护性和可靠性，都会提升一个量级。
如果你在实际项目中遇到Flash分区难题，欢迎在评论区留言。我们一起探讨解决方案。
