背景RK3568 板卡eMMC 启动根文件系统 ext4 挂载在 eMMC p7 上。想直接在系统运行时dd新版本镜像升级到底行不行讨论结论是能不能 dd不取决于介质eMMC/NAND、文件系统类型或烧写工具只取决于一件事——dd 开始那一刻目标分区对运行中的系统是不是死的未挂载或只读挂载且无写回。一、为什么代码跑在 DDR 里还是不能直接 dd 正在用的分区上电时 U-Boot 把内核、dtb 读进 DDR内核再按需把 rootfs 的页读进内存——但rootfs 的本体始终在 eMMC 上运行期间内核持续和它交互可执行文件是 mmap 到 eMMC 块的内存不够时按页重读日志、数据库、临时文件在持续写回文件系统元数据inode、bitmap、journal在内核与磁盘间不断同步。直接 dd 覆写块设备会绕过文件系统层与上述写回并发几秒内就会把刚写的镜像冲坏还会造成元数据与数据错位。这不是 dd 命令的问题是边跑步边换腿。二、分区能不能在线 dd 的判定标准分区类型运行时的状态能否在线 dd说明uboot / kernel / dtb / boot裸镜像启动后不再读✅ 随时 dd对系统来说等同死盘system只读挂载ro 挂载无写回✅ 可 dd写完立刻重启无写回竞争但读竞争仍在dd 期间进程可能读到新旧混合的数据而崩溃userdata读写挂载rw 挂载持续读写❌ 必须先 umount 或借助 recovery 环境dd 与页缓存回写、journal 提交并发必然损坏多为静默损坏没异常只是没立刻暴露一句话dd 开始那一刻目标分区的块设备上除了 dd 之外还有没有别的写入者。有就不安全没有就安全。三、为什么 NAND 方案看起来能在线升级不是因为 NAND 工艺特殊而是架构决定的整系统跑在 RAMuboot 把内核 initramfs 全量加载进 DDRrootfs 不挂载在 NAND 上NAND 就是一块闲置盘随便擦写A/B 双分区当前跑 A 槽升级写空闲的 B 槽写完切启动标志 reboot——写 B 时系统对 B 没有任何 I/O。四、手机为什么能直接 dd手机 eMMC/UFS 是块设备不是 MTD机制与板子完全相同。刷机时 dd 的对象分两类boot / dtbo / vbmeta / recovery裸镜像分区系统运行时不挂载、不读取dd 天然安全system / vendor只读挂载ext4 ro 或 erofs内核不产生脏页、不提交 journal无写回竞争dd 完整覆盖后盘上就是完整新镜像。代价是 dd 进行中进程可能读到新旧混合的数据而崩溃所以dd 完马上重启。至于 userdata主流 Android 并不存在在线 dd 挂载中的 userdata 不出问题——凡是成功案例拆开看都是进 recovery dd那里 userdata 没挂载、先 umount 再 dd、或 dd 的是闲置分区/未用空间。remount,rw / 与 dd 安全性无关mount 的 ro/rw 是 VFS 层标志管的是路径读写dd 直接操作块设备完全绕过 VFS。remount,rw只是升级脚本自己要用文件接口写文件它既不保护也不妨碍 dd。五、eMMC 在线升级的正确姿势裸镜像分区uboot/kernel/dtb/boot任何时候可直接 dd。system 类只读分区dd ifsystem_new.img of/dev/mmcblk0pX bs4M convfsync reboot -f # 写完立刻重启缩短暂的新旧共存窗口userdata 类读写分区sync umount /data # 或mount -o remount,ro /datafuser -k 清理占用进程 dd ifuserdata_new.img of/dev/mmcblk0pY bs4M convfsync reboot -fdd 前用这几条确认目标分区已死cat /proc/mounts | grep mmcblk0 # 是否还挂着什么模式 lsof D /data | head # 谁还握着写句柄 cat /proc/meminfo | grep Dirty # 脏页是否已回写干净A/B 双槽是更稳妥的工程方案当前槽运行时把新镜像写空闲槽写完后改 uboot 环境变量切换启动槽。掉电安全升级中途断电环境变量没切仍从旧槽启动且无新旧共存窗口。六、几条配套纪律dd 完整写完后盘上才是成套的新镜像半截镜像 起不来的残次品升级包先校验 sha256 再开写加convfsync或 dd 后手动 sync确保数据真正落盘而非停在缓存eMMC 裸写偏移布局RK 平台512B 扇区idbloader 偏移 64、uboot 偏移 16384、trust 偏移 24576convnotrunc必须加否则 dd 会截断整块盘写 boot0/boot1 分区前记得解锁echo 0 /sys/block/mmcblk0boot0/force_ro动 uboot/trust/分区表等关键区域优先走 SD 卡启动或 Maskromupgrade_tool不要在线裸写正在运行的根设备。核心结论各种专用烧写工具recovery、upgrade_tool 等的全部意义就是创造一个目标分区不被挂载使用的环境——达到同样的物理状态后dd 和它们是等价的。判断安全性的唯一标准始终是dd 那一刻目标分区上除了 dd 还有没有别的 I/O。