ufs2.2 协议扫盲(三)

五、 UFS ARCHITECTURE OVERVIEW
UFS communication is a layered communication architecture. It is based on SCSI SAM architectural model [SAM].

ufs2.2 协议扫盲(三)_第1张图片

5.1、应用层由UFS命令集(UCS)、设备管理器和任务管理器组成。
 UCS 将处理正常的命令,如读取、写入等。 UFS 可能支持多个命令集。 UFS 旨在与协议无关。 此版本 UFS 标准的命令集 基于 SCSI 命令集。 特别是,为 UFS 选择了一个简化的 SCSI 命令集。 当需要扩展 UFS 功能时,可以支持 UFS Native 命令集。
 任务管理器处理用于命令队列控制的命令。
 设备管理器将提供设备级别的控制,如查询请求和较低级别的链路层控制。

5.2、设备管理器有以下两个职责:
 处理设备级操作。包括设备电源管理、与数据传输相关的设置、后台操作启用和其他设备特定操作等功能。
 管理设备级配置。比如处理一些Descriptors, Flag,Attr。处理诸如查询请求之类的命令,这些命令允许修改或检索设备的配置信息。

5.3、Service Access Points:
ufs2.2 协议扫盲(三)_第2张图片 ufs2.2 协议扫盲(三)_第3张图片

 UDM_SAP(Ufs Device Manager Service Access Points) 是 UTP(就是上图中的ufs传输协议层符合SAM标准)为设备管理器公开的服务访问点,以允许处理设备级操作和配置。 例如,对描述符的查询请求的处理将使用此服务访问点来完成。UDM_SAP对应UFS UTP层定义的Query Request(如下图可以读写ufs配置的功能)和Query Response功能。
ufs2.2 协议扫盲(三)_第4张图片

 UIO_SAP是UIC层暴露的服务接入点,通过对UIC层的DME管理器提供的服务,对设备触发UIC层的复位,并传递与UIC管理功能相关的请求和响应。在 UniPro 中,UIO_SAP 对应DME_SAP。 DME_SAP 提供服务原语,包括一个用于重置整个 UniPro 协议栈和一个用于 UFS 设备重置等。 DME_RESET :当 UniPro 堆栈必须重置时使用。 DME_ENDPOINTRESET:当 UFS 主机希望 UFS 设备执行重置时使用它。 
ufs2.2 协议扫盲(三)_第5张图片

5.4、UFS Transport Protocol Layer:
UFS 传输协议 (UTP) 层为更高层提供服务。 UPIU 是“UFS 协议信息单元”,它在 UFS 主机和 UFS 设备的 UTP 层之间交换。 例如,如果主机端 UTP 收到来自应用层或设备管理器的请求,UTP 会为该请求生成一个 UPIU,并将生成的 UPIU 传输到 UFS 设备端的对等 UTP。 UTP 层提供以下三个接入点。 1) UFS 设备管理器服务访问点 (UDM_SAP) 执行设备级管理,如描述符访问。 2) UTP 命令服务接入点 (UTP_CMD_SAP) 传输命令,比如读写ufs上的数据。 3)UTP任务管理服务(ufs中的正在进行的task,利用这个接入点,可以对Task的优先级进行调整)接入点(UTP_TM_SAP)传输任务管理 功能类似于“中止任务”功能。
5.5、UFS Interconnect Layer:
最低层是 UFS 互连层 (UIC),它处理 UFS 主机和 UFS 设备之间的连接。 UIC 由 MIPI UniPro 和 MIPI M-PHY 组成。 UIC 为上层提供了两个服务接入点。 UIC 服务接入点 (UIC_SAP) 在 UFS 主机和 UFS 设备之间传输 UPIU。 UIC_SAP 对应 UniPro 中的 T_SAP。 UIC IO 控制服务访问点 (UIO_SAP) 来管理 UIC。 UIO_SAP 对应于 UniPro 中的 DME_SAP。以下是unipro中的结构,数据流的堆栈。 如果设备 A 的应用程序需要向设备 B 的应用程序发送数据,则数据将通过 T_SAP(传输层服务接入点) 传递到传输层(L4),传输层(L4)将数据通过 N_SAP 传递到网络层(L3),后者通过 数据通过 DL_SAP 到数据链路层 (L2),数据链路层通过 PA_SAP 将数据传递到 PHY 适配器层 (L1.5),后者通过属于 PHY 的接口将数据传递到 PHY 层 (L1)。 PHY 通过线路(“媒体”)与另一个 PHY 通信。 在设备 B,数据以相反的顺序向上传递相应的堆栈层。
ufs2.2 协议扫盲(三)_第6张图片

在unipro中对T_SAP(CPort 信号接口)的实现进行了描述。目前,定义了两个供应用程序使用的外部接口,CPorts (T_SAP) 和 DME_SAP。 在本规范的未来版本中可能会添加用于特殊目的的附加接口,例如安全协议。 例如,传输层根据定义提供由 T_SAP 接口公开的功能。 在概念层面,两端的 L4 逻辑实现了一个协议,提供相应 T_SAP 接口对定义的服务。 这个 L4 协议显然需要某种数据交换。 在 L4 级别,这些数据交换单元称为 L4 协议数据单元(或 T_PDU)。 因此,L4 规范的一部分将 T_SAP 原语映射到对等设备之间的 T_PDU 单元交换。

5.6、UFS System Model:
ufs2.2 协议扫盲(三)_第7张图片

UFS 主机由希望与 UFS 设备通信的应用程序组成。它使用 UFS 驱动程序与设备通信。 UFS 驱动程序旨在通过 UFS HCI(UFS 主机控制器接口)管理 UFS 主机控制器。 UFS HCI 基本上是主机控制器公开的一组寄存器。图 5-4 还显示了 UFS 主机和 UFS 设备之间的 UFS 接口。 UFS 互连 (UIC) 层由 MIPI UniPro 和 MIPI M-PHY 组成。物理层 M-PHY 是 差分、双单工 PHY,包括 TX 和 RX 对。潜在的 UFS 设备可以是存储卡(全尺寸和微型尺寸)、嵌入式可引导大容量存储设备、IO 设备等。 UFS 设备由多个逻辑单元、设备管理器和 描述符。设备管理器执行设备级功能,例如电源管理,而逻辑单元执行读取、写入等功能。描述符用于存储配置 相关信息。

5.7、System Boot and Enumeration:
当 UFS 互连层(MIPI M-PHY 和 UniPro)完成其启动序列后,系统将从可启动 UFS 设备启动。 启动代码可以从 适当的引导逻辑单元被读,或者根据需要,可以在读取boot code之前,用boot ROM code将 MIPI M-PHY 和 UniPro 重新配置为适当的设置。 一个 UFS 设备中可能有多个引导逻辑单元。 然而,只有一个引导逻辑单元在加电时处于活动状态。 适当的描述符可用于配置引导过程。在引导期间,通过 SCSI 命令支持对引导逻辑单元的访问。

5.8、UFS Interconnect (UIC) Laye:
UFS互连层由MIPI UniPro组成,提供向上层(UTP)的基本传输能力,MIPI M-PHY作为UFS物理层。

5.9、UFS Physical Layer Signal:
UFS 物理层定义了连接 UFS 设备和 UFS 主机的 UFS 接口的物理部分。 这是基于 MIPI M-PHY 规范。 UFS 接口可以支持每个方向的多个通道。 每个通道由一个差分对组成。 基本配置基于一个发送通道和一个接收通道。 可选地,UFS设备可以支持两个下行通道和两个上行通道。 每条链路应提供相同数量的下行和上行通道。 下表总结了 UFS 设备所需的信号。 只有单车道,每个方向,每个链接, 配置。
ufs2.2 协议扫盲(三)_第8张图片

参考时钟:参考时钟 所有 UFS 器件通用的相对低速时钟,用作每个器件中 PLL 的参考。  
差分线路,硬件reset信号。

5.10、MIPI UniPro:
在 UFS 中,UniPro 负责管理链路,包括 PHY。 注:设备管理不在互连层的范围内,由上层负责。 互连层的基本接口是 UniPro 定义的 CPort。 CPort 用于所有数据传输以及控制和配置消息。 通常,一个设备上可以支持多个 CPort,并且 CPort 的数量取决于厂家实现。 通过 UniPro 链路发送的流量可归为 TC0 或 TC1 流量类别,其中 TC1 为更高优先级的流量类别。 此版本的 UFS 标准仅使用单个 CPort 和 TC0 流量类别。 UFS 利用 UniPro 服务的基本类型。 这些包括数据传输服务和配置/控制/状态服务。 

5.11、MIPI UniPro 相关属性:
一般来说,与 UniPro 相关的属性、值和它们的使用在 MIPI UniPro 规范中定义。 这些属性对于所有 UniPro 应用程序可能是通用的,因此超出了ufs协议的范围 文档。 ufs2.2中专门为 UFS 应用定义了以下属性,如所示 见表 5-2。
ufs2.2 协议扫盲(三)_第9张图片

下图来自unipro协议中对,通道的属性值的描述,这些对应用层都是通用的,上述的DME_ManufacturertID和DME_DeviceClass都是ufs上特有的。
ufs2.2 协议扫盲(三)_第10张图片

5.12、UFS Transport Protocol (UTP) Layer :
 传输层负责将协议封装到互连层(UIC)的恰当的帧结构中。 UFS 与协议无关,因此任何协议都需要适当的转换层(必须符合unipro的接口要求,才能使数据流到另一个设备上)。 对于这个版本的 UFS 标准,这是 UTP(UFS 传输协议)层。在此版本的标准中,所有访问被支持仅通过 SCSI,但是在未来版本中可能会添加其他 API/服务/扩展以引入新功能或特定地址 要求。
 UTP 的一个设计特点是提供灵活的数据包架构,帮助 UFS 控制器将封装的命令、数据和状态数据包导入和导出系统内存目的是允许在主机系统内存和 UFS 设备之间快速传输数据,而主机处理器的干预最少。(这一层就是为了方便ufs主机控制器脱离unipro的协议帧,与UTP建立自己的联系,记载一个博文:UFS Host Controller工作流程_Frank_sample的专栏-CSDN博客) 一旦在主机内存中设置数据结构并通知目标设备,整个命令事务就可以在 UFS 设备和主机内存之间进行。 UFS 控制器通过硬件和/或固件机制将数据传入和传出主机内存的方式不在ufs协议中。 有关详细信息,在ufs控制器寄存器文档中(文档中有例如utrd等数据结构)。
 UTP 设计的第二个特点是,一旦设备收到来自主机的命令请求通知,该设备将控制满足数据传输和请求状态完成所需的起搏和状态转换。 这里的想法是设备知道其内部条件和状态,以及何时以及如何最好地传输构成请求的数据。 主机系统或控制器没有必要持续轮询设备以获取“就绪”状态或主机估计何时开始数据包传输。 设备将在确定其条件和状态最佳时启动总线事务。 这种方法减少了主机内与设备通信所需的固件和逻辑。 它还以完成操作所需的最少总线事务数提供最大可能的吞吐量。

5.13、Architectural Model and Client-Server Model
 SCSI 架构模型 [SAM] 用作 UTP 的通用架构模型。 SAM 架构是客户端-服务器模型,或者更常见的是请求-响应架构。
 客户端-服务器事务表示为过程调用,其输入由启动器设备上的应用程序客户端提供。 过程调用由服务器处理并返回输出和过程调用状态。 客户端-服务器关系不是对称的。 客户端仅发起服务请求。 服务器仅响应此类请求。
 发起方设备和目标方设备映射到UFS物理网络设备。 发起方设备可以请求目标设备处理命令或任务管理功能。 设备服务请求用于请求命令的处理,任务管理器请求用于请求任务管理功能的处理。目标设备是 UFS 设备。 一台 UFS 设备将包含一个或多个逻辑单元。 逻辑单元是设备内的独立处理实体。 发起方请求被定向到设备内的单个逻辑单元。 逻辑单元将接收并处理客户端命令或请求。 每个逻辑单元在目标设备中都有一个地址,称为逻辑单元号 (LUN)。
 发起方设备和目标方设备之间的通信分为一系列消息。 这些消息被格式化为本标准中定义的 UFS 协议信息单元 (UPIU)。 定义了许多不同的 UPIU 类型。 所有的 UPIU 结构都在数据结构的开头(最低地址)包含一个公共头区域。 结构的其余字段根据 UPIU 的类型而有所不同。
 任务是执行请求的服务的命令或操作序列。 一个逻辑单元包含一个支持处理一个或多个任务的任务队列。 任务队列由逻辑单元管理。 在构建任务时,启动器设备会生成一个唯一的任务标签。 目标设备和发起方设备使用此任务标签来区分多个任务。 与特定任务相关联的所有事务和序列都将在事务相关数据结构中包含该任务标签(代码中常说的tag)。
 命令结构由包含命令操作码(代码中的opcode)和相关参数(对应UPIU结构中的字段)、标志和属性的命令描述符块 (即CDB) 组成。 CDB 内容和结构的描述在 [SAM]、[SBC] 和 [SPC] INCITS T10 草案标准中有详细定义,通常CDB也就不超过16个字节,具体忘记了。。
ufs2.2 协议扫盲(三)_第11张图片

上图是一个UFS Domain Class Diagram,类似于面向对象编程的类图,具体的含义之后SAM-5上研究下,比如
ufs2.2 协议扫盲(三)_第12张图片

描述了Task Router class的功能定义。 其中一个功能如上图中的
a)寻址到有效逻辑单元的命令被路由到指定逻辑单元中的任务管理器

5.14、CDB, Status, Task Management:
UTP 采用命令描述符块 (CDB) 格式的命令设备状态数据层次结构(UPIU会有字段描述该任务的状态)报告方法(代码中的sense key)以及未完成命令的任务管理功能,在 [SAM] 中进行了描述。 无论UTP下发何种命令协议,UFS设备都应统一采用SCSI CDB、状态和任务管理功能。

5.15、Nexus:
Nexus
代表发起者、目标、逻辑单元和命令(任务)之间的关系
 Nexus 符号:I_T_L_Q nexus; 其中 I = 启动器,T = 目标,L = 逻辑单元,Q = 命令
UFS 定义中应至少有一个启动器设备。 应该只有一个目标设备,UFS 设备。 在一个 UFS 设备中应该有一个或多个逻辑单元。 命令标识符(即 I_T_L_Q nexus中的 Q)由发起方设备分配,以在特定 I_T_L nexus的上下文中唯一标识一个命令,允许在同一时间,在I_T_L nexus中,有多个命令未交付。
 当任务管理器或任务路由器在 I_T_L_Q 关系完成其命令生命周期之前,检测到命令中使用重复的 I_T_L_Q 关系时,就会发生重叠命令(请参阅 [SAM])。 UFS 中不允许并发重叠命令。 每个命令都应该有一个唯一的任务标签。 UFS 设备没有必要检测重叠的命令。

5.16、SCSI Command Model
所有命令请求都源自发起方设备中的应用程序客户端。 应用程序客户端通过以下过程调用请求处理命令:
 服务响应 = 执行命令(IN输入参数I_T_L_Q NexusCDB任务属性,[数据输入缓冲区大小],[数据输出缓冲区],[数据输出缓冲区大小],[CRN],[命令优先级]), OUT输出([数据输入缓冲器]、[Sense Data]、[Sense Data Length]、状态、[状态限定符]))
UPIU 头中的参数字段包含执行命令过程的输入和输出参数的必要信息,包括UTP 命令、响应、准备传输、数据输出、数据输入。

5.17、SCSI Task Management Functions:
应用程序客户端通过以下过程调用请求处理任务管理功能:
 Service Response = Function name (IN (Nexus), OUT ([Additional Response Information])
UTP 任务管理请求UTP 任务管理响应报头中的参数字段包含符合 [SAM] 的任务管理功能过程调用的输入和输出参数的必要信息。

5.18、UFS Application and Command Layer:
 UFS 接口被设计为与协议无关的接口。 但是,如前所述,已选择 SCSI 作为该标准的基线协议层。 Descriptors可用于为 UFS 接口识别和选择适当的协议(应该是可以配置UTP协议,之后在Descriptors的叙述中,再回来补充)。
 命令集层的主要功能是建立 UFS 主机和 UFS 设备之间的数据交换方法,并提供基本的设备管理能力。 SCSI SBC 和 SPC 命令是 UFS 的基准。 UFS 不会修改 SBC 和 SPC Compliant 命令。 目标是最大限度地重用和利用已经支持 SCSI 的平台(PC、上网本、MID)上可用的软件代码库。可以根据需要使用选项来定义 UFS Native 命令和扩展(目前未使用自家的命令,之后的协议中可以扩展)。
UFS SCSI command set includes:
1. SBC compliant commands [SBC]:
 FORMAT UNIT
 READ (6) and READ (10)
 READ CAPACITY (10)
 REQUEST SENSE
 SEND DIAGNOSTIC
 UNMAP
 WRITE (6) and WRITE (10)
2. SPC compliant commands [SPC]:
 INQUIRY
 REPORT LUNS
 READ BUFFER (optional)
 TEST UNIT READY
 WRITE BUFFER
 SECURITY PROTOCOL IN and SECURITY PROTOCOL OUT
3. SCSI operational commands for UFS applications and compatible with existing SCSI driver (scsi操作命令)
 MODE SELECT (10) and MODE SENSE (10)
 PRE-FETCH (10)
 START STOP UNIT
 SYNCHRONIZE CACHE (10)
 VERIFY (10)
4. Value-added optional commands for UFS(ufs增加的可选命令):
 READ (16), WRITE(16), PRE-FETCH (16), SYNCHRONIZE CACHE (16), and READ
CAPACITY(16).
之后在UFS APPLICATION (UAP) LAYER – SCSI COMMANDS章节,对应用层的命令详细叙述。

你可能感兴趣的:(UFS,Linux,C,驱动开发,架构,c语言)