UFS

UFS（Universal Flash Storage，通用闪存存储）是面向移动和嵌入式设备的高性能托管式闪存存储标准，和 eMMC 一样内部包含 NAND Flash 与闪存控制器，但使用 MIPI M-PHY、UniPro、SCSI 命令模型和 UFSHCI 主机控制器接口来提供更高带宽、更好并发和更细的功耗管理。

一句话说，UFS 常被看作 eMMC 的高性能替代方案：它仍是“带控制器的 NAND 块设备”，但主机接口和协议栈更接近现代高速存储。

核心问题

eMMC 成本低、生态成熟，但其并发和带宽能力有限。移动设备、AI 边缘设备和高端嵌入式平台需要：

更快的顺序读写，用于系统启动、应用加载和大文件访问。
更好的随机 I/O，用于数据库、应用缓存和多任务。
命令队列和任务管理能力，让多个请求并发排队、取消、恢复。
更高效的全双工链路，减少读写互相阻塞。
更细的功耗状态，兼顾高性能突发和移动设备待机功耗。

UFS 用更接近高性能存储协议的方式解决这些问题。

核心对象

对象	含义	工程关注点
UFS host	SoC 侧主机和驱动	UFSHCI、DMA、时钟、reset、电源域、错误恢复
UFS device	存储芯片	NAND、闪存控制器、FTL（闪存转换层）、LUN、RPMB
MIPI M-PHY	物理层	lane 数、gear 档位、参考时钟、信号完整性
UniPro	链路/互连协议	连接建立、可靠传输、流控、电源状态
UIC	UFS Interconnect Layer	把 UFS 上层连接到 UniPro/M-PHY
UTP	UFS Transport Protocol	用 UPIU 承载命令、响应和任务管理
UCS	UFS Command Set	基于 SCSI 命令模型处理读写和查询
LUN	Logical Unit Number	boot LUN、user LUN、RPMB LUN、逻辑隔离
descriptor / attribute	设备描述和属性	容量、健康、配置、功耗状态、boot 配置

核心机制

UFS 采用分层通信模型。主机侧一个块 I/O 请求通常会经过：

block request
  -> SCSI command
  -> UPIU
  -> UTP transfer request
  -> UniPro packet
  -> M-PHY signal
  -> UFS device controller
  -> FTL / NAND
  -> completion UPIU

块层提交请求：文件系统或应用间接发起读写，内核块层生成 block request。
映射成 SCSI 命令：UFS 在软件栈中使用 SCSI 架构模型，例如读写可表达为 READ / WRITE 类命令。
封装为 UPIU：UFS Transport Protocol 把命令、数据方向、任务管理或查询操作封装成 UPIU。
主机控制器执行传输：UFSHCI 管理 transfer request list、doorbell、中断和 DMA buffer。
链路层传输：UniPro 负责可靠传输和链路管理，MIPI M-PHY 把数据转换成高速串行电信号。
设备内部调度：UFS device 根据队列、LUN、功耗状态和内部负载调度请求。
NAND 访问：控制器通过 FTL（闪存转换层）把 LBA 映射到 NAND 物理页，处理 ECC（错误纠正码）、磨损均衡、坏块管理和垃圾回收。
完成响应：设备返回 completion UPIU，主机控制器中断或轮询通知内核，请求完成。

UFS 仍然是托管式闪存，不会消除 NAND 的物理限制；它只是提供了更高效的主机接口和设备内部调度空间。

最小模型

可以把 UFS 的吞吐能力粗略拆成三层：

effective_io = min(link_capacity, device_internal_capacity, host_stack_capacity)

link_capacity 是 M-PHY lane、gear 和编码效率决定的链路上限。
device_internal_capacity 是 NAND die 并行度、FTL、缓存、热状态和后台垃圾回收决定的设备内部能力。
host_stack_capacity 是 UFS host controller、DMA、内核块层、文件系统、加密和 CPU 调度决定的主机侧能力。

所以 UFS 规格更高不自动等于应用更快。如果瓶颈在文件系统同步写、dm-crypt、CPU 解压、热降频或应用小随机写，标称接口速率不会直接兑现为体验提升。

工程用途

高端手机、平板、车载设备和高性能嵌入式 Linux 平台。
系统启动、应用加载、模型文件读取、日志和数据分区。
需要更高 I/O 性能或更好并发的边缘 AI 和多媒体设备。
安全启动、防回滚和 TEE 状态存储场景中的 RPMB 类安全区域。

调试 UFS 时常看：

host controller probe 是否成功，设备树/ACPI 里的 clocks、resets、regulators、PHY 是否匹配。
M-PHY link startup 是否成功，gear/lane/PWM/HS mode 是否进入预期档位。
LUN 是否枚举出正确的 boot/user/RPMB 设备。
dmesg 中是否有 UIC error、device fatal、host fatal、task abort、link recovery。
fio、启动时间、应用加载时间和尾延迟是否符合预期。
温度、电源状态切换和 throttling 是否影响持续性能。

Linux 中 UFS host controller driver 通常接入 SCSI midlayer，块设备可能表现为 /dev/sdX 或平台相关路径；调试低层协议时还可能用到 /dev/ufs-bsg 交换 UPIU。

与 eMMC 的边界

维度	eMMC	UFS
抽象	托管式 NAND 块设备	托管式 NAND 块设备
物理/链路	MMC/eMMC 总线	MIPI M-PHY + UniPro
协议模型	MMC 命令集	SCSI 架构模型 + UTP/UPIU
并发	较弱，适合成本优先平台	更强，适合多任务和高吞吐平台
bring-up 难点	EXT_CSD、boot 分区、MMC host、写保护	PHY/link startup、UFSHCI、LUN、功耗状态、错误恢复
成本与复杂度	通常更低、更成熟	通常更高，对板级和驱动要求更高

边界与常见坑

UFS 不是裸 NAND：它和 eMMC 一样隐藏了 NAND 管理细节。
UFS 不是 NVMe：两者都可能很快，但 UFS 面向移动/嵌入式托管闪存和低功耗链路，NVMe 面向 PCIe 存储生态。
UFS 不总是必要：低成本、低写入压力、低带宽设备用 eMMC 可能更合适。
协议更快不代表系统一定更快：瓶颈可能在 CPU、文件系统、应用加载、加密或热限制。
板级和驱动要求更高：高速 PHY、供电、时钟、信号完整性和内核驱动都更敏感。
仍要管理写放大和寿命：日志策略、分区余量和掉电保护仍然重要。
功耗状态切换会影响延迟：深睡、省电和高性能档位之间的切换如果策略不合适，会出现尾延迟毛刺。
LUN 不是物理芯片：多个 LUN 可以来自同一颗 UFS device 的逻辑划分，不要把它误解成多个独立硬盘。

Sean's Blog

探索

UFS