标签：
http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/htmls/ch02_msc_basic.html
目录
摘要
【todo】待整理：Linux USB MASS Storage driver流程图
USB Mass Storage所对应的层次和要实现哪些东西：
更深入的剖析，对于普通U盘的内部结构，则是一个USB物理接口，加上对应的控制芯片（微控制器（含Nand Flash的控制器）+ USB设备控制器）和一个Nand Flash芯片：
上述PC电脑和U盘的物理关系，以群联的PS2251-50 USB 2.0 Flash Controller为例，对应的逻辑关系为：
关于U盘容量，再多解释一句：一般U盘的大小，就是对应着这个Nand Flash芯片的容量，比如2GB，4GB，8GB等。当然，比如一个8GB的U盘，内部也可以用两块4GB的Nand Flash芯片来构成。
PC和U盘的之间的抽象的逻辑关系，可用下图来表示：
上图中，Storage Media，就是我们例子中的Nand Flash芯片。而例子中的那个控制芯片，是Microcontroller with embedded USB device controller 和Media Controller的集合。
而上图中的USB MSC（Mass Storage Class） Device，从应用领域来说，可以分为以下几类：
而像上述例子中那样的常用的U盘，属于上图中的Flash Drive，即，物理上存储数据的介质用的是Flash Memory，比如例子中的Nand Flash芯片，对应的，Media Controller，也就是Nand Flash的Controller，负责从Nand Flash芯片中读写数据。
USB MSC设备中的固件（firmware）或者硬件（hardware），必须要实现下面这些功能：
另外，设备如果想要向存储介质中，创建/读取/写入，文件/文件夹的话，那么就涉及到文件系统，还要实现对应的文件系统。嵌入式系统中常见的文件系统有FAT16或FAT32。
除了本身USB的协议之外，Mass Storage作为其中USB的一种，USB Mass Storage自己又有相关的协议，对应的协议可以去官网下载：
http://www.usb.org/developers/devclass_docs/
其中有关于Mass Storage相关的，一堆的协议：
说实话，咋一看，这么多协议，不知道驴年马月才能看完和真正理解。不过，等待了解了这些协议的关系之后，会发现，其实需要特别关注和研究的协议，并不是很多，至少很多协议可以不用太关心。
凡事至少得对整体系统有个大致了解后，才能继续下一步的深入的开发。所以，我们的目的，首先是要搞懂这么多协议之间都是啥关系，以及具体写U盘驱动的话，要看哪些协议。
从上面那一堆协议的名词上，我们就能看到，第一个：Mass Storage Class Specification Overview 1.4 就是对于这么多协议的概述，其中介绍了各个协议的关系。
下面就把其中的主要内容摘出来，解释如下：
关于USB Mass Storage相关的一些协议，都是由一个叫做USB Mass Storage Class Working Group (CWG)的组织定义的，如上所述，包括下面一些协议：
对于这些协议，我们一个个的简单解释和分析一下：
我们所关注的U盘，就是所谓的MSC设备，大容量存储设备。
U盘的功能，就是数据存储。而对应的数据传输，用的是USB中的Bulk Transfer。而Control Transfer是用来发送Class-Specific的信息和Clear Stall。而其他方面的信息交换，是用Bulk-only协议。
而对于CBI，算是Bulk-only的替代品，也可以用来信息交换，但是只能用于full-speed的软盘（Floppy drive），也不推荐将CBI用于其它新出的MSC设备上。
【总结】USB MSC Control/Bulk/Interrupt (CBI) 主要用于Floppy设备，对于我们关心的U盘，用不到，不需要太关心，可以忽略之。
如上所述，Bulk-only是USB设备端，此处的U盘和USB Host端，即普通PC，之间信息交换的协议。
Bulk Only Transport，也被简称为BOT。
USB MSC中的Bulk-Only 常被叫做BBB，是相对于前面所说的CBI来说的。
看起来，USB MSC的CBI，是Control/Bulk/Interrupt的简写，但是其具体含义是：
Control端点用于，除了传送标准的USB请求之外，还用于通过Class-specific的请求，将命令块（command block）传给设备；即Control端点传送命令块
Bulk In和Bulk Out端点用于在主机（Host）和设备（Device）之间数据的传输。即，Bulk用于传送数据
Interrupt端点用于（设备向主机）通知命令完成。即Interrupt用于传送状态信息
因此，上面的USB MSC的Control/Bulk/Interrupt，才被简称为CBI。
和CBI中的用三种不同的端点来传送三种类型的信息，而不同的是，Bulk-only传送这些全部的信息，都之用Bulk端点。
即用Bulk端点来传送命令块，数据，状态，因此，才类似于Control/Bulk/Interrupt被简称为CBI一样，而Bulk/Bulk/Bulk被简称为BBB。
【总结】USB MSC传输协议分CBI和BOT，而BOT又称为BBB。
既然，对于USB MSC设备来说，USB设备和USB主机之间的通信，已经定义了一个CBI规范，那么为何还要再新定义一个Bulk-only（BBB）呢？
我的理解是，那是因为，最开始USB协议定义的时候，那时候市场上的Floppy Disk还是用的很多的。所以针对Floppy设备特点，分别定义了多个端点来传输不同的信息，即Control端点传命令块，Bulk传数据，Interrupt传状态信息，
而后来计算机行业的发展了，Floppy类的设置很少用了，存储数据的话，多数开始用Flash Memory了，再加上通过合理规划，可以用同一种端点，即Bulk端点，传输上述三种信息，即命令块，数据，状态，因此，只需要物理上实现一个Bulk端点，节省掉了其他两个端点：Control端点和Interrupt端点，达到了物理上实现起来方便和节省资源，而达到同样的信息传输的目的。
此部分理解，有待进一步考证。
【总结】USB MSC Bulk-Only (BBB) 协议，是我们要重点关注的对象。因为我们的U盘和USB主机（PC端）直接信息交互，主要是用此协议。
UFI，即Universal Floppy Interface，因此看名字就知道，是关于软盘的。此USB MSC UFI规范，定义了UFI命令集合（Command Set），设计出来此规范，就是用于软盘的。此UFI命令集合，是基于SCSI-2 和SFF-8070i命令集合的。
【总结】看完上面的解释，就明白了，我们此处关心的是U盘，是USB Flash Memory类型的，不是Floppy Disk类型的，所以，此处也可以不关心，暂忽略之。
目前常见的电脑启动，很多都是从MSC大容量存储设备中启动的，比如硬盘。因此，设计了这个规范，以使得操作系统可以从USB MSC设备上启动。关于此规范的具体内容，主要是定义了一些命令和相关的一些数据的定义。即，如果你想要实现让操作系统从你的这个MSC设备启动，那么你就要实现对应的CDB（Command Descriptor Block，命令描述符块）或者Data数据。
【总结】我们主要关心U盘如何和主机数据交互，暂不关心是否能否从此U盘启动，所以也可不太关心，暂忽略之。
【总结】无须多解释，看名字就知道，是一个关于兼容性测试的规范，和我们此处所关心的U盘和主机的数据交互，关系不大，暂忽略之。
“Lockable Storage Devices Feature Specification”，简称为 LSD FS。“Lockable”的意思是，可锁定，即锁定以防止其他人访问或者写入，即变成只读，甚至不允许其他人再访问。说白了就是对USB存储设备的安全控制方面的规范。
而基于目前还没有一个标准的规范去定义，如何去控制那些对于USB存储设备的访问，所以此处才定义了一个这么个和访问控制相关的协议。此协议可实现允许主机Host或者设备Device去锁定Lock或者解锁Unlock 对应的存储设备。
【总结】和安全存储和权限控制相关的协议，我们此处也是暂不关心，可忽略之。
“Attached”顾名思义，是附在某个上面的，此处即附在SCSI协议的上面的，即SCSI协议的补充部分。UASP规范，定义了关于如何在USB 2.0和USB 3.0中，UAS的传输标准是如何实现的，并且给出了一些范例和一些推荐的做法。
既然已经有了对应的SCSI协议，用于发送对应命令，实现对应功能。作为U盘等应用的话，直接实现对应的协议，符合对应的规范，不是也就可以实现对应功能了吗，为何还要另外再弄出一个SSCI的附属协议UASP？
那是因为，原先的BOT（Bulk Only Transport），虽然协议简单已实现，适合用于大容量存储设备中，但其就像一个单线程，不能同时并行执行多个传输。即，对于BOT，每一个由Host发起数据传输（transaction），都必须等待设备完成，然后设备再返回对应的已完成状态信息，然后才能开始下一次数据传输。这样的话，对于整个数据传输过程的话，就造成了一个很大（大概有20%）的浪费（overhead）。
而对于USB 3.0来说，速度从USB 2.0的480Mb/s变成了 5.0Gb/s，而如果继续用BOT的话，那么相对来说CPU性能的利用率很低，USB传输速度也不太高，例如，有研究表明，2.4 GHz Core Duo™的CPU，利用率只要大概12%，CPU传输速度只有大约250MB/s，而USB 3.0的理论速度是5.0Gb/s=640MB/s，即还不到理论最大速度的一半。
因此，才有了这个UASP，对于SCSI协议进行了补充，以提高USB 2.0的USB总线利用率，和充分利用USB 3.0的全双工能力，可以使得传输速度达到大约400MB/s。此新的协议UASP的实现，也需要对应的新的Host端的软件，新的Device端的固件（Firmware）。
为了实现设备的向后兼容性，Device同时支持BOT和UAS。而此UASP规范，定义了就是如何在USB 2.0和USB 3.0上实现对应的UAS协议。
当Host和Device都实现了此UAS协议的话，那么Host将通过Host端的SCSI Software Stack去访问Device，而USB的Interface也将从功能上看，变成Host Stack中的另外一个SCSI Host Adapter。Device需要实现SAM4的架构模型，这样Host也就可以查询（Queue）Device中的命令了，以及对应性能的提升。
【总结】为了克服旧的BOT协议的总线利用率不高的缺点，所以定义了新的UAS协议，即UASP，来提升USB的传输效率，提升USB速度。当然，我们此处为了实现U盘功能的话，当然希望性能越高越好了，所以，这个协议也是我们应该好好研究的。
为了说明清楚USB Mass Storage各个协议的关系，我们先给这些协议编个号：
①USB Mass Storage Class Control/Bulk/Interrupt (CBI) Transport
②USB Mass Storage Class Bulk-Only (BBB) Transport
③USB Mass Storage Class Universal Floppy Interface (UFI) Command Specification
④USB Mass Storage Class Bootability Specification
⑤USB Mass Storage Class Compliance Test Specification
⑥USB Lockable Storage Devices Feature Specification (LSD FS)
⑦USB Mass Storage Class USB Attached SCSI Protocol (UASP)
直接用图来表示USB MSC各个协议之间的关系，显得更加直观：
如上图，我们U盘实现的功能，主要就是数据的读写，而Device和Host之间的数据通信，主要有两种：
而对于BOT/BBB来说，对其提高USB总线利用率，提高了USB速度后，就是对应的UASP协议，故此处称UASP为BOT的增强版的协议。
协议方面说完了，再来看看USB Device这一端。
而USB的Device端，根据内部数据存储的介质类型不同，又分两种：
而SCSI协议，本身就是有的了，所以不是属于USB MSC协议范畴，即SCSI只是和USB MSC相关的协议。
同样的，对于USB Device本身，如果需要一些用到其他的特性，比如可启动性，兼容性，可锁定性等等，那么分别对应的规范是
④USB Mass Storage Class Bootability Specification
⑤USB Mass Storage Class Compliance Test Specification
⑥USB Lockable Storage Devices Feature Specification (LSD FS)
【总结】至此，各个协议和规范之间的关系，就很容易理解了。上面这么多协议中，其中我们所要关心的，只有三个规范，如前面的图中，已经用星号标识出来了：
最需要关心的是BOT，即Host和Device间数据通讯的协议
★★★ ②USB Mass Storage Class Bulk-Only (BBB) Transport
其次，需要关心USB Device内部和数据存储介质之间通信的协议
★★ SCSI - Small Computer System Interface
最后，对于，如果要实现更好的性能，那么需要关心BOT的升级版
★⑦USB Mass Storage Class USB Attached SCSI Protocol (UASP)
对应的，了解USB的都知道，每个设备的描述符中，都有对应下面这几个域：
分别对应着USB的Class，Subclass，Protocol。
而对于我们此处的U盘：
图 2.8. SubClass Codes Mapped to Command Block Specifications
 |
标签：
原文地址：http://www.cnblogs.com/heiyue/p/4377192.html
