linux　USB驱动前言（主机与USB设备的点滴）_linux usb驱动挂载时设备主动发送啥-CSDN博客

最近在做有关linux下的u盘驱动的相关工作，进行到最后遇到了瓶颈，到处找资料，觉得有些确实不错，留下来，没准以后会有用！同时也分享给做技术的朋友们，希望可以帮助你们少浪费一些时间。

网上关于linux U盘驱动的讲解不算少，但大同小异，几乎都是说了下流程《linux那些是事》里边的东西还不错，但还是没找到我想要的。

转载链接：http://www.lxway.com/4062656224.htm（不完全转载）

　　　　　　固件在USB设备设别阶段的编程思路　<－－－－－觉得对了解U盘驱动和数据传输的问题有帮助

一般地，USB设备接口芯片会产生一些中断来通知程序员特定事件的发生。譬如说，EP0（缺省控制端点） SETUP包的到达，EP0 IN或OUT事务的发生等等。控制传输是分三个阶段的：建立阶段，数据阶段，状态阶段。所以对于一次控制传输，设备固件必须要正确控制其执行流程，不能颠倒。当收到EP0 SETUP包到达的信息之后，固件要分析其请求的具体内容，这里假定为读取描述符，然后进入数据阶段向主机发送相应描述符的具体内容，发送完成后，进入状态阶段。状态阶段结束后，一次控制传输就此完成。要注意的是，就算是进入各个阶段，也要等待主机发送事务请求后才能响应具体操作。也就是，假定固件分析了EP0 SETUP包得到主机的请求是读取某个描述符，固件随后应该进入数据阶段，但只是流程逻辑上的进入，具体的操作还要等待主机的控制IN令牌到达后，才能开始数据阶段真正的数据传输，之后进入状态阶段。一般地，状态阶段只需设定一个寄存器通知芯片开始状态阶段即可，无需干预其细节。主机对设备的识别最初是通过控制管道来进行的，一系列控制传输（主机识别设备的请求）完成之后，主机就能识别到USB设备了，在设备管理器中会显示出来（但是不一定能完全正常地使用设备，因为可能还有一些协议并未完成，例如Mass Storage设备还需对SCSI命令正确响应，文档的第3部分会有具体讲述）。

关于请求：
第一，主机首先会发出一系列标准请求。
第二，在标准请求完成之后，会发出两个类请求：Bulk-Only Mass Storage Reset请求和Get Max LUN请求。这两个请求的格式可以在USB Mass Storage Class Bulk-Only Transport文档中查询。

Bulk-Only Mass Storage Reset没有数据阶段，只在状态阶段告诉主机设备的Reset过程完成与否。如果在状态阶段返回ACK，那么主机就认为设备已经Reset完毕并准备好接收CBW了。
Get Max LUN要求设备返回一个字节的数据给主机，以表明此USB设备有多少个逻辑设备。返回的这个数据就是最大的设备逻辑号（Logic Unit Number），范围是0到15。例如，如果返回2，那么代表有0、1、2三个逻辑设备。

2、USB Mass Storage设备的Bulk数据交换流程
通过bulk端点进行的数据传输，都遵循这样一个过程，即三个阶段：
CBW->DATA->CSW
CBW是一个数据块，携带主机发给设备的SCSI命令。接收了CBW后，设备就可以从中知道在接下来的DATA阶段中该干什么。
DATA阶段有三种情况：无数据需要传输，IN传输（设备到主机）或OUT传输（主机到设备）。
CSW阶段反馈这次传输的结果给主机。

其中值得注意的是:

- 在设备枚举完成之后，主机发出的第一个bulk OUT事务就是请求向设备发出CBW。所以设备可以通过这第一次的bulk OUT事务来判定第一次bulk数据传输的开始。此后的bulk数据传输就按照上述的三个阶段反复执行。也就是说，第一次传输CBW后，如果有数据要传输，那么就会经历DATA阶段，然后进入CSW阶段；如果没有数据要传输，则直接进入CSW阶段，就此一次传输结束。接下来，如果又有传输，那么再发出CBW。因此，设备可以认为CSW完成后收到的下一个bulk OUT事务就是主机请求传输新的CBW。

- CBW[12]（CBW数据块的第13个字节）指明了传输方向，CBW[8-11]指明了传输的数据长度。实际上，CBW中的SCSI命令就暗含了数据要传输的方向和数据长度，因为SCSI规范中已明确规定这个命令所对应的数据格式。（在完整的应用中，要将CBW中的传输方向、数据长度与SCSI命令所表明的传输方向和数据长度做比较，不对应就要进行错误处理（Mass Storage Bulk-Only文档中有相关描述），不过正常情况下二者是匹配的，试验的时候可以暂时不理）。

- CSW[12]（CSW数据块的第13个字节）这个字节很重要，它为0则表示此次传输成功，非0就是不成功。在DATA阶段的数据传完（或者无需数据传输）之后，主机会发出IN事务请求设备返回CSW。如果CSW传送的是不成功的信息，那么主机会接着发送另一个命令来获取失败的详细信息（即RequestSense命令）。

3、Mass Storage设备所使用的SCSI命令集
0x00    TestUnitReady
0x03    RequestSense
0x12    Inquiry
0x1A    ModeSense6
0x1B    StartStop
0x1E    MediumRemoval
0x23    ReadFormatCapacity
0x25    ReadCapacity
0x28    Read(10)
0x2A    Write(10)
0x2F    Verify
0x5A    ModeSense10

其中，
- 主机首先发出Inquiry命令，响应了Inquiry之后就可以看到盘符.
- Inquiry之后会发出ReadFormatCapacity命令，这个命令在SCSI规范中是“厂家自定义命令”,可以参考UFI命令集文档（实际上，U盘所使用的所有SCSI命令集都可以参考UFI文档，它比SCSI标准文档更简洁明了）。注意这个命令在BusHound里是没有描述的，必须在“Device”选项页里勾选上这个U盘所对应的USB Mass Storage Device这个节点，才能看到这个命令的数据流。
- ReadFormatCapacity之后会发出ReadCapacity命令。
- U盘读数据（读扇区）时会发送Read(10)。ReadCapacity完成后就会发送Read(10)读取U盘的第一个扇区。
- U盘写数据时（写扇区）会发送Write(10)。
- TestUnitReady会在无其他数据传输时会定时发送，如果设备没有回应成功的CSW给主机，则主机认为设备已不存在。此时如果再双击磁盘图标，Windows会提示“请插入磁盘”。
- Verify在写数据时有用，表示核实数据，一般直接返回成功的CSW就可以了。一般来说，数据校验的工作在接收和向介质写数据时就已经顺带做了，如果发现错误，则直接告诉主机那次的数据传输有误，不会等到主机Verify时。当然，这不是一个必然的方案。
- RequestSense：如果CSW指示此次传输不成功，那么主机会发出此请求。
- StartStop暂时未发现大用处，一般直接返回成功的CSW。
- MediumRemoval在U盘被Eject的时候有用，处理不正确会Windows会弹出错误信息。
- ModeSense6/10这两个命令可以不支持（不支持不代表不反应，任何一个命令你都要做出反应，对于不支持的命令，可以通过STALL握手来向主机表明），暂时也未遇到过什么异常情况，而且我查看过一些U盘，有相当一部分就是随便回了几个数据给主机。这两个命令只会在U盘插入后发送一次，此后不再发送。