当前位置: IT大杂烩 > Ubuntu  > 如何实现Linux下的U盘(USB Mass Storage)驱动

如何实现Linux下的U盘(USB Mass Storage)驱动

www.someabcd.com  网友分享于:Jun 8, 2018 6:09:02 PM

标签:des   style   blog   class   code   tar   

摘要

本文主要介绍了USB Mass Storage的相关的各种协议之间的关系,以及如何在Linux的USB驱动框架下实现U盘驱动

2012-08-09

修订历史
修订 0.4 2011-07-01 crl
  1. 介绍如何在Linux下实现U盘驱动
修订 0.6 2012-08-09 crl
  1. 通过Docbook发布

关于U盘,估计大家都用过。

比如,笔者手上的宇瞻AH320的8G的U盘:


最常见的用法就是,直接将此8GU盘插到电脑的USB口上,然后系统(Windows的XP或者Linux)就会自动检测到你的U盘然后生成一个移动盘符,然后你就可以打开对应盘符,读写文件数据了。

而此文呢,目的就是,要搞懂,作为驱动开发者来说,对于这样一个U盘,如何在Linux平台下,去实现U盘驱动,即USB Mass Storage驱动,实现驱动时,需要做哪些事情,以及如何去实现这些事情。

关于USB,其实网上也有不少相关的文章,但是笔者觉得太多帖子,很多帖子,也只是介绍USB协议,而如何在Linux下面实现驱动,却很少提及。或者说是,理论多,实践少,东一块,西一块,很少能把相关知识有机的结合起来,尤其是软件,硬件,系统框架等结合起来一起说明的,导致看了很多这样的帖子,还是似懂非懂。

关于USB或者说多数计算机方面的技术文章,如果有说得明白的,往往都是老外写的。

所以,为了实现有中文的帖子,也能把问题说明白,所以才有此文的诞生。

所以,简述此文目的:

  1. 首先,算为自己学习USB的过程,做个记录和总结,以备后查。
  2. 对于其他不懂Linux和USB的人,看了此文后,可以对Linux,USB等有个基本的认识。
  3. 对于了解Linux和USB的人,搞开发的人,尤其是Linux下USB驱动开发的人,看了此文后,真正能搞懂Linux下USB的Mass Storage的框架,和自己去实现对应的U盘驱动的时候,数据读写的前后流程,而其中,系统做了哪些事情,需要我们自己做哪些事情。

总的说来,本人写任何帖子,要么不写,要么就写的逻辑清晰,让人看得明白。

就像某人说的,看了我写的东西,能达到“醍醐灌顶”的效果,这才是我写东西的终极目标。

【todo】待整理:Linux USB MASS Storage driver流程图

USB Mass Storage所对应的层次和要实现哪些东西:


PC电脑和U盘之间的关系,以及物理上的组成,可以用下图表示:


更深入的剖析,对于普通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),必须要实现下面这些功能:

  1. 检测和响应通用的USB Request和USB总线上的事件。
  2. 检测和响应来自USB设备的关于信息或者动作的USB Mass Storage Request。
  3. 检测和响应,从USB Transfer中获得的SCSI Command。这些业界标准的命令,是用来获得状态信息,控制设备操作,向存储介质块中读取(read block)和写入(write block)数据的。

另外,设备如果想要向存储介质中,创建/读取/写入,文件/文件夹的话,那么就涉及到文件系统,还要实现对应的文件系统。嵌入式系统中常见的文件系统有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)的组织定义的,如上所述,包括下面一些协议:

  • 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)

对于这些协议,我们一个个的简单解释和分析一下:

如上所述,Bulk-only是USB设备端,此处的U盘和USB Host端,即普通PC,之间信息交换的协议。

Bulk Only Transport,也被简称为BOT。

“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之间的数据通信,主要有两种:

  1. CBI:主要用于Floppy设备,所以新的设备,都很少用此协议
  2. BOT:Bulk-Only Transport,也称BBB(Bulk/Bulk/Bulk),

而对于BOT/BBB来说,对其提高USB总线利用率,提高了USB速度后,就是对应的UASP协议,故此处称UASP为BOT的增强版的协议。

协议方面说完了,再来看看USB Device这一端。

而USB的Device端,根据内部数据存储的介质类型不同,又分两种:

  1. 一种是Floppy设备,对应用的是UFI Command Set;
  2. 而另外一种,就是我们常见的Flash Memory,对应的是用SCSI Command Set。

而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)

【总结】

至此,各个协议和规范之间的关系,就很容易理解了。上面这么多协议中,其中我们所要关心的,只有三个规范,如前面的图中,已经用星号标识出来了:

  1. 最需要关心的是BOT,即Host和Device间数据通讯的协议

    ★★★ ②USB Mass Storage Class Bulk-Only (BBB) Transport

  2. 其次,需要关心USB Device内部和数据存储介质之间通信的协议

    ★★ SCSI - Small Computer System Interface

  3. 最后,对于,如果要实现更好的性能,那么需要关心BOT的升级版

    ★⑦USB Mass Storage Class USB Attached SCSI Protocol (UASP)

如何实现Linux下的U盘(USB Mass Storage)驱动,布布扣,bubuko.com

如何实现Linux下的U盘(USB Mass Storage)驱动

标签:des   style   blog   class   code   tar   

发布此文章仅为传递网友分享,不代表本站观点,若侵权请联系我们删除,本站将不对此承担任何责任。
Copyright ©2018  IT大杂烩  版权所有  京ICP备11030978号-1 网站地图