Comtrol eCos - Manual (Page 717)

Testing
Name
Testing — Testing of USB Device Drivers
Introduction
The support for USB testing provided by the eCos USB common slave package is somewhat different in nature
from the kind of testing used in many other packages. One obvious problem is that USB tests cannot be run on just
a bare target platform: instead the target platform must be connected to a suitable USB host machine, and that host
machine must be running appropriate software for the test code to interact with. This is very different from say a
kernel test which typically will have no external dependencies. Another important difference between USB testing
and say a C library
strcmp test is sensitivity to timing and to hardware boundary conditions: although a simple test
case that just performs a small number of USB transfers is better than no testing at all, it should also be possible to
run tests for hours or days on end, under a variety of loads. In order to provide the required functionality the basic
architecture of the USB testing support is as follows:
1. There is a single target-side program usbtarget. By default when this is run on a target platform it will appear
to do nothing. In fact it is waiting to be contacted by another program usbhost which will tell it what test or
tests to run. usbtarget provides mechanisms for running a wide range of tests.
2. usbtarget is a generic program, but USB testing depends to some extent on the functionality provided by the
hardware. For example there is no point in testing bulk transmits to endpoint 12 if the target hardware does not
support an endpoint 12. Therefore each USB device driver should supply information about what the hardware
is actually capable of, in the form of an array of usbs_testing_endpoint data structures.
3. There is a single host-side program usbhost, which acts as a counterpart to usbtarget. Again usbhost has no
built-in knowledge of the test or tests that are supposed to run, it only provides mechanisms for running a
wide range of tests. On start-up usbhost will search the USB bus for hardware running the target-side program,
specifically a USB device that identifies itself as the product
"Red Hat eCos USB test" .
4. usbhost contains a Tcl interpreter, and will execute any Tcl scripts specified on the command line together
with appropriate arguments. The Tcl interpreter has been extended with various commands such as us-
btest::bulktest , so the script can perform the desired test or tests.
5. Adding a new test simply involves writing a short Tcl script that invokes the appropriate USB-specific com-
mands. Running multiple tests involves passing appropriate arguments to usbhost, or alternatively writing a
single script that just invokes other scripts.
The current implementation of usbhost depends heavily on functionality provided by the Linux kernel and in
particular the usbdevfs support. It uses
/proc/bus/usb/devices to find out what devices are attached to the
bus, and will then access the device by opening /proc/bus/usb/xxx/yyy and performing ioctl operations.
This allows USB testing to take place without having to write a new host-side device driver, but getting the code
working on host machines not running Linux would obviously be problematical.
613