UFS 2 -UFS架构简介2
- 1 UFS架构简介
- 1.1 System Boot and Enumeration
- 1.2 UFS Interconnect (UIC) Layer
- 1.2.1 UFS Physical Layer Signals
- 1.2.2 MIPI UniPro
- 1.2.3 MIPI UniPro Related Attributes
- 1.3 UFS Transport Protocol (UTP) Layer
- 1.3.1 Architectural Model
- 1.3.1.1 Client-Server Model
- 1.3.1.2 CDB, Status, Task Management
- 1.3.1.3 Nexus(关系)
- 1.3.1.4 SCSI Command Model
- 1.3.1.5 SCSI Task Management Functions
- 1.4 UFS Application and Command Layer
- 1.4.1 SBC compliant commands [SBC]:
- 1.4.2 SPC compliant commands [SPC]:
- 1.4.3 SCSI operational commands for UFS applications and compatible with existing SCSI driver
- 1.4.4 Value-added optional commands for UFS:
1 UFS架构简介
1.1 System Boot and Enumeration
The system boot from a bootable UFS device will initiate after power up when the UFS InterConnect Layer (MIPI M-PHY and UniPro) has completed its boot sequence. The boot code can be read from the appropriate boot logical unit, or as desired, boot ROM code can re-configure MIPI M-PHY and UniPro to appropriate setting before reading the boot code.
当 UFS 互连层(MIPI M-PHY 和 UniPro)完成其启动序列时,从可启动 UFS 设备启动的系统将在加电后启动。引导代码可以从适当的引导逻辑单元读取,或者根据需要,引导 ROM 代码可以在读取引导代码之前将 MIPI M-PHY 和 UniPro 重新配置为适当的设置。
Multiple boot logical units may be available in a UFS device. However, only one boot logical unit will be active at power-up. Appropriate descriptors are available to configure the boot process.
UFS 设备中可能有多个引导逻辑单元。但是,只有一个引导逻辑单元在加电时处于活动状态。适当的描述符可用于配置引导过程。
During boot, accesses to boot logical unit are supported via SCSI commands.
在引导期间,支持通过 SCSI 命令访问引导逻辑单元。
1.2 UFS Interconnect (UIC) Layer
UFS interconnect layer is composed by MIPI UniPro, which provides basic transfer capabilities to the upper layer (UTP), and MIPI M-PHY, adopted as UFS physical layer.
UFS互连层由MIPI UniPro和MIPI M-PHY组成,MIPI UniPro为上层(UTP)提供基本的传输能力,MIPI M-PHY作为UFS物理层。
1.2.1 UFS Physical Layer Signals
The UFS physical layer defines the physical portion of the UFS interface that connects UFS device and UFS host. This is based on MIPI M-PHY specification. UFS interface can support multiple lanes in each direction. Each lane consists of a differential pair. Basic configuration is based on one transmit lane and one receive lane.
UFS 物理层定义了连接 UFS 设备和 UFS 主机的 UFS 接口的物理部分。这是基于 MIPI M-PHY 规范。 UFS 接口可以在每个方向上支持多个通道。每个通道由一个差分对组成。基本配置基于一个传输通道和一个接收通道。
Optionally, a UFS device may support two downstream lanes and two upstream lanes. An equal number of downstream and upstream lanes shall be provided in each link.
可选地,UFS 设备可以支持两个下行通道和两个上行通道。每条链路应提供相等数量的下行和上行lane。
Table 5.1 summarizes the signals required for a UFS device. Only the single lane, per direction, per link, configuration is shown.
表 5.1 总结了 UFS 设备所需的信号。仅显示单通道、每个方向、每个链路、配置。
1.2.2 MIPI UniPro
In UFS, UniPro is responsible for management of the link, including the PHY.
在 UFS 中,UniPro 负责链路的管理,包括 PHY。
NOTE Device management is outside the scope of the interconnect layer and is the responsibility of the upper
layers.
注:设备管理不在互连层的范围内,它负责的是更上层。
The basic interface to the interconnect layer is UniPro definition of a CPort. CPort is used for all data transfer as well as all control and configuration messages. In general, multiple CPorts can be supported on a device and the number of CPorts is implementation dependent.
互连层的基本接口是 UniPro 定义的 CPort。 CPort 用于所有数据传输以及所有控制和配置消息。通常,一个设备可以支持多个 CPort,并且 CPort 的数量取决于具体实现。
Traffic sent over UniPro link can be classified as TC0 or TC1 traffic class with TC1 as higher priority traffic class. This version of UFS standard only uses a single CPort and TC0 traffic class.
通过 UniPro 链路发送的流量可以分类为 TC0 或 TC1 流量类,其中 TC1 为更高优先级的流量类。此版本的 UFS 标准仅使用单个 CPort 和 TC0 流量类别。
UFS takes advantage of the basic types of UniPro services. These include data transfer service, and config/control/status service.
UFS 利用了 UniPro 服务的基本类型。这些包括数据传输服务和配置/控制/状态服务。
1.2.3 MIPI UniPro Related Attributes
In general the UniPro related attributes, values and use of them are defined in the MIPI UniPro specification. The attributes may be generic for all UniPro applications and thus out of scope of this document. Following attributes are defined in this standard specifically for UFS application as indicated in Table 5.2.
一般来说,与 UniPro 相关的属性、值和它们的使用在 MIPI UniPro 规范中定义。这些属性可能对所有 UniPro 应用程序都是通用的,因此超出了本文档的范围。本标准专门为 UFS 应用程序定义了以下属性,如表 5.2 所示。
1.3 UFS Transport Protocol (UTP) Layer
As mentioned previously, the Transport Layer is responsible for encapsulating the protocol into the appropriate frame structure for the interconnect layer. UFS is protocol agnostic and thus any protocol will need the appropriate translation layer. For this version of UFS standard, this is UTP (UFS Transport Protocol) layer.
如前所述,传输层负责将协议封装到互连层的适当帧结构中。 UFS 与协议无关,因此任何协议都需要适当的转换层。对于此版本的 UFS 标准,这是 UTP(UFS 传输协议)层。
In this version of the standard, all accesses are supported only through SCSI, however additional API/service/extension may be added in future versions to introduce new features or address specific requirements.
在此版本的标准中,仅通过 SCSI 支持所有访问,但未来版本可能会添加额外的 API/服务/扩展以引入新功能或满足特定要求。
A design feature of UTP is to provide a flexible packet architecture that will assist the UFS controller in directing the encapsulated command, data and status packets into and out of system memory. The intention is to allow the rapid transmittal of data between the host system memory and the UFS device with minimal host processor intervention. Once the data structures are set up in host memory and the target device is notified, the entire commanded transaction can take place between the UFS device and the host memory. The means by which the UFS controller transfers data into and out of host memory is via a hardware and/or firmware mechanism that is beyond the scope of this document. See the UFS controller standard for further information.
UTP 的一个设计特点是提供一种灵活的数据包架构,该架构将协助 UFS 控制器将封装的命令、数据和状态数据包导入和导出系统内存。目的是允许在主机系统内存和 UFS 设备之间快速传输数据,而主机处理器的干预最少。一旦在主机内存中设置了数据结构并通知了目标设备,整个命令事务就可以在 UFS 设备和主机内存之间进行。 UFS 控制器将数据传入和传出主机内存的方式是通过超出本文档范围的硬件和/或固件机制。有关详细信息,请参阅 UFS 控制器标准。
A second feature of the UTP design is that once a device receives a command request notification from the host, the device will control the pacing and state transitions needed to satisfy the data transfers and status completion of the request. The idea here is that the device knows its internal condition and state and when and how to best transfer the data that makes up the request. It is not necessary for the host system or controller to continuously poll the device for “ready” status or for the host to estimate when to start a packet transfer. The device will start the bus transactions when it determines its conditions and status are optimal. This approach cuts down on the firmware and logic needed within the host to communicate with a device. It also affords the maximum possible throughput with the minimum number of bus transactions needed to complete the operation.
UTP 设计的第二个特点是,一旦设备从主机接收到命令请求通知,设备将控制满足请求的数据传输和状态完成所需的步调和状态转换。这里的想法是设备知道它的内部条件和状态以及何时以及如何最好地传输构成请求的数据。主机系统或控制器无需连续轮询设备的“就绪”状态,也无需主机估计何时开始数据包传输。当设备确定其条件和状态最佳时,它会启动总线事务。这种方法减少了主机与设备通信所需的固件和逻辑。它还以完成操作所需的最少总线事务数提供最大可能的吞吐量。
1.3.1 Architectural Model
The SCSI Architecture Model [SAM] is used as the general architectural model for UTP. The SAM architecture is a client‐server model or more commonly a request‐response architecture.
SCSI 体系结构模型 [SAM] 用作 UTP 的通用体系结构模型。 SAM 架构是一种客户端-服务器模型,或者更常见的是一种请求-响应架构。
1.3.1.1 Client-Server Model
A client-server transaction is represented as a procedure call with inputs supplied by the application client on the Initiator device. The procedure call is processed by the server and returns outputs and a procedure all status. Client-server relationships are not symmetrical. A client only originates requests for service. A server only responds to such requests.
客户端-服务器事务表示为过程调用,其输入由发起方设备上的应用程序客户端提供。过程调用由服务器处理并返回输出和过程所有状态。客户端-服务器关系不是对称的。客户端仅发起服务请求。服务器仅响应此类请求。
Initiator device and Target device are mapped into UFS physical network devices. An Initiator device may request.processing of a command or a task management function through a request directed to the Target device. Device service requests are used to request the processing of commands and task manager requests are used to request the processing of task management functions.
Initiator device 和Target device 映射成UFS 物理网络设备。发起方设备可以通过指向目标设备的请求来请求处理命令或任务管理功能。设备服务请求用于请求命令的处理,任务管理器请求用于请求任务管理功能的处理。
Target device is a UFS device. A UFS device will contain one or more Logical Units. A Logical Unit is an independent processing entity within the device.
目标设备是 UFS 设备。一个 UFS 设备将包含一个或多个逻辑单元。逻辑单元是设备内的独立处理实体。
An Initiator request is directed to a single Logical Unit within a device. A Logical Unit will receive and process the client command or request. Each Logical Unit has an address within the Target device called a Logical Unit Number (LUN).
Communication between the Initiator device and Target device is divided into a series of messages. These messages are formatted into UFS Protocol Information Units (UPIU) as defined within this standard. There are a number of different UPIU types defined. All UPIU structures contain a common header area at the beginning of the data structure (lowest address). The remaining fields of the structure vary according to the type of UPIU.
启动器请求被定向到设备中的单个逻辑单元。逻辑单元将接收并处理客户端命令或请求。每个逻辑单元在目标设备中都有一个地址,称为逻辑单元号 (LUN)。 Initiator 设备和 Target 设备之间的通信分为一系列消息。这些消息被格式化为本标准中定义的 UFS 协议信息单元 (UPIU)。定义了许多不同的 UPIU 类型。所有 UPIU 结构都在数据结构的开头(最低地址)包含一个公共标头区域。该结构的其余字段根据 UPIU 的类型而有所不同。
A Task is a command or sequence of actions that perform a requested service. A Logical Unit contains a task queue that will support the processing of one or more Tasks. The Task queue is managed by the Logical Unit. A unique Task Tag is generated by the Initiator device when building the Task. This Task Tag is used by the Target device and the Initiator device to distinguish between multiple Tasks. All transactions and sequences associated with a particular Task will contain that Task Tag in the transaction associated data structures.
任务是执行请求服务的命令或操作序列。一个逻辑单元包含一个任务队列,它将支持一个或多个任务的处理。任务队列由逻辑单元管理。在构建任务时,启动器设备会生成一个唯一的任务标签。 Target 设备和 Initiator 设备使用此 Task Tag 来区分多个 Task。与特定任务关联的所有事务和序列都将在事务关联数据结构中包含该任务标签。
Command structures consist of Command Descriptor Blocks (CDB) that contain a command opcode and related parameters, flags and attributes. The description of the CDB content and structure are defined in detail in the [SAM], [SBC] and [SPC] INCITS T10 draft standards.
命令结构由命令描述符块 (CDB) 组成,其中包含命令操作码和相关参数、标志和属性。 CDB内容和结构的描述在[SAM]、[SBC]和[SPC] INCITS T10标准草案中有详细定义。
1.3.1.2 CDB, Status, Task Management
UTP adopts Command Descriptor Block (CDB) format for commands, device status data hierarchy and reporting method, and task management functions of outstanding commands, described in [SAM]. Regardless of the command protocol to be delivered by UTP, SCSI CDB, Status and Task Management Functions should be adopted uniformly in UFS devices.
UTP采用命令描述符块(CDB)格式的命令,设备状态数据层次结构和报告方法,以及[SAM]中描述的未完成命令的任务管理功能。无论UTP、SCSI CDB、Status和Task Management Functions要下发什么命令协议,UFS设备都应该统一采用。
1.3.1.3 Nexus(关系)
The nexus represents the relationship among the Initiator, Target, Logical Unit and Command (Task)
nexus代表Initiator、Target、Logical Unit和Command(Task)之间的关系
- Nexus notation: I_T_L_Q nexus; where I =Initiator, T = Target, L = Logical Unit, Q = Command
- Nexus 表示法:I_T_L_Q nexus;其中 I = 启动器,T = 目标,L = 逻辑单元,Q = 命令
There shall be at least one initiator device in the UFS definition. There shall only one target device, the UFS device. There shall be one or more logical units in a UFS device. The command identifier (i.e., the Q in an I_T_L_Q nexus) is assigned by the Initiator device to uniquely identify one command in the context of a particular I_T_L nexus, allowing more than one command to be outstanding for the I_T_L nexus at the same time.
UFS 定义中至少应有一个启动器设备。只有一个目标设备,即 UFS 设备。 UFS 设备中应有一个或多个逻辑单元。命令标识符(即 I_T_L_Q 关系中的 Q)由启动器设备分配,以在特定 I_T_L 关系的上下文中唯一地标识一个命令,允许多个命令同时针对 I_T_L 关系。
An overlapped command occurs when a task manager or a task router detects the use of a duplicate I_T_L_Q nexus in a command before that I_T_L_Q nexus completes its command lifetime (see [SAM]).
当任务管理器或任务路由器在 I_T_L_Q 关系完成其命令生命周期之前检测到在命令中使用了重复的 I_T_L_Q 关系时,就会出现重叠命令(请参阅 [SAM])。
Concurrent overlapped commands are not allowed in UFS. Each command shall have an unique Task Tag. The UFS device is not required to detect overlapped commands.
UFS 中不允许并发重叠命令。每个命令都应有一个唯一的任务标签。 UFS 设备不需要检测重叠命令。
1.3.1.4 SCSI Command Model
All command requests originate from application clients in an Initiator device. An application Client requests the processing of a command with the following procedure call:
所有命令请求都源自启动器设备中的应用程序客户端。应用程序客户端请求使用以下过程调用处理命令:
- Service Response = Execute Command (IN (I_T_L_Q Nexus, CDB, Task Attribute, [Data-In Buffer Size], [Data-Out Buffer], [Data-Out Buffer Size], [CRN], [Command Priority]), OUT ([Data-In Buffer], [Sense Data], [Sense Data Length], Status, [Status Qualifier]))
- 服务响应 = 执行命令(IN(I_T_L_Q Nexus、CDB、任务属性、[数据输入缓冲区大小]、[数据输出缓冲区]、[数据输出缓冲区大小]、[CRN]、[命令优先级])、OUT ([缓冲区中的数据]、[检测数据]、[检测数据长度]、状态、[状态限定符]))
Parameter fields in the UTP Command, Response, Ready-to-Transfer, Data-Out, Data-In UPIU headers contain the requisite information for the input and output arguments of the Execute Command procedure call in compliance with [SAM].
UTP 命令、响应、准备传输、数据输出、数据输入 UPIU 标头中的参数字段包含执行命令过程调用的输入和输出参数的必要信息,符合 [SAM]。
1.3.1.5 SCSI Task Management Functions
An application client requests the processing of a task management function with the following procedure call:
应用程序客户端请求使用以下过程调用处理任务管理功能:
Service Response = Function name (IN (Nexus), OUT ([Additional Response Information])
服务响应 = 函数名称(IN(Nexus),OUT([附加响应信息])
Parameters fields in the UTP Task Management Request and UTP Task Management Response headers contain the requisite information for the input and output arguments of the Task Management Function procedure call in compliance with [SAM].
UTP 任务管理请求和 UTP 任务管理响应报头中的参数字段包含符合 [SAM] 的任务管理功能过程调用的输入和输出参数的必要信息。
1.4 UFS Application and Command Layer
UFS interface is designed to be protocol agnostic interface. However, as mentioned previously, SCSI has been selected as the baseline protocol layer for this standard. Descriptors are available to identify and select the appropriate protocol for UFS interface.
UFS 接口被设计为与协议无关的接口。但是,如前所述,SCSI 已被选为该标准的基线协议层。描述符可用于识别和选择 UFS 接口的适当协议。
The primary functions of the Command Set Layer are to establish a method of data exchange between the UFS host and UFS device and to provide fundamental device management capability. SCSI SBC and SPC commands are the baseline for UFS. UFS will not modify the SBC and SPC Compliant commands.
命令集层的主要功能是建立 UFS 主机和 UFS 设备之间的数据交换方法,并提供基本的设备管理功能。 SCSI SBC 和 SPC 命令是 UFS 的基准。 UFS 不会修改 SBC 和 SPC 兼容命令。
The goal is to maximize re-use and leverage of the software codebase available on platforms (PC, netbook, MID) that are already supporting SCSI.
目标是最大限度地重用和利用已经支持 SCSI 的平台(PC、上网本、MID)上可用的软件代码库。
Options are available to define UFS Native commands and extension as needed. UFS SCSI command set includes:
选项可用于根据需要定义 UFS Native 命令和扩展。 UFS SCSI 命令集包括:
1.4.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)
1.4.2 SPC compliant commands [SPC]:
- INQUIRY
- REPORT LUNS
- READ BUFFER
- TEST UNIT READY
- WRITE BUFFER
- SECURITY PROTOCOL IN and SECURITY PROTOCOL OUT
1.4.3 SCSI operational commands for UFS applications and compatible with existing SCSI driver
- MODE SELECT (10) and MODE SENSE (10)
- PRE-FETCH (10)
- START STOP UNIT
- SYNCHRONIZE CACHE (10)
- VERIFY (10)
1.4.4 Value-added optional commands for UFS:
- READ (16), WRITE(16), PRE-FETCH (16), SYNCHRONIZE CACHE (16), and READ CAPACITY(16).
NOTE These commands support logical units with larger capacities having an 8-byte LBA field.
注意 这些命令支持具有 8 字节 LBA 字段的更大容量的逻辑单元。