Linux-based USB subsystem learning, linuxusb Subsystem

Source: Internet
Author: User

Linux-based USB subsystem learning, linuxusb Subsystem


I. References


1.Introduction to basic USB knowledge

Http://www.crifan.com/files/doc/docbook/usb_basic/release/html/usb_basic.html

2.USB in a NutShell

Http://www.beyondlogic.org/usbnutshell/usb1.shtml

3.USB development (version 4)

Http://download.csdn.net/download/qqqq419276485/7839403


2. Basic knowledge about USB


2.1 USB hardware knowledge


In terms of physical logical structure, USB devices includeHostAndDevice. The Host has the corresponding hardware USBHost ControllerAnd the device connects to the correspondingUSB device. There are four types of USB Host controllers:OHCIAndUHCI,EHCI, AndXHCIThe differences and relationships between them are shown in the following table.


The USB standard interface pin is defined as follows, including a power cord, a ground wire, and two signal lines. There are many USB interface pins and they will not be expanded here, refer to the articles USB 2.0 A, B, Mini and Micro Interface Definition and encapsulation and USB 3.0 connector pin, interface definition and encapsulation size. It is worth mentioning that at present, most mobile phone manufacturers have announced unified useMicro USB InterfaceAsMobile phone charger Standard Interface.



2.2 USB software knowledge


To make the USB device work properly, in addition to hardware, software support is also required. ForUSB deviceFor example, a device driver is needed internally, which is calledFirmwareIt implements what the USB device needs to do. It mainly involves some standard requests and reads and writes data. InHost, Also need the corresponding driver, this part of the driver, whether in Linux or Windows, has achieved a common driver, so in general, few developers need to write related drivers.

When a problem occurs in the development phase of the device driver or USB, debugging is usually required.USB debugging tool. Generally, the corresponding USB hardware testing tools are included, and the corresponding software tools are added to capture data on the corresponding USB bus, that is, the so-called USB packet capture, then analyze the captured data, whether it is expected, whether it complies with the USB protocol specification definition. In addition, of course there are someUSB development tools, Specific tools can be queried online.


Iii. Overview of USB protocol


For the USB 2.0 and USB 3.0 protocol specifications, you can go to the official website to download:

Http://www.usb.org/developers/docs/

The USB protocol has a large number of document pages, so you do not need to read the entire USB standard. Here, we will take the USB 2.0 specification as an example to analyze what content it mainly contains. You will find that there is not so much content related to the USB protocol itself, and there are only about 97 pages of content, which we need to care about.



Appendix 1: notes on USB 2.0 standard protocol specifications


Chapter 1 Architecture Overview


This chapter provides an overview of the general Serial Bus (USB) architecture and important concepts. USB is a wired bus that supports data exchange between host computers and peripherals that can be accessed at the same time in a large range. Ancillary peripherals share USB bandwidth through a host scheduling and Token-based protocol. The bus allows peripherals to be attached, configured, used, and separated during operations on the host and other peripherals.

4.1 USB System Description

The USB system is described as three custom domains:
>USB Interconnect
>USB device
>USB Host

  USB InterconnectThe connection and communication between the USB device and the host. Includes the following parts:
>Bus topology: The connection model between the USB device and the host.
>Inner contact: In terms of a capability stack, the USB tasks that are timed med at each layer in the system.
>Data Stream Model: Data in the system is moved between consumers by USB.
>USB Scheduling: USB provides shared internal connections. Access to internal connections is scheduled to support synchronous data transmission and eliminate arbitration overhead.

4.1.1 bus topology

The internal connection of the USB physical layer is hierarchical.Star Topology. USB hub is located in the center of each star. Figure 4-1 illustrates the USB topology.

Restrictions on the allowable time of hub and cable propagation time allow The maximum number of layers is 7 (including the root layer). Due to layer-7 constraints, a communication line between the host and any device supports up to five non-root hubs. The combined device in 4-1 occupies two layers. Therefore, if it is attached to the seventh layer, it cannot be enabled. On the seventh layer, only functions (the Func shown in the figure) can be enabled.



Chapter 2 USB data stream model


5.1 real-life perspective

Figure 5-2 shows a deep USB view. In particular, there are four key implementation areas:
>USB physical device: A small piece of hardware at the end of the USB cable to execute some useful terminal user functions.
>Client Software: The software executed on the host side responds to the USB device. This client software is typically provided by the operating system or with a USB device.
>USB System Software: Software that supports USB in a specific operating system. USB system software is typically provided by the operating system and is independent of a specific USB device or client software.
>USB Host Controller (host-side bus interface): Allows the USB device to be connected to the hardware and software of the host.


As shown in Figure 5-2, simple connection between the host and the device requires interaction between many layers and entities. The USB bus interface layer provides physical/signal/packet connectivity between the host and the device. The USB device layer is the perspective of the USB system software, which is used to perform common USB operations with the device. The feature layer provides additional capabilities to the host through an appropriately matched client software layer. From the perspective of the layer, both the USB device layer and the function layer have a logical communication. In fact, the USB bus interface layer is used for data transmission.


USB communication from the physical perspective is described in sections 6, 7, and 8 and associated with the logical view communication described in sections 9 and 10. This chapter describes the key concepts that affect USB implementers and should be read by everyone.


To describe and manage USB communication, the following concepts are important:
>Bus topology: 5.2 describes the main physical and logical components of USB and how they are related.
>Communication stream model: 5.3 to 5.8 describes how the host communicates with the device through USB, and defines four USB transmission types.
>Bus Access Management: 5.11 describes how bus access in the host is managed to support a wide range of communication flows from USB devices.
>Special considerations for Time Transmission: 5.12 describes the special characteristics of USB for data transmission devices that need to be in other hours. You do not need to read 5.12 for devices that are not transmitting at the same time.

5.2-bus topology


The USB topology consists of four main parts:
>Host and Device: Main components of the USB System
>Physical Topology: How to connect a USB Unit
>Logical topology: The roles and responsibilities of multiple USB units, and how USB is presented from the host and device perspective
>Association between client software and functions: How client software looks at each other with functional interfaces on its related USB devices

5.2.1 USB Host


The USB logic consists of 5-3, including the following parts:
>USB Host Controller
>Integrated USB System Software(USB driver, host controller driver and host software)
>Client


The USB Host occupies a unique position as the USB coordination entity. In addition to its Special Physical Layer location, the host is responsible for USB and its affiliated devices. The host controls all access to USB. Access to the bus can be obtained only when the USB device is permitted by the main statement. The host is also responsible for monitoring the USB topology. For a complete discussion of hosts and their responsibilities, see section 10.

5.2.2 USB device


The logical structure of the USB physical device is 5-4, which includes the following parts:
> USB Bus Interface
>USB Logic Device
>Function


The USB physical device provides additional functions for the host. USB devices provide a wide range of functions. However, all USB logic devices present the same basic interface to the host. This allows the host to manage USB related aspects of different USB devices in the same way.


To help hosts identify and configure USB devices, each device carries and reports configuration information. Part of the reported information is the same for all logical devices. Other information is related to the functions provided by the device. The detailed format of this information is very large, depending on the device type of the device. For a complete discussion of USB devices, see Chapter 9.

5.2.3 physical bus topology


The device on USB is physically connected by a layered star topology, as described in 5-5. USB attaching points are calledHub). The attaching point provided by the hub is calledPort). The hub embedded in the host is called the root hub ). The host provides one or more attaching points through the root hub. The USB device that provides additional functions to the host is calledFunction). To prevent cyclic attachment, the order of layering is applied to the star topology of USB.



5.2.4 logical bus topology


When a device is physically attached to a hierarchical, star-shaped USB, the host communicates with each logical device as if it was directly connected to the root port, as shown in Figure 5-7, corresponds to the physical topology shown in Figure 5-5. The Hub is also a logical device, but the simplified diagram is not shown in Figure 5-7. Although most host/logical device activities use this logical view, the host maintains a physical topology to support processing when the hub is removed. When a hub is removed, all devices attached to the hub must be removed from the logical topology of the host.


5.2.5 association between client software and functions


Although the physical and logical topology of USB reflects the shared nature of the bus, the client software (CSw) interface for operating USB functions is presented as it only processes interfaces that interest it. Figure 5-8 illustrates the relationship between client software and USB functions from the device designer's perspective.



5.3 USB communication flow

USB provides communication services between software on the host and Its USB functions. The function can have different communication flow requirements for different client-to-function interactions. USB provides better overall bus utilization by allowing different communication flows to be separated by USB functions. Each communication flow uses some access bus to complete the communication between the client and the function. Each communication stream is terminated at an endpoint on the device. The device endpoint is used to identify the communication flow.


Figure 5-9 shows a more detailed view in Figure 5-2. Figure 5-2 complete definition of the actual communication flow of the logical device and the functional layer communication flow supported. These actual communication streams span several interface boundaries. The software interfaces of the two hosts are as follows:
>Host Controller Driver (HCD): Software Interface between the USB Host Controller and USB system software. This interface allows the implementation of host controllers within a certain range, without the need for all host software to rely on any specific implementation. A usb driver supports different host controllers without the specific knowledge of host controllers. The host controller is an HCD implementation provided by the implementer to support the host controller.
>USB Driver (USBD): Interface between the USB system software and the client software. This interface provides convenient functions for the client to operate USB devices.


The USB logical device is a collection of endpoints for the USB system. An endpoint is composed of an endpoint set to implement an interface. Interfaces are considered as functions. The USB system software uses the default control pipe to manage devices. The client software uses a pipe bundle (associated with an endpoint set) to operate an interface. The client software requests data to be moved between the cache on the host and the endpoint on the USB device through USB. Host Controller (or USB device, depending on the Transmission Direction) package data to move data through USB.


Figure 5-10 illustrates how the communication stream is transmitted between the endpoint and the host memory buffer through a pipeline.


The software on the host communicates with the logical device through a communication flow set. The set of communication streams is selected by device software/hardware designers to efficiently match the communication requirements of devices.



Linux USB driver Materials

LINUX Device Driver

USB skeleton Program (usb-skeleton) is the basis of USB driver. By learning and understanding its source code, we can quickly understand the USB driver architecture, quickly develop our own USB hardware driver.
Preface
In the previous article "hardware drivers in Linux-USB devices (I) (driver preparation)", we learned how to use some of the most common USB devices in Linux. However, this is far from enough for system design programmers. We also need to have the ability to read, modify, and develop drivers. In the next article, we will use a simple USB driver example to bring you into the world of USB driver development.
USB driver development
After mastering the configuration of the USB device, programmers can try to modify and develop some simple USB drivers. In this section, we will explain two small USB driver examples based on a basic USB frame.
USB skeleton
Driver/usb/usb-skeleton.c in the Linux kernel source code Directory provides us with a basic usb driver. We call it a USB skeleton. With this, we only need to modify a few parts to complete the driver of a USB device. Our USB driver development started from her.
Almost all USB devices not supported in linux are products specific to the manufacturer. If the manufacturer uses their own Protocols in their products, they need to create a specific driver for the device. Of course, we know that some manufacturers disclose their USB protocol and help develop Linux drivers, but some manufacturers do not disclose their USB protocol at all. Because each protocol generates a new driver, a general USB driver skeleton is available, which uses the pci skeleton as the template.
If you want to write a linux driver, first familiarize yourself with the USB protocol specifications. The USB homepage is helpful. Some typical drivers can be found above, and the concept of USB urbs is also introduced, which is the most basic of USB drivers.
The first thing the Linux USB driver needs to do is to register it in the Linux USB subsystem and provide relevant information, such as the device that the driver supports, what actions are taken when a supported device is inserted or pulled out from the system. All this information is transmitted to the USB subsystem, as shown in the following figure in the usb skeleton DRIVER:
Static struct usb_driver skel_driver = {
Name: "skeleton ",
Probe: skel_probe,
Disconnect: skel_disconnect,
Fops: & skel_fops,
Minor: USB_SKEL_MINOR_BASE,
Id_table: skel_table,
};
The variable name is a string that describes the driver. Probe and disconnect are function pointers. When the device matches the variable information in id_table, this function is called.
The fops and minor variables are optional. Most USB Drivers hook another driver system, such as SCSI, network, or tty subsystem. These drivers are registered in other driver systems, and interaction operations in any user space are provided through those interfaces. For example, we use the SCSI device driver as another driver system hooked by our USB driver, then, the read and write operations of the USB device are accessed according to the read and write Functions of the SCSI device. However, no matching driver system can be used for drivers such as scanners. Therefore, we need to process the interaction functions such as read and write with the user space on our own. The Usb sub-system provides a method to register a device number and file_operations function pointer, so that it can be convenient with the user space ...... the remaining full text>

How to Learn about usb development in linux

Are you talking about USB driver development? If yes, we recommend a copy of "Linux device driver development". From the simplest character device to the network device, including USB development, we will introduce in detail. It is worth learning.

Related Article

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.