UFS系列五:逻辑单元(LU)

转载:蛋蛋读UFS之五:逻辑单元(LU)

熟悉NVMe的朋友知道,NVMe里面有namespace的概念,就是把SSD物理空间划分成若干个逻辑地址空间。在UFS的世界里,它也有这个特性。UFS设备的物理存储空间可以有若干个独立的逻辑地址空间,我们把逻辑地址空间叫做LU,即Logical Unit,俗称“撸”。前面看到,在每个UPIU的Header中,有个LUN(Logical Unit Number)的域,就是标识该UPIU关联的命令或者请求的目标逻辑单元。每个LU的地址空间是独立的,主机在发命令或者请求给设备的时候,须通过LUN指定目标逻辑单元。

如上图所示,UFS设备有若干个LU,每个LU接收主机发过来的命令或者请求,这些命令或者请求可来自应用层的SCSI模块、设备管理器或者任务管理器。每个LU都是独立的,“独立”表现在下面几个方面:

  • 逻辑地址空间是独立的,都是从LBA 0开始;
  • 逻辑块大小可以不同,可以为4KB,..;
  • 可以有不同的安全属性,比如可以设置不同的写保护属性;
  • 每个LU可以有自己的命令队列;
  • 不同的LU可以存储不同的数据,比如有的LU存储系统启动代码,有的LU存储普通的应用数据,有的LU存储用户特殊数据...
  • 。。。

UFS2.1中可以有最多32个普通LU和“四大名撸”(四个Well known LU,众所周知的LU)。

普通LU的逻辑块大小至少是4KB,但RPMB LU逻辑块大小为256B。至于什么是RPMB LU,后面再讲。

普通LU我觉得没有什么好讲的,就是分别用来存储用户数据的。我们主要来讲讲“四大名撸”。

Report LUNS LU

Report LUNS主要用来代表设备向主机汇报设备LU清单。主机想知道设备LU的支持情况,就需要发命令或者请求给该LU。UFS其中有个命令“Report LUNS” (和该LU名字一样)用来访问Report LUNS。

UFS Device LU

UFS设备的法人。当UFS主机不针对某个具体LU,而是对整个UFS设备发命令的时候,UFS Device LU就成为该命令接收的对象,比如格式化UFS设备(FORMAT UNIT命令)、切换UFS设备的功耗模式(START STOP UNIT命令)等等。

BOOT LU

顾名思义,就是用来存储启动代码的LU。不过,BOOT LU本身是不存储启动代码的,它只是个虚拟的LU,启动代码物理上是存储在普通LU上的。

有两个Boot LU,LU A和LU B,可以用来存储不同启动代码(比如一个新,一个旧),但在启动过程中,只有一个是活跃的(Active)的。32个普通LU中的任意一个可以配成Boot LU A或者Boot LU B。

举例说明:

在上例中,LU 1 充当Boot LU A,LU 4 充当Boot LU B。由于有两份启动代码,分别保存在LU 1和LU 4,那启动的时候读取哪一份呢?

主机启动时,首先应该通过设备管理器,发送Query 请求给设备,获取一个叫做“bBootLunEn ”的属性,该属性标识当前活跃(Active)的Boot LU。

在上例中,bBootLunEn = 01,说明Boot LU A是当前活跃的Boot LU,因此主机会从LU 1上读取启动代码完成系统的启动。

值得一提的是,Boot LU不是必须的。如果系统的启动代码不是存储在UFS设备上,那么Boot LU就不需要,因此bBootLunEn = 0。

RPMB LU

在UFS里,有这么一个LU,主机往该LU写数据时,UFS设备会校验数据的合法性,只有特定的主机才能写入;同时,主机在读取数据时,也提供了校验机制,保证了主机读取到的数据是从该LU上读的数据,而不是攻击者伪造的数据。这个LU就是RPMB LU。

关于RPMB,后面有专门章节介绍,这里不多说。

“四大名撸” 每个LU分工明确,分别执行不同的任务。下面把 “四大名撸” 能接收的命令列一下:

他们能接收一些通用的命令(如上图绿色命令),还有只有该LU能执行的命令(如红色命令),具体命令可查看Spec。

需要注意的是,写Boot LU和RPMB LU时,它是不支持cache操作的,就是说,数据必须写到闪存中以后,这笔写命令才算完成。而对一般LU的写,一般都是cache操作的,即主机数据到设备的内部buffer,设备就会回命令完成状态给主机。

展开阅读全文

没有更多推荐了,返回首页