Understanding of USB driver

Understanding of USB driver
 
I have learned about USB drivers for more than two weeks. The following is a summary !!!!!!!!
1. Each device corresponds to a PDO, and each PDO corresponds to multiple FDO. In the driver, the corresponding PDO and FDO are not the hardware. For USER-to-KERNEL communication, the system packs each USER request into an IRP structure, sends it to the driver, and identifies the PDO in the IRP to identify the device to which the request is sent. In addition, in terms of driver loading, WDM does not recognize the driver name, but uses a 128-bit globally unique identifier GUID to recognize the driver, that is, each firmware has a GUID, which is used to identify the firmware.
2. the USB host driver complies with the WDM driver architecture and uses the IRP (I/O Request Packet) mechanism. However, the actual USB driver uses the URB (USB request block) structure to send requests to its hardware device. The USB driver is highly dependent on its bus driver (USBD. SYS), instead of directly communicating with the hardware using the hardware abstraction layer (HAL) function.
3. USBD is the most critical layer in USB system software. It is responsible for controlling all USB protocol operations and interrupt handling control. Main functions include device settings, resource management, data transmission (pipeline level), and public data definition. MPs queue and command. MPs queue is a logical connection between a device and a host. It can be divided into standard MPs queues and logical MPs queues. MPS queues are used to complete the requests that customers send through command interfaces, for example, set the device address, but USBD does not allow the customer to directly access the standard MPs queue of the device. The customer pipeline is managed by the customer and the corresponding data buffer zone is provided. The command mechanism allows the customer to access the device data and its control part in read/write mode. All the customer has to do is provide the USBD with the device address and related data buffer pointer. The functions provided by the command mechanism are mainly related to USB Bus Management, such as Device Configuration Management, device data access, bus device management, and current distribution.
4. USB device driver design
2000DDK + VC6.0 (only C can be used, not C ++)
Three key routines: DriverEntry, AddDevice, and ReadWrite
(1) DriverEntry, which completes global initialization. It is the main entry point of the kernel-mode driver.
Extern "C"
NTSTATUS DriverEntry (IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath)
With the important data structure PDRIVER_OBJECT, I/O manager uses it to define each device driver. DriverEntry mainly works to fill various function pointers in various domains of the driver object, these pointers indicate various child routines in the driver container for the operating system, including the following pointer members:
1. DriverUnload
2. DriverExtension-> AddDevice points to the AddDevice function of the driver.
3. DriverStartIo points to the driver's function for processing serial I/O requests. If the driver uses the standard IRP queuing method, set this member to point to the StartIo routine of the driver.
4. MajorFunction is a pointer array pointing to multiple IRP processing functions in the driver.
DriverObject-> DriverUnload = DriverUnload;
DriverObject-> DriverExtension-> AddDevice = AddDevice;
DriverObject-> MajorFunction [IRP_MJ_CREATE] = DispatchCreate;
~~~~~~~~~~~~~~
(2) AddDevice
A driver can be used by multiple devices. The WDM driver has a special AddDevice function, which is called by the PnP Manager for each instance. The prototype is as follows:
NTSTATUS
AddDevice (IN PDRIVER_OBJECT DriverObject,
IN PDEVICE_OBJECT PhysicalDeviceObject );
The basic responsibility of the AddDevice function is to create a device object and connect it to the device stack with the PDO base.
The procedure is as follows:
1) Use IoCreateDevice to create a device object and create a private extension object.
PDEVICE_OBJECT fdo;
NTSTATUS status = IoCreateDevice (DriverObject,
Sizeof (DEVICE_EXTENSION ),
NULL,
FILE_DEVICE_UNKNOWN,
FILE_DEVICE_SECURE_OPEN,
FALSE,
& Fdo );
2) initialize the Flag members of the device extensions and Device objects.
PDEVICE_EXTENSION pdc = (PDEVICE_EXTENSION) fdo-> DeviceExtension;
Fdo-> DeviceExtension;
Fdo-> Flag2 | = DO_BUFFERED_IO;
3) Call the IoAttachDeviceToDeviceStace function to put the new device object on the stack.
Pdx-> LowerDeviceObject = IoAttachDeviceToDeviceStack (fdo, pfo );
The device object (DEVICE_OBJECT or * PDEVICE_OBJECT) is also an important structure defined by DDK. It can be named as a device object in the device name (DeviceName) field (the third parameter. Another key field of a device object is the size of the device object (DeviceExtension). The I/O manager allocates a piece of memory for the device object. This pointer points to a user-defined data structure, stores information about each device instance.
Typedef struct _ DEVICE_EXTENSION
{
PDEVICE_OBJECT DeviceObject; // device object this extension
// Belongs
PDEVICE_OBJECT LowerDeviceObject; // next lower driver in // same stack
PDEVICE_OBJECT Pdo; // the PDO
IO_REMOVE_LOCK RemoveLock; // removal control locking structure
UNICODE_STRING ifname; // interface name
DEVSTATE state // current state of device
DEVSTATE prevstate; // state prior to removal query
DEVICE_POWER_STATE devpower; // current device power state
SYSTEM_POWER_STATE syspower; // currnet system power state
DEVICE_CAPABILITIES devcaps; // copy of most recent device capabilities
LONG handles; // # open handle
USBD_DEVICE_DESCRIPTOR dd; // device descriptor
USBD_CONFIGURATION_HANDLE hconfig; // selected configuration handle
PUSB_CONFIGURATION_DESCRIPTOR pcd; // Configuration descriptor;
LANGID langid; // default language id for strings
USBD_PIPE_HANDLE hPipe;
USBD_PIPE_HANDLE hPipe_WriteCode;
} DEVICE_EXTENSION, * PDEVICE_EXTENSION;
AddDevice registers an interface for the device object so that the application can access the device through the registration interface. A device interface is uniquely identified by a 128-bit GUID.
Status = IoRegisterDeviceInferface (pdo, & GUID_INTERFACE_USB, NULL, & pdx-> ifname); after the GUID is obtained, when the driver calls the following function to make it available in response to the PnP request IRP_MN_START_DEVICE, ioSetDeviceInterfacestate (& pdx-> ifname, TRUE );
In response to this call, I/O manager creates a PDO connection object pointing to the device. Because the interface name finally points to PDO, the security descriptor of PDO controls the access permission of the device. (3) ReadWrite implements the dispatch functions of the device driver and bus enumeration and management functions for device initialization and error recovery. Is the most important part of the entire driver. In this example, the host requires the device to transmit data to it.
1) Create and submit an URB. the USB driver never directly talks to the hardware. You can complete hardware operations by creating the URB and submitting the URB to the bus driver. SYS is an entity that accepts URB. Calls to USBD are converted to IRP with the main function code IRP_MJ_XXX. Then USBD schedules the bus time and sends out the operation specified in URB.
Creating an URB is the most basic work of the USB driver. First, you should allocate memory for the URB, and then call the initialization routine to fill in the fields in the URB structure with the requested content. Finally, you can create and send an internal I/O Control (IOCTL) request to the USBD driver to send this URB package to complete the USB request.
2) create and send an IOCTL request
After creating the URB, we create and send an IOCTL (internal I/O Control) request to USBD, and then wait for the device to respond. The corresponding function is SendAwaitUrb.
3) return to the device completion status
 

 

 

Trackback: http://tb.blog.csdn.net/TrackBack.aspx? PostId = 1491604