usb热插拔使用简介
相关的网页可以通过man hotplug获取
USB
USB hotplugging involves:
- MODULE_DEVICE_TABLE support in the USB Device Driver API, so that a driver's probe() routine is called only when it's very likely to want to bind to a particular interface. USB always uses this.
- Support for invoking the hotplug helper (/sbin/hotplug by default) when devices are added or removed. This functionality is enabled only by CONFIG_HOTPLUG.
- That hotplug helper usually contacts a policy agent which handles the USB-level configuration or activation tasks appropriate to this device and the current system configuration.
- Boot-time configuration ("cold-plugging") can be managed by the /etc/rc.d/init.d/hotplug startup script, if the "usbmodules" command line utility is available. (There is also a "diet hotplug" tool for use during "initrd" processing, which is much less flexible but works without BASH to allow boot images to work over USB devices.)
/usr/src/linux/Documentation/usb/hotplug.txt (this local file if you're reading this on a Linux system, or this one from the lxr.linux.no stable tree) has basic information about USB Device Driver API support for hotplugging. (See a current version if yours doesn't describe the match_flags support added in the final 2.4.0 release.)
modutils knows about the binary MODULE_DEVICE_TABLE format, and needs to be updated if struct usb_device_id ever changes. For hotplugging on 2.6 kernels, you need new module-init-tools anyway, because of the new module loader.
/sbin/hotplug Parameters
Linux 2.2 (and later) kernels invoke the hotplug helper as /sbin/hotplug usb, with environment variables.
There are two kinds of usb hotplug event: device, and interface. Kernel 2.6 added device events, as well as reporting the complete set of interface events. You can tell which kind of event by the environment variables: device events don't include PRODUCT, or any of the other parameters here except DEVPATH and ACTION.
| Variable | Example | Notes |
|---|---|---|
| ACTION | add | a USB device has been added or removed; |
| DEVPATH | only in 2.6 and later kernels; /sys/$DEVPATH is the sysfs directory for this device or interface | |
| PRODUCT | 46d/c281/108 | idVendor/idProduct/bcdDevice, from device descriptor. Numbers are hexadecimal, without leading '0x' or zeros. |
| TYPE | 9/0/0 | bDeviceClass/bDeviceSubClass/bDeviceProtocol, from device descriptor ... when 0/*/* is seen, a variable of type INTERFACE is also provided. Numbers are decimal. |
| INTERFACE | 3/1/1 | bInterfaceClass/bInterfaceSubClass/bInterfaceProtocol, only for device class zero. Linux 2.6 gives each interface its own hotplug event, and /sys/$DEVPATH/bInterfaceNumber tells them apart. Earlier kernels only reported the first interface. Numbers are decimal. |
If "usbfs" (originally called "usbdevfs") is enabled, the following variables are also available:
| Variable | Example | Notes |
|---|---|---|
| DEVFS | /proc/bus/usb | Where the USB "drivers" list lives. (Don't confuse this with the "devfs" filesystem type.) Removed in Linux 2.5 kernels. |
| DEVICE | /proc/bus/usb/002/008 | The path to the usbdevfs node for this device. |
Before the Linux 2.6 kernels, usbmodules was used to scan the other interfaces. In the 2.6 kernels, every interface is reported, so usbmodules doesn't help hotplugging.
Generic /sbin/hotplug USB Policy Agent
A USB policy agent should be installed into /etc/hotplug/usb.agent where it will be invoked by /sbin/hotplug as appropriate. This uses the /lib/modules/.../modules.usbmap file created by "depmod -a" (on 2.4 kernels). It will also search the /etc/hotplug/usb.handmap file for module listings that the kernel doesn't (or can't) know about, typically device-specific bindings, and the /etc/hotplug/usb.usermap file for purely user mode tools (such as user mode drivers to hotsync cameras and PDAS, or firmware downloading).
In addition to the hotplug scripts available at this site, you may want to install the current usbutils; see http://usb.cs.tum.edu/download/usbutils for for the latest version. To get "cold plugging" support (handling devices that are present at boot time before hotplugging works), the "usbmodules" utility (from usbutils) may be important. But can also cause problems with UHCI-based 2.4 systems, so you may want to disable it. You may also want to look at the "diet hotplug" tools (in C) which provide limited device configuration suitable for use with "initrd" setups. (The "diet hotplug" tools don't solve the "coldplug" problem, since they only address module loading and not the rest of the device setup that is often required.)
Device-Specific Setup Programs
Specialized user mode device support can integrate with hotplugging, even if your devices don't need kernel drivers. For example, you may want programs to run immediately to download pictures from a digital camera; you can see one way to do this at this jPhoto page. When your device support involves a kernel driver, instead of a purely user mode driver, name the script after that driver. Similar scripts can trigger when you connect a PDA, printer, or other device. (Some older releases of the hotplug scripts have bugs in this area, so you may need to get an updated release.)
Note that these programs run with the priviliges of a system process. When they need to communicate with unprivileged processes, it is their responsibility to drop excess privileges and otherwise avoid creating security problems. On single-user systems it's typically OK to change the mode of $DEVICE to 0666 (or mount /proc/bus/usb with devmode=0666) to let any user mode driver access the USB device, but that won't always be true.
Downloading Firmware with "fxload"
USB devices based on Cypress EZ-USB (original, FX, or FX2) microcontrollers often need firmware downloads to work. Such downloads are naturally driven by hotplugging, using this project's fxload tool (download release, or use CVS). This handles one or two stage bootstrapping, and is used like this:
- Set up the /etc/hotplug/usb.usermap with the "pre-renumeration" IDs of the device to drive some /etc/hotplug/usb/driver script that uses fxload to download the firmware. See this example usermap file, which maps two different devices (needing different firmware) to the "perf" driver and setup script. Be very careful about the syntax of that file; the parsers used with it expect depmod -a output. If you modify this in an RPM or APT setup step, be sure you don't clobber the file; just append new entries to it, since setup for other devices needs to use this too. (Current versions of hotplug scripts work best if you use /etc/hotplug/usb/driver.usermap files, unique to your driver: you won't need to modify any file.)
- In that setup script, invoke fxload to load your device's firmware from a standard hex file. That script should use
$PRODUCTincasestatements using pre-renumeration device IDs to identify the particular firmware to use for each device and version, and specify the microcontroller type, as shown in this example script. The suggested convention is to keep firmware in a /usr/share/usb/ directory that's clearly associated with the driver. - The last thing fxload does is reboot the device, so it now runs with the new firmware. It will normally enumerate again with new "post-renumeration" product IDs, which should hook up to your driver. (The device script will run, but won't download firmware since that would only be done for pre-renumeration IDs. And the driver will already have been loaded the first time around, since your setup script used the driver name.)
- Make sure your driver exports its supported post-renumeration device IDs with a MODULE_DEVICE_TABLE entry for the USB subsystem, as well as listing that in your
struct usb_driver. Then "depmod -a", after installing the driver module, will automatically update the modules.usbmap file to list your driver, which is where the hotplug tools expect it. (If your driver isn't listed there, it won't hotplug correctly.)
Note that if you need to download firmware into external RAM, a two stage loader is needed. The loader built into the EZ-USB chips only handles loading into on-chip memory (often about 8K, but sometimes just 4K). The 2002_04_11 release of fxload utility supports (and includes) such a loader. For development use, it also supports writing boot EEPROMs for devices that support them.
If you want to develop Free firmware for EZ-USB devices, look at the firmwarehotplug releases in the Linux-Hotplug project (click the link to the left). That includes both 8051 Assembly Language examples, and ones using C. One GPL-friendly firmware development tool is the the SDCC project, which includes a version of a GPL'd 8051 assembler. This Linux-USB web page may have other useful resources.