CN114036081A - 基于依赖注入式设备库的usb cdc驱动方法 - Google Patents

基于依赖注入式设备库的usb cdc驱动方法 Download PDF

Info

Publication number
CN114036081A
CN114036081A CN202111351273.7A CN202111351273A CN114036081A CN 114036081 A CN114036081 A CN 114036081A CN 202111351273 A CN202111351273 A CN 202111351273A CN 114036081 A CN114036081 A CN 114036081A
Authority
CN
China
Prior art keywords
equipment
usb
cdc
database
library
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202111351273.7A
Other languages
English (en)
Other versions
CN114036081B (zh
Inventor
秦飞虎
唐剑
卢炬
吴平
余彧
谢乾
盛金华
彭铮
王杰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kunshan Byosoft Electronic Technology Co ltd
Nanjing Byosoft Co ltd
Shanghai Baizhiao Information Technology Co ltd
Jiangsu Zhuoyi Information Technology Co ltd
Original Assignee
Kunshan Byosoft Electronic Technology Co ltd
Nanjing Byosoft Co ltd
Shanghai Baizhiao Information Technology Co ltd
Jiangsu Zhuoyi Information Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kunshan Byosoft Electronic Technology Co ltd, Nanjing Byosoft Co ltd, Shanghai Baizhiao Information Technology Co ltd, Jiangsu Zhuoyi Information Technology Co ltd filed Critical Kunshan Byosoft Electronic Technology Co ltd
Priority to CN202111351273.7A priority Critical patent/CN114036081B/zh
Publication of CN114036081A publication Critical patent/CN114036081A/zh
Application granted granted Critical
Publication of CN114036081B publication Critical patent/CN114036081B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0042—Universal serial bus [USB]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Systems (AREA)

Abstract

本发明公开一种基于依赖注入式设备库的USB CDC驱动方法，属于计算机技术领域，通过USB ID创建组合驱动，实现多个接口在一个CDC设备中的协同工作；根据USB CDC规范及设备类规范架构的特点，给出驱动模块管理设备类数据库的模型，建立设备类数据库，在设备数据库方面应用依赖注入思想，设备类库数据完全由设备类注入。本发明打破现有USB驱动模型每类设备都需要独立的驱动模块的模式，通过USB ID来创建组合驱动，实现设备内多接口在一个CDC设备中的协同工作，设备间能共享通用层数据。通过试验证明，本发明对USB CDC设备具有更高可识别性，对所有USB ECM/NCM设备都适用。

Description

基于依赖注入式设备库的USB CDC驱动方法
技术领域
本发明属于计算机技术领域，具体涉及一种基于依赖注入式设备库的USB CDC驱动方法。
背景技术
当前的UEFI USB驱动模型是按USB接口来建立控制器句柄，并通过控制器句柄来尝试UEFI BIOS(统一的可扩展固件接口基本输入输出系统)系统中是否有驱动模块来驱动该控制器。这种模型下，一个USB接口对应一个控制器，进而对应一个驱动模块。这对于目前UEFI BIOS中的常用设备如USB键盘/鼠标/USB存储设备是没有问题的。因为这几类设备仅仅需要在单个接口上就能进行设备操纵了。
这种按接口来匹配驱动的模型有什么缺点呢？缺点就是：不是所有USB设备仅仅靠单一接口就能完成其功能的。作为证据：USB CDC1.2/1.0是关于通信设备类的规范。该规范就明确规定：一个USB通讯设备包含一个USB通讯接口用来管理设备比如网络连接状态等；该设备可能包含一个USB数据接口用来处理数据包的发送。如果UEFI BIOS需要以USB CDC的协议方式从USB网卡中启动PXE，就必须要求USB通讯接口和数据接口协作才能完成通讯任务。
现有UEFI BIOS是不支持USB CDC设备的，平时我们看到的BIOS能通过USB网卡启动那是因为使用了厂商的Inhouse驱动，而且不同厂商的芯片也需要不同驱动。如果BIOS真的支持CDC规范，就不存在依赖厂商驱动的问题，任何USB CDC设备都应该能驱动起来，原因就是管理方式和数据收发都有相应的设备类规范定义如NCM1.0。
发明内容
本发明解决的技术问题：本发明提供一种通过USB ID来创建组合驱动，实现设备内多接口在一个CDC设备中的协同工作，设备间能共享通用层数据的基于依赖注入式设备库的USB CDC驱动方法。
技术方案：为了解决上述技术问题，本发明采用的技术方案如下：
一种基于依赖注入式设备库的USB CDC驱动方法，通过USB ID创建组合驱动，实现多个接口在一个CDC设备中的协同工作；根据USB CDC规范及设备类规范架构的特点，给出驱动模块管理设备类数据库的模型，建立设备类数据库，在设备数据库方面应用依赖注入思想，设备类库数据完全由设备类注入，或者将设备的操作直接集成到驱动模块。
作为优选，驱动模块管理设备类数据库的模型包括UsbCdcDriver、CDC设备数据库和USB CDC设备库；
一个UsbCdcDriver驱动管理所有USB CDC网络类型的设备，UsbCdcDriver实现USBCDC规范中的通用层操作，与设备类数据库通讯，建立设备信息管理表，最后安装简单网络协议从而实现USB CDC设备到网络协议栈的连接；
CDC设备数据库提供众多USB CDC设备类的数据模板，每个设备模板是由独立的模板库通过CONSTRUCTOR方式注入到设备数据库中，模板间完全无耦合，不同类型的模板分别处理USB CDC某个子类型设备。
作为优选，UsbCdcDriver包括以下不同种类的协议或者服务：驱动绑定协议DBP，简单网络协议SNP，UsbCfgUpdateEventHandle服务。
作为优选，驱动绑定协议实现UEFI DRIVER类型的标准服务，利用同一个USB设备共享唯一的ID，当一个新的接口进来后，利用该接口路径的转换出一个ID作为设备ID；如果该ID不在UsbCdcDriver管理设备中，则意味着一个新的USB CDC设备需要创建；如果该ID在UsbCdcDriver管理设备中，则意味着该接口对应的控制器需要和已经发现ID的设备中的控制器协同工作，被组合的接口数量在UsbCdcDriver层不受限制。
作为优选，简单网络协议提供所有USB CDC网络类型设备的简单网络协议模板，简单网络协议中的服务被所有实例共用，如果某服务有底层操作则调用设备类库提供的操作。
作为优选，UsbCfgUpdateEventHandle函数中，部分USB设备有多个USB配置用来支持Inhouse模式和USB CDC模式，如果当前配置不满足要求，但是该设备存在CDC配置，则需要在USB设备枚举上下文外重设USB配置，该函数从Ring取出数据，将相应的设备进行重设配置。
作为优选，驱动绑定协议实现UsbCdcSupported服务、UsbCdcStart服务和UsbCdcStop服务；
UsbCdcSupported服务先检测通用CDC通用层的规定，如果通用层满足要求，则通过USB控制器句柄来查询CDC设备数据库是否有模板支持该类型设备，如果数据库返回支持，则返回成功；如果数据库返回该句柄需要选择新的USB配置，则提交数据给异步函数UsbCfgUpdateEventHandle，然后返回失败；
UsbCdcStart服务完成以下三项操作：1、建立UsbCDC设备管理信息表，该信息表中包含设备ID，以及设备的需要被协作所有控制器，设备信息表是按USB设备数来管理，而设备数据库是按CDC设备类来组织，一个设备类可以有多个属于该类的设备；2.查询设备数据库，调用Probe函数继续初始化该设备的信息表；3.安装简单网络协议；
UsbCdcStop服务完成设备层复位操作，释放对应设备的管理信息，以及完成UEFI协议层的终止。
作为优选，UsbCfgUpdateEventHandle服务中，部分USB设备有多个USB配置用来支持Inhouse模式和USB CDC模式，如果当前配置不满足要求，但是该设备存在CDC配置，则需要在USB设备枚举上下文外重设USB配置。该函数从Ring取出数据，将相应的设备进行重设配置。
有益效果：与现有技术相比，本发明具有以下优点：
本发明除了解决目前UEFI开源代码中缺乏对USB通讯设备类的支持外，还打破现有USB驱动模型每类接口都需要独立驱动模块的模式。因为USB CDC设备可能需要多个接口协作才能完成功能。本发明根据USB CDC规范特点，在设备内利用USB接口形成的USB ID构建组合驱动；在设备间利用设备类数据库处理专属该类的操作以及共享来自CDC通用层数据；同时为了减小设备库的耦合度，本申请在设计中利用依赖注入式理念，设备库的支持由设备库自行注入到系统，通用层通过数据库操作新的设备。本发明正是基于USB CDC1.2/1.0规范上设计出来，对USB CDC各种设备的支持具有更好的普适性，对将来新出现的CDC设备的支持也具有更好的可扩展性，当前的设备库对所有USB ECM/NCM设备都适用。
附图说明
图1是基于依赖注入式设备库的USB CDC驱动方法结构示意图；
图2是Driver Binding Protocol协议的UsbCdcSupported服务执行流程图；
图3是Driver Binding Protocol协议的协议的UsbCdcStart服务执行流程图；
图4是Driver Binding Protocol协议的UsbCdcSop服务执行流程图；
图5是UsbCfgUpdateEventHandle服务执行流程图；
图6是ECM设备类模板接口函数Probe()执行流程图；
图7是ECM设备类解析USB CDC Functional Descriptors；
图8是ECM&NCM设备类复位流程图；
图9是ECM&NCM设置MacAddress流程图；
图10是ECM发数据包流程图；
图11是ECM收数据包流程图；
图12是NCM设备类模板接口函数Probe()执行流程图。
具体实施方式
下面结合具体实施例，进一步阐明本发明，实施例在以本发明技术方案为前提下进行实施，应理解这些实施例仅用于说明本发明而不用于限制本发明的范围。
现有UEFI BIOS是不支持USB CDC设备的，平时我们看到的BIOS能通过USB网卡启动那是因为使用了厂商的Inhouse驱动，而且不同厂商的芯片也需要不同驱动。如果BIOS真的支持CDC规范，任何USB CDC设备都可以直接驱动起来。
本发明的重点不是“如何使UEFI BIOS支持USB CDC的”，而是“当前USB设备驱动这种单一的扁平结构不能适配USB CDC这种上下层的组织架构，进而公开一种让设备内多接口协同工作，设备间能共享通用层数据的CDC设备类模型”。
本发明的基于依赖注入式设备库的USB CDC驱动方法，通过USB ID创建组合驱动，实现多个接口在一个CDC设备中的协同工作；根据USB CDC规范及设备类规范(如USBNCM1.0/USB ECM1.2)架构的特点，给出驱动模块管理设备类数据库的模型，建立设备类数据库，在设备数据库方面应用依赖注入思想，设备类库数据完全由设备类注入；如果目标系统仅仅只需要支持1类或者2类CDC设备，也可以直接将这2类设备的操作直接集成到驱动模块而不需要建立设备数据库，但是这无疑增加了USB CDC设备类驱动的耦合度。
如图1所示，本发明的驱动模块管理设备类数据库的模型包括UsbCdcDriver、CDC设备数据库(CDC Class Database)和USB CDC设备库三大块；下面对三大块的内容进行具体的描述。
UsbCdcDriver：本发明可以实现一个UsbCdcDriver驱动管理所有USB CDC网络类型的设备，具体的，UsbCdcDriver实现USB CDC规范中的通用层操作，与设备类数据库通讯，建立设备信息管理表，最后安装SNP协议从而实现USB CDC设备到USB网络协议栈的连接；此处SNP协议中的各种服务就能充分展现其优点，比如SNP协议中的设置MAC地址服务，先利用SNP*This指针取出该设备类信息，然后调用设备类中的SetMacAddress。如此，就没必要为NCM设备类写一套代码安装SNP协议，为ECM设备类写一套代码安装SNP协议了。因为它们中的绝大部分代码都是相同的，仅仅底层的USB操作不同而已。本发明将所有通用操作置于UsbCdcDriver中，而设备层的操作被各种设备库注入到数据库中。
CDC设备数据库(CDC Class Database)：提供众多USB CDC设备类的数据模板，每个设备模板是由独立的模板库通过CONSTRUCTOR方式注入到设备数据库中，模板间完全无耦合，不同类型的模板分别处理USB CDC某个子类型设备。例如USB NCM网卡的支持由NCM库注入到CDC设备数据库，而USB ECM网卡的支持则由ECM库注入。
USB CDC设备库：USB CDC设备库包括各种USB CDC网络类型的设备，例如NCM设备类，ECM设备类等等。
如图1所示，UsbCdcDriver包括以下不同种类的协议或者服务：驱动绑定协议(DBP，Driver Binding Protocol)，简单网络协议(SNP，Simple Network Protocol)，UsbCfgUpdateEventHandle服务等。
驱动绑定协议实现UEFI DRIVER类型的标准协议，利用同一个USB设备共享唯一的ID，当一个新的接口进来后，利用接口路径转换出一个ID作为设备ID；如果该ID不在UsbCdcDriver管理设备中，则意味着一个新的USB CDC设备需要创建；如果该ID在UsbCdcDriver管理设备中，则意味着该接口对应的控制器需要和已经发现ID的设备中的控制器协同工作，被组合的接口数量在UsbCdcDriver层不受限制。
简单网络协议提供所有USB CDC网络类型设备的服务模板，简单网络服务被所有实例共用，如果某服务有底层操作则调用设备类库提供的操作。比如NCM收发数据包；实例的数据则部分来自设备类库层，比如最大网络数据包大小。
其中，驱动绑定协议实现UsbCdcSupported服务、UsbCdcStart服务和UsbCdcStop服务，具体如下：
UsbCdcSupported服务：先检测通用CDC通用层的规定，如果通用层满足要求，则通过USB控制器句柄(USB Controller Handle，由UEFI USB总线驱动模块创建)来查询CDC设备数据库是否有模板支持该类型设备，如果数据库返回支持，则返回成功；如果数据库返回该句柄需要选择新的USB配置，则提交数据给异步函数UsbCfgUpdateEventHandle，然后返回失败。
UsbCdcStart服务完成以下三项操作：1、建立UsbCDC设备管理信息表，该信息表中包含设备ID，以及设备的需要被协作所有控制器，设备信息表是按USB设备数来管理，而设备数据库是按CDC设备类来组织，一个设备类可以有多个属于该类的设备；2.查询设备数据库，调用Probe函数继续初始化该设备的信息表；3.安装SNP。
如图3所示，流程图中的ConvertUsbDevicePathToString()，先调用HandleProtocol(Controller，gEfiDevicePathProtocolGuid，&DevicePath)找到当前控制器的DevicePath，如果成功再复制NewDp＝DuplicateDevicePath(DevicePath)，最后调用ConvertDevicePathToText(NewDp)转为StringID，这里不再给出流程图；
RetriveCdcDeviceById()，就是搜索全局设备链表gCdcList，用StrCmp比较有没有哪个设备的ID和上面的ID一样，如果没有，则意味着当前USB是新的，否则，这意味着当前控制器可以和已经发现的这个设备组合起来使用；至于能不能组合以及最大需要组合多少个控制器才能满足要求，那决定于每个设备类的Probe()，如果本次返回USB_CDC_COMPLT，则意味着组合已经达到了要求，如果返回USB_CDC_OK，仅仅意味着当前控制器对应的信息被成功的建立在该设备的信息表*CdcDeviceInfo中。
最后InstallSNPTemplate()函数，对于NCM/ECM网络设备，最终得结果是安装SNP，该协议在当前的UEFI开源代码中有多个实例，此处重点指出跟USB CDC层有关的：
SNP.Mode.ReceiveFilterMask中的Mast Bits能支持多少位，主要来自NCM/ECM在通讯接口(Communication Interface)上的命令。最后能支持多少位取决于物理USB对这些命令的返回；
SNP.Mode.MaxPacketSize在来自Functional Descriptor(功能描述)；
SNP.ReceiveFilters服务，在NCM&ECM SetEthemetPacketFilter是可选支持；参数MCastFilterCnt和MCastFilter则涉及到另外一个命令SetEthemetMulticastFilters；
SNP.Start服务，由于NCM&ECM规范都指出设备复位导致SetEthemetPacketFilter中的设备被复位，所以，在SNP.Start和SNP. Shutdown后，最好在服务再调用SetEthernetPacketFilter；
SNP.Statistics服务，在NCM&ECM中有很多统计数据，但是命令则是可选支持；
SNP.StationAddress服务，在NCM&ECM中SetNetAddress是可选支持，如果物理设备不支持SetNetAddress，则设置SNP.Mode.MacAddressChangeable＝FALSE；
SNP.Transmit和SNP.Receive中关于CDC部分，ECM流程图中已经给出。
如图4所示，UsbCdcStop服务完成设备层复位操作，释放对应设备的管理信息，以及完成UEFI协议层的终止。比如卸载对应的SNP，关闭已经在绑定句柄(BindHanlde)上打开的USB IO协议等。
如图5所示，UsbCfgUpdateEventHandle服务中，部分USB设备有多个USB配置用来支持Inhouse模式和USB CDC模式，如果当前配置不满足要求，但是该设备存在CDC配置，则需要在USB设备枚举上下文外重设USB配置。该函数从Ring取出数据，将相应的设备进行重设配置。
USB CDC设备库的ECM注入库：
ECM模板与NCM模板流程基本一样，只不过ECM解析USB CDC功能描述(FunctionalDescriptors)的时候，按ECM1.2解析，建议考虑ECM1.1/ECM1.0，这也是为什么在NCM解析的时候，验证部分是可选的，如果太严格，可能到物理连接上的USB CDC设备不过。实际上，只需要得到USB通讯接口和数据接口即可。如图6所示为，为ECM设备类模板接口函数Probe()执行流程图，图7是ECM设备类解析USB CDC Functional Desc如tors；图8是ECM&NCM设备类复位流程图；图9是ECM&NCM设置Mac Address；图10是ECM发数据包流程图；图11是ECM收数据包流程图；
USB CDC设备库的ECM注入库：
如图12所示，每种CDC设备模板都由统一接口提供Probe()函数，目的是检查是否支持当前USB设备，以及填写来自UsbCdcDriver层的设备管理信息表。设备的信息表和SNP结构被关联在一个私有结构体种，当需要进行SNP服务的时候，根据该实例的This指针得到该设备的信息表，从而得到对应的设备操作。在ECM注入库部分会列举ECM设备的重点操作流程。
ECM设备类库的EcmLibConstructor
所有USB CDC设备数据库都是通过inf file中的CONSTRUCTOR来构建。入口主要是将mUsbCdcPlugIn的数据结构注册到CdcDeviceDataBase中；所有USB CDC设备的PlugIn数据结构是通用类型，主要提供设备类的Probe函数。
Figure BDA0003355483300000081
Name说明模板库的名字，后面推荐到版本号。
Priority在Probe过程中的优先级，数值小的则先Probe，同等级按登记的次序Probe。由于目前已经实现NCM和ECM模块，该参数没有测试。
Probe指向模板的Probe函数，其中参数Controller是USB Interface对应的句柄，参数CurrentInterface是当前接口，参数CfgNums是当前设备含有的USB配置描述的个数，该数据需要USB_CDC_STATUS配合，参数NewCfgNo模板请求使用的配置，参数CdcDeviceInfo设备类信息表，参数TotalCfg和LenTotalCfg是该设备总配置和总配置长度。在探查(Probe)过程中，如果发现当前接口不满足要求，模板应该从TotalCfg中去检查该USB设备是否含有模板要求的接口比如接口类别和子类别等。值得注意的是该参数以指针的指针出现，因为TotalCfg包含的是该USB设备的所有配置数据，没有任何必要在每个模块中去读取所有配置。当先探查的模块拿到它的时候，*TotalCfg是空，该模块如果发现当前接口不满足要求，则读取该设备的所有配置，这样后探查的模块可以使用前面的模板已经读出来的TotalCfg。具体函数流程参考前面章节。
Probe函数的返回值有三个值得关注，USB_CDC_COMPLT表示当前组合控制器达到要求可以开始组合功能，USB_CDC_RECONFIG表示该模板请求重新配置，USB_CDC_OK表示当前Probe函数正常返回，别的值都表示错误。
NCM设备类库：
NCM设备的详细操作可以参考ECM模板推导NCM的建立过程。文档上参考USBNCM1.0规范，这里仅仅指出NCM与ECM的主要差别在NCM的数据包是有NTB格式规定的，同一个NTB包可以封装多个以太网包，而ECM则是裸的单个以太网包。对于来自USB NCM设备的NTB格式包，需要解析出以太网包，然后传给网络协议栈；来自网络协议栈的以太网包则需要封装在NTB中，然后传给NCM设备以便其发送数据。至于如何解析和封装NTB包，部分参数来自NCM通讯接口(NCM Communication Interface)上的命令。这也是为什么本发明强调通讯接口和数据接口协作才能完成CDC功能的重要原因。
UsbCdcDeviceRegisterLib库：
该库的主要功能是为每个CDC设备库函数提供简化的接口Register(注册)函数，调用此函数后，每个USB CDC设备类的USB_CDC_PLUGIN会被注册到对应的优先级链表中，目前设计中的优先级有4级。优先级的原因是考虑将来新CDC设备类规范出现导致可能会多个模板匹配到同一个物理USB设备，在此条件下，模板库可以提升模板匹配优先级。
UsbCdcDatabase模块：
该模块类别是DXE驱动，无特殊依赖需求。该模块主要是安装USB CDC数据库协议，以便为UsbCdcDriver提供Probe服务，该服务则完全来自UsbCdcDeviceRegisterLib库，本质上UsbCdcDeviceRegisterLib库和UsbCdcDatabase是一体的，UsbCdcDeviceRegisterLib库仅仅为给CDC设备类提供Register库函数。
本发明已经实现ECM1.2/1.0设备类和NCM1.0设备类的支持，在2款RealtekUSBRTL8152 RTL8153芯片的网卡上做OS启动测试：
该发明运用前，需要Realtek官方发布的inhouse驱动才能让BIOS启动OS。并且发现如果老的官方驱动，不能支持Usb2.5G的那款芯片。但是当使用该发明后，两款USB网卡都能启动。此测试显示：inhouse驱动虽然是官方的，但是依然需要靠版本才能支持最新的芯片。
在BMC linux kemel(内核)中开启USB Over LAN功能后，Realtek官方的inhouse驱动不支持BMC创建的USB CDC设备，进而导致BIOS不能通过USB接口跟BMC进行USB OverLAN通讯，但是当使用该发明后，在EFI shell下面可以ping通BMC的USB网卡。
上述两项测试表明，本发明对USB CDC设备具有更高可识别性。准确地讲：该发明对所有USB ECM/NCM设备都适用。
以上仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (8)

1.一种基于依赖注入式设备库的USB CDC驱动方法，其特征在于，包括：通过USB ID创建组合驱动，实现多个接口在一个CDC设备中的协同工作；根据USB CDC规范及设备类规范架构的特点，给出驱动模块管理设备类数据库的模型，建立设备类数据库，在设备数据库方面应用依赖注入思想，设备类库数据完全由设备类注入，或者将设备的操作直接集成到驱动模块。
2.根据权利要求1所述的基于依赖注入式设备库的USB CDC驱动方法，其特征在于：驱动模块管理设备类数据库的模型包括UsbCdcDriver、CDC设备数据库和USB CDC设备库；
一个UsbCdcDriver驱动管理所有USB CDC网络类型的设备，UsbCdcDriver实现USB CDC规范中的通用层操作，与设备类数据库通讯，建立设备信息管理表，最后安装简单网络协议从而实现USB CDC设备到网络协议栈的连接；
CDC设备数据库提供众多USB CDC设备类的数据模板，每个设备模板是由独立的模板库通过CONSTRUCTOR方式注入到设备数据库中，模板间完全无耦合，不同类型的模板分别处理USB CDC某个子类型设备。
3.根据权利要求2所述的基于依赖注入式设备库的USB CDC驱动方法，其特征在于：UsbCdcDriver包括以下不同种类的协议或者服务：驱动绑定协议，简单网络协议，UsbCfgUpdateEventHandle服务。
4.根据权利要求3所述的基于依赖注入式设备库的USB CDC驱动方法，其特征在于：驱动绑定协议实现UEFIDRIVER类型的标准服务，利用同一个USB设备共享唯一的ID，当一个新的接口进来后，利用该接口路径的转换出一个ID作为设备ID；如果该ID不在UsbCdcDriver管理设备中，则意味着一个新的USB CDC设备需要创建；如果该ID在UsbCdcDriver管理设备中，则意味着该接口对应的控制器需要和已经发现ID的设备中的控制器协同工作，被组合的接口数量在UsbCdcDriver层不受限制。
5.根据权利要求3所述的基于依赖注入式设备库的USB CDC驱动方法，其特征在于：简单网络协议提供所有USB CDC网络类型设备的简单网络协议模板，简单网络协议中的服务被所有实例共用，如果某服务有底层操作则调用设备类库提供的操作。
6.根据权利要求3所述的基于依赖注入式设备库的USB CDC驱动方法，其特征在于：UsbCfgUpdateEventHandle函数中，部分USB设备有多个USB配置用来支持Inhouse模式和USB CDC模式，如果当前配置不满足要求，但是该设备存在CDC配置，则需要在USB设备枚举上下文外重设USB配置，该函数从Ring取出数据，将相应的设备进行重设配置。
7.根据权利要求4所述的基于依赖注入式设备库的USB CDC驱动方法，其特征在于：驱动绑定协议实现UsbCdcSupported服务、UsbCdcStart服务和UsbCdcStop服务；
UsbCdcSupported服务先检测通用CDC通用层的规定，如果通用层满足要求，则通过USB控制器句柄来查询CDC设备数据库是否有模板支持该类型设备，如果数据库返回支持，则返回成功；如果数据库返回该句柄需要选择新的USB配置，则提交数据给异步函数UsbCfgUpdateEventHandle，然后返回失败；
UsbCdcStart服务完成以下三项操作：1、建立UsbCDC设备管理信息表，该信息表中包含设备ID，以及设备的需要被协作所有控制器，设备信息表是按USB设备数来管理，而设备数据库是按CDC设备类来组织，一个设备类可以有多个属于该类的设备；2.查询设备数据库，调用Probe函数继续初始化该设备的信息表；3.安装简单网络协议；
UsbCdcStop服务完成设备层复位操作，释放对应设备的管理信息，以及完成UEFI协议层的终止。
8.根据权利要求1所述的基于依赖注入式设备库的USB CDC驱动方法，其特征在于：UsbCfgUpdateEventHandle服务中，部分USB设备有多个USB配置用来支持Inhouse模式和USB CDC模式，如果当前配置不满足要求，但是该设备存在CDC配置，则需要在USB设备枚举上下文外重设USB配置。该函数从Ring取出数据，将相应的设备进行重设配置。
CN202111351273.7A 2021-11-15 2021-11-15 基于依赖注入式设备库的usb cdc驱动方法 Active CN114036081B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111351273.7A CN114036081B (zh) 2021-11-15 2021-11-15 基于依赖注入式设备库的usb cdc驱动方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111351273.7A CN114036081B (zh) 2021-11-15 2021-11-15 基于依赖注入式设备库的usb cdc驱动方法

Publications (2)

Publication Number Publication Date
CN114036081A true CN114036081A (zh) 2022-02-11
CN114036081B CN114036081B (zh) 2024-06-21

Family

ID=80137698

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111351273.7A Active CN114036081B (zh) 2021-11-15 2021-11-15 基于依赖注入式设备库的usb cdc驱动方法

Country Status (1)

Country Link
CN (1) CN114036081B (zh)

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1932789A (zh) * 2005-09-12 2007-03-21 美国凹凸微系有限公司 利用usb和外设部件互连功能的增强ccid电路和系统
CN101674267A (zh) * 2009-06-30 2010-03-17 中兴通讯股份有限公司 一种家庭网关及其实现usb设备驱动的方法
US7877788B1 (en) * 2006-02-27 2011-01-25 Teradici Corporation Method and apparatus for securing a peripheral data interface
US20110034162A1 (en) * 2007-12-21 2011-02-10 Telefonaktiebolaget L M Erricsson Technique for providing network access to different entities
CN103365818A (zh) * 2012-03-30 2013-10-23 上海盛轩网络科技有限公司 Usb组合设备及其实现方法
CN105745675A (zh) * 2013-11-29 2016-07-06 联邦快递服务公司 用于使用无线节点网络来管理物品的装运的方法和系统
US9432298B1 (en) * 2011-12-09 2016-08-30 P4tents1, LLC System, method, and computer program product for improving memory systems
CN108089999A (zh) * 2017-11-29 2018-05-29 郑州云海信息技术有限公司 一种多功能usb设备注册方法及系统
CN112199314A (zh) * 2020-10-29 2021-01-08 杭州雾联科技有限公司 基于网络的通用usb设备跨平台透传方法
CN112699071A (zh) * 2020-12-14 2021-04-23 北京握奇智能科技有限公司 一种基于Linux系统的USB端口绑定结构和方法

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1932789A (zh) * 2005-09-12 2007-03-21 美国凹凸微系有限公司 利用usb和外设部件互连功能的增强ccid电路和系统
US7877788B1 (en) * 2006-02-27 2011-01-25 Teradici Corporation Method and apparatus for securing a peripheral data interface
US20110034162A1 (en) * 2007-12-21 2011-02-10 Telefonaktiebolaget L M Erricsson Technique for providing network access to different entities
CN101674267A (zh) * 2009-06-30 2010-03-17 中兴通讯股份有限公司 一种家庭网关及其实现usb设备驱动的方法
US9432298B1 (en) * 2011-12-09 2016-08-30 P4tents1, LLC System, method, and computer program product for improving memory systems
CN103365818A (zh) * 2012-03-30 2013-10-23 上海盛轩网络科技有限公司 Usb组合设备及其实现方法
CN105745675A (zh) * 2013-11-29 2016-07-06 联邦快递服务公司 用于使用无线节点网络来管理物品的装运的方法和系统
CN108089999A (zh) * 2017-11-29 2018-05-29 郑州云海信息技术有限公司 一种多功能usb设备注册方法及系统
CN112199314A (zh) * 2020-10-29 2021-01-08 杭州雾联科技有限公司 基于网络的通用usb设备跨平台透传方法
CN112699071A (zh) * 2020-12-14 2021-04-23 北京握奇智能科技有限公司 一种基于Linux系统的USB端口绑定结构和方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
RENESAS SYNERGY™ PLATFORM: "Installing Synergy Signed USB CDC Driver", Retrieved from the Internet <URL:https://www.zebra.com/.../drivers/usb-cdc-driver.html> *

Also Published As

Publication number Publication date
CN114036081B (zh) 2024-06-21

Similar Documents

Publication Publication Date Title
US6263373B1 (en) Data processing system and method for remotely controlling execution of a processor utilizing a test access port
US8838812B2 (en) Network security enhancement methods, apparatuses, system, media, signals and computer programs
US20040203296A1 (en) Method and system for attaching a USB network adapter supporting both RNDIS and non-RNDIS capable operating systems
US5797031A (en) Method and apparatus for peripheral device control by clients in plural memory addressing modes
CN101110039B (zh) 终端设备自安装及自启动系统及方法
CN109426613B (zh) 在uefi中检索调试数据的方法及其电脑系统
US6915368B2 (en) Computer system and processing method for driving program of smart peripheral device
WO2011127845A2 (zh) 一种移动通信终端间进行系统升级的方法、系统及终端
CN101330399A (zh) 嵌入式设备的升级方法
CN100346298C (zh) 远程加载或升级程序的系统及其方法
CN105068946A (zh) 一种安卓设备的识别方法和装置
CN113010470A (zh) 边缘节点远程控制系统、方法、设备及存储介质
CN103092648B (zh) 一种镜像升级方法、系统及用户设备和个人计算机
US9069572B2 (en) Replacement of inbox driver with third party driver
CN112162765A (zh) 固件升级方法、上位机及存储介质
EP2713269B1 (en) Method for updating data card, personal computer and data card
CN110688235A (zh) Uefi固件与os间共享无线连接信息的系统及方法
US20090201944A1 (en) Controlling External Communication of Embedded Device Using Proxy Server
CN114036081B (zh) 基于依赖注入式设备库的usb cdc驱动方法
KR100801759B1 (ko) 슬레이브의 디버깅 방법 및 시스템
CN112506674B (zh) Linux系统下用户态TCP/IP协议栈与本地应用通信的系统及方法
CN116048640A (zh) 一种驱动计算机系统中iic设备正常工作的方法
US6715110B1 (en) External debug card sharing a communication bus
CN112257381B (zh) 一种AXI Crossbar设计电路验证方法和系统
CN218886572U (zh) 一种简单外设总线系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant