UFS 学习笔记（概念入门篇）

笔者作为初次学习存储协议的学生，在目前水平下无法假设出您作为已经拥有何种基础的朋友，但会持续的对文章进行修正完善，以确保您能容易的从本文中理解相关术语或通过 bing 搜索引擎准确的查找到该术语的解释。

由于笔者期望本文内容尽可能的全面，除非您已经对该章节主干理解，否则建议第一次阅读时跳过引用内容，以避免被引用的内容带偏主干而造成理解困难。建议阅读完该章节包括引用在内的所有内容后再跳到下一章节。

其次，本文也是在借鉴各位前辈撰写的，一些术语可能被遗漏未统一或与协议相比过分缩写或缩写但未在第一次提及时标注全程，恳请各位朋友发现后不吝赐教。

最后，笔者个人的学习感受觉得协议手册是学习 UFS 协议的重要工具，笔记只能作为参考和引路人，除了遇见问题要去手册中寻找准确解释外，不建议在笔记中将一些关键性的术语翻译以避免意译不准确引发的错误，如果您发现文中有哪些地方过分翻译也请麻烦指出。

经过固态技术协会（Joint Electron Device Engineering Council，JEDEC）不断对 eMMC 协议的完善，eMMC 5.1 发布后因为无法继续提高其传输速度，JEDEC 于 2011 年发布了 UFS 1.0 协议，尽管 UFS 1.0 相比较同时期的 eMMC 并没有实质上的优势，但由于 UFS 协议基础优秀，随着时代逐步发展，UFS 2.1 相比较 eMMC 已经形成绝对压倒性优势，奠定了 UFS 协议未来成为存储技术主流的地位：

UFS 之所以可以如此之快的原因在于：

要让 UFS 速度快，这些基础设施是必须的。但要充分利用底层高速数据传输通道，还需要上层数据传输协议配合：

UFS 协议更像是一个整合者，重新定义的东西不多，Application Layer 主要是将 SCSI 规范搬过来，下面的 M-PHY 和 UniPro 则直接挪用 MIPI 标准的部分，优点当然显而易见，处理不用担心以往优秀且成熟协议的稳定性外，也同时大大减少重新设计硬件的工作量。

UFS 应用层由基于 SCSI 体系结构模型 （SAM） 的 UFS SCSI 命令集组成：

UFS 设备有若干个 LU，LU 接收主机发过来的命令或请求可能来自应用层的 SCSI 模块、设备管理器或者任务管理器：

每个 LU 都是独立的，“独立”表现在下面几个方面：

总结来说，划分不同 LU 有以下作用：

一个 UFS 设备最多可以有 32 个逻辑单元用来存储用户数据的，此外可能有 4 个知名逻辑单元 （Well Known LU）：

各个 LU 相对地址如下：

UFS 传输层的事务由称为 UFS 协议信息单元 （UPIU） 的数据包组成，主机是启动器，设备是目标。有不同类型的 UPIU 用于处理 SCSI 命令、数据操作、任务管理操作、查询操作等。每笔交易包括：

在这一层中主机和设备的交互如下：

UFS 架构以 HCI（Host Controller Interface，主机控制器接口）为界划分为三部分。如下图，蓝色框上方调用 HCI 的为主机软件部分，蓝色框下方的为 HCI 封装的硬件处理细节部分，即 HC（Host Controller，主机控制器） ：

数据结构服务于软件，主机的软件通过内存中的一系列主机 register 和数据结构 Transfer Request Descriptors 来与 Host controller 硬件进行交互。UFSHCI 定义了两种接口：IO Memory/Registar Space 以及 Host Memory Space，下图展示了 UFS HCI 的框图：

IO Memory/Registar Space：在这个空间，主机 register 被定义为主机的软件接口，通过 MMIO[4]（Memory-Mapped I/O，内存映射 I/O）的方式被实现，主要包含了下面三种类型的寄存器：

Host Memory Space：该空间中包含了能够描述将执行命令和命令中数据缓存的数据结构。简单地可以理解为——UTP Transfer Request List 负责通用的 IO 命令，UTP Task Mangement Request List 负责管理命令。

当传输请求完成（成功或出错）时，主机控制器将相应的位清除为“0”。

主机控制器始终按照提交到列表中的顺序有序处理传输请求。在批处理模式下，如果多个命令使用单个门铃寄存器进行触发，主机控制器对这些传输请求的调度顺序将基于它们在列表中的索引。具有较低索引值的传输请求将在具有较高索引值的传输请求之前执行。

当主机软件将 UTRLRSR 从“1”写入为“0”时，该字段也会被清除。

相应数据结构体具体在代码中的表示如下：

UFS Task Management 在代码中的表示如下：

UFS 的 host system 由一些硬件（host controller）和软件层组成（host software）：

为了管理 host software 和 UFS 设备间的通信，host controller 为 host software 发送出传输请求提供了 3 个独立的接口：

主机 register 是通过 MMIO 存在于 IO Memory/Registar Space 中，寄存器访问以8字节对齐，最大大小为 64 位，其类型分为五种：

host software 对于 UFS HCI 的操作又分为三部分：Host controller配置和控制，数据传输操作，任务任务管理。

UPIU 是命令、数据和状态信息传输的载体，是 UFS 协议栈的灵魂。UPIU 是有固定格式的数据包，我们分析数据包格式，有助于我们更深的理解 UPIU 以及整个 UFS 协议。在学习 UPIU 数据包之前我们先回顾下数据在 UniPro 各个层级之间是如何层层封装和解包的，意义并不是说 UniPro 中的数据包与 UPIU 数据包有什么对应关系，因为事实恰恰相反，回顾的意义是将我们之前学习的这些概念放在一边，以避免与我们将要学习的概念搞混：

每个 UPIU 都有一个 12 字节的 Header，再加上跟每个 UPIU 相关的域。一个 UPIU（包括 Header）最小为 32字节，最大为 65600 字节：

通用的 Header 体如下：

总结通用的 Header 体各个域功能如下，如果需要对各种 UPIU 做更详细的域了解请参见《JESD220E》10.7 UFS Protocol Information Units：

一个命令或者请求的执行包含下面几个阶段：

在命令执行过程中，无论是处在哪个阶段，UFS 主机和设备间都是通过 UPIU 进行信息的交互：

4.2.1 命令/请求UPIU

应用层包括 UFS 命令、设备管理器和任务管理器三个模块，传输层根据不同模块发来的命令或者请求，分别产生不同类型的 UPIU：

4.2.2 数据传输相关UPIU

4.2.3 状态UPIU

前面看到，主机有三种请求：SCSI 命令，任务管理器发出的 Task Management Request，以及设备管理器发出的 Query request。针对不同的命令或者请求，设备在执行完相应的任务后，分别返回对应的状态UPIU给主机。

4.2.4 其它UPIU

除了以上常规的 UPIU，还有其它一些 UPIU 作为他用：

4.3.1 例子一：主机往设备读取96KB数据

主机先发送读 96KB 数据的命令给设备，然后设备执行命令，分了三批把数据返回给主机，最后返回命令执行状态给主机：

4.3.2 例子二：主机往设备写64KB数据

主机发送写 64KB 数据的命令给设备，然后在那里等设备回应。当设备说你可以传来 24KB 数据时，主机写 24KB数据给设备；接着，设备又来通知说可以继续传 32KB 数据，主机照做。最后，设备通知说可以把最后 8KB 数据也传过来，主机于是写最后 8KB 数据。最后，主机收到设备命令执行完成的回应。主机必须等收到 RTT 后才能启动数据传输。

UFS 目前没有定义自己的命令，使用简化的SCSI命令。本节将介绍常用的 scsi 协议命令，如您遇到相关问题需要深入查询域名时建议再阅读《JESD220E》详细了解。

INQUIRY

inquiry 命令用于查询 device 的一些关键信息，例如设备制造商，产品名称，FW 版本号等，通常 host 上电启动时会下发 inquiry 命令获取设备信息，针对不同厂商的器件可能会使用不同的配置项（参见《JESD220E》11 UFS Application (UAP) Layer – SCSI Commands）。

REPORT LUNS

report luns 命令用于向 host 上报当前 device 中使能的 normal lun 的 lun ID，以及 device 中支持的 Well Known LU 的 lun ID。

READ CAPACITY(10)

读取指定逻辑单元的容量和部分配置信息。协助存储管理软件确定是否在 CDB 中描述的逻辑块地址起始有足够空间，包含频繁访问的数据结构，避免引起额外的延迟。

REQUEST SENSE

request sense 命令用于查询指定的 lun 是否存在 sense data（提供有关先前执行的 SCSI 命令的详细错误信息），如果有的话会通过 data in UPIU 返回给主机。同时 request sense 命令可以清除 device 复位产生的 UAC（Unit Attention Condition，单元注意条件）标记，并且命令不会报失败（可能这才是 host 发 request sense 的主要目的）。

TEST UNIT READY

作用是查询设备是否 ready。空闲的时候，主机就会发送 test ready 命令下来，这个命令不用回复和应答数据，如果已经 Ready 只要回复 GOOD 即可。如果设备无法运行或处于需要主机操作以准备就绪的状态，设备应返回 BUSY。

SEND DIAGNOSTIC

host 下发 send diagnostic 命令让 device 执行指定的自检操作。但是 host 并不能判断 device 是否真的正确的执行了自检，换句话说 host 无法感知自检结果，所以对于 device 而言此功能可有可无。

READ(10)

read 命令包含 read(6)/read(10)/read(16)，不同的 read 命令 LBA 的寻址范围存在区别。主机下发读命令读取指定 LBA 的数据，device FW 会通过 FTL 映射表获得指定 LBA 对应的物理地址，然后读取相应数据返回给主机。

WRITE(10)

write 命令包含 write(6)/write(10)/write(16)，不同的 write 命令 LBA 的寻址范围存在区别。主机下发写命令修改指定 LBA 的数据，device 将数据写入到 flash 之后需要修改 FTL 映射表（flash 无法在有数据的地址上覆盖写）。

UNMAP

主机下发 unmap 命令要求 device 清除某个 LUN 中指定 LBA 的数据，实际上只会修改映射表。根据 LU 中bProvisionType 的不同，unmap 命令被分为erase和discard两种操作。其中erase要求 host 读取经过unmap 的 LBA 时返回全 0，而discard则返回随机值。

FORMAT UNIT

格式化指定逻辑单元，如果指定了 device Well Known LU，则将格式化全盘。实现上与 UNMAP 命令相似。

SYNCHRONIZE CACHE(10)

将 device 中指定 LBA 的数据下刷到 flash 中，也可以将 buffer 中所有数据一起下刷，因为 host 无法预期哪些数据会缓存在 device buffer 中。

VERIFY(10)

下发 verify 命令校验指定 LBA 中的数据能否被正常读出。校验数据，请求设备 server 端检验指定媒介上的逻辑块。基于 VRPROTECT 字段和媒介格式，每个逻辑块都包含用户数据，并可能包含保护信息。

START STOP UNIT

用于调整 device 的电源状态以及指定 LU 的启动与关闭。在调整 device 电源状态的场景中，start stop unit 命令与硬件平台息息相关，不同的 UFS 设备硬件资源不同，需要执行的操作也并不相同。可以通过 query 配置上电启动时的电源状态。如果设备 server 端正在处理该命令，后续有确认过的 CDB 请求逻辑单元执行启动/停止单元命令更换电源状态的话，设备 server 端应中断后续的启动/停止单元命令。

如果参考引用了您的创作却未署名，请一定联系我添加，给您添麻烦了！