📄 usbs-testing.html
字号:
<!-- Copyright (C) 2003 Red Hat, Inc. -->
<!-- This material may be distributed only subject to the terms -->
<!-- and conditions set forth in the Open Publication License, v1.0 -->
<!-- or later (the latest version is presently available at -->
<!-- http://www.opencontent.org/openpub/). -->
<!-- Distribution of the work or derivative of the work in any -->
<!-- standard (paper) book form is prohibited unless prior -->
<!-- permission is obtained from the copyright holder. -->
<HTML
><HEAD
><TITLE
>Testing</TITLE
><meta name="MSSmartTagsPreventParsing" content="TRUE">
<META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="eCos Reference Manual"
HREF="ecos-ref.html"><LINK
REL="UP"
TITLE="eCos USB Slave Support"
HREF="io-usb-slave.html"><LINK
REL="PREVIOUS"
TITLE="Writing a USB Device Driver"
HREF="usbs-writing.html"><LINK
REL="NEXT"
TITLE="eCos Support for Developing USB-ethernet Peripherals"
HREF="io-usb-slave-eth.html"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>eCos Reference Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="usbs-writing.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="io-usb-slave-eth.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><H1
><A
NAME="USBS-TESTING">Testing</H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN16868"
></A
><H2
>Name</H2
>Testing -- Testing of USB Device Drivers</DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN16871"
></A
><H2
>Introduction</H2
><P
>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
<TT
CLASS="FUNCTION"
>strcmp</TT
> 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: </P
><P
></P
><OL
TYPE="1"
><LI
><P
> There is a single target-side program
<SPAN
CLASS="APPLICATION"
>usbtarget</SPAN
>. 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
<SPAN
CLASS="APPLICATION"
>usbhost</SPAN
> which will tell it what test or
tests to run. <SPAN
CLASS="APPLICATION"
>usbtarget</SPAN
> provides
mechanisms for running a wide range of tests.
</P
></LI
><LI
><P
> <SPAN
CLASS="APPLICATION"
>usbtarget</SPAN
> 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
<SPAN
CLASS="STRUCTNAME"
>usbs_testing_endpoint</SPAN
> data structures.
</P
></LI
><LI
><P
> There is a single host-side program
<SPAN
CLASS="APPLICATION"
>usbhost</SPAN
>, which acts as a counterpart to
<SPAN
CLASS="APPLICATION"
>usbtarget</SPAN
>. Again
<SPAN
CLASS="APPLICATION"
>usbhost</SPAN
> 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
<SPAN
CLASS="APPLICATION"
>usbhost</SPAN
> will search the USB bus for
hardware running the target-side program, specifically a USB device
that identifies itself as the product <TT
CLASS="LITERAL"
>"Red Hat eCos
USB test"</TT
>.
</P
></LI
><LI
><P
> <SPAN
CLASS="APPLICATION"
>usbhost</SPAN
> 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
<TT
CLASS="LITERAL"
>usbtest::bulktest</TT
>, so the script can perform
the desired test or tests.
</P
></LI
><LI
><P
> Adding a new test simply involves writing a short Tcl script that
invokes the appropriate USB-specific commands. Running multiple
tests involves passing appropriate arguments to
<SPAN
CLASS="APPLICATION"
>usbhost</SPAN
>, or alternatively writing a
single script that just invokes other scripts.
</P
></LI
></OL
><P
>The current implementation of <SPAN
CLASS="APPLICATION"
>usbhost</SPAN
>
depends heavily on functionality provided by the Linux kernel and in
particular the usbdevfs support. It uses
<TT
CLASS="FILENAME"
>/proc/bus/usb/devices</TT
> to find out what devices
are attached to the bus, and will then access the device by opening
<TT
CLASS="FILENAME"
>/proc/bus/usb/xxx/yyy</TT
> and performing
<TT
CLASS="FUNCTION"
>ioctl</TT
> 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.</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN16904"
></A
><H2
>Building and Running the Target-side Code</H2
><P
>The target-side component of the USB testing software consists of a
single program <SPAN
CLASS="APPLICATION"
>usbtarget</SPAN
> which contains
support for a range of different tests, under the control of host-side
software. This program is not built by default alongside other eCos
test cases since it will only operate in certain environments,
specifically when the target board's connector is plugged into a Linux
host, and when the appropriate host-side software has been installed
on that host. Instead the user must enable a configuration option
<TT
CLASS="LITERAL"
>CYGBLD_IO_USB_SLAVE_USBTEST</TT
> to add the program to
the list of tests for the current configuration.</P
><P
>Starting the <SPAN
CLASS="APPLICATION"
>usbtarget</SPAN
> program does not
require anything unusual, so it can be run in a normal
<SPAN
CLASS="APPLICATION"
>gdb</SPAN
> session just like any eCos application.
After initialization the program will wait for activity from the host.
Depending on the hardware, the Linux host will detect that a new USB
peripheral is present on the bus either when the
<SPAN
CLASS="APPLICATION"
>usbtarget</SPAN
> initialization is complete or
when the cable between target and host is connected. The host will
perform the normal USB enumeration sequence and discover that the
peripheral does not match any known vendor or product id and that
there is no device driver for <TT
CLASS="LITERAL"
>"Red Hat eCos USB
test"</TT
>, so it will ignore the peripheral. When the
<SPAN
CLASS="APPLICATION"
>usbhost</SPAN
> program is run on the host it will
connect to the target-side software, and testing can now commence.</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN16915"
></A
><H2
>Building and Running the Host-side Code</H2
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>In theory the host-side software should be built when the package is
installed in the component repository, and removed when a package
is uninstalled. The current eCos administration tool does not provide
this functionality.</P
></BLOCKQUOTE
></DIV
><P
>The host-side software should be built via the usual sequence of
"configure/make/make install". It can only be built on a
Linux host and the <B
CLASS="COMMAND"
>configure</B
> script contains an
explicit test for this. Because the eCos component repository should
generally be treated as a read-only resource the configure script will
also prevent you from trying to build inside the source tree. Instead
a separate build tree is required. Hence a typical sequence for
building the host-side software would be as follows:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>$ mkdir usbhost_build
$ cd usbhost_build
$ <repo>packages/io/usb/slave/current/host/configure <A
NAME="PATH"
><IMG
SRC="../images/callouts/1.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(1)"></A
> <A
NAME="VERSION"
><IMG
SRC="../images/callouts/2.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(2)"></A
> <args> <A
NAME="ARGS"
><IMG
SRC="../images/callouts/3.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(3)"></A
>
$ make
<output from make>
$ su <A
NAME="ROOT"
><IMG
SRC="../images/callouts/4.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(4)"></A
>
$ make install
<output from make install>
$</PRE
></TD
></TR
></TABLE
><DIV
CLASS="CALLOUTLIST"
><DL
COMPACT="COMPACT"
><DT
><A
HREF="usbs-testing.html#PATH"
><IMG
SRC="../images/callouts/1.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(1)"></A
></DT
><DD
>The location of the eCos component repository should be substituted
for <TT
CLASS="LITERAL"
><repo></TT
>.</DD
><DT
><A
HREF="usbs-testing.html#VERSION"
><IMG
SRC="../images/callouts/2.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(2)"></A
></DT
><DD
>If the package has been obtained via CVS or anonymous CVS then the
package version will be <TT
CLASS="FILENAME"
>current</TT
>, as per the
example. If instead the package has been obtained as part of a full
eCos release or as a separate <TT
CLASS="FILENAME"
>.epk</TT
> file then the
appropriate package version should be used instead of
<TT
CLASS="FILENAME"
>current</TT
>.</DD
><DT
><A
HREF="usbs-testing.html#ARGS"
><IMG
SRC="../images/callouts/3.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(3)"></A
></DT
><DD
>The <B
CLASS="COMMAND"
>configure</B
> script takes the usual arguments such
as <TT
CLASS="PARAMETER"
><I
>--prefix=</I
></TT
> to specify where the executables
and support files should be installed. The only other parameter that
some users may wish to specify is the location of a suitable Tcl
installation. By default <SPAN
CLASS="APPLICATION"
>usbhost</SPAN
> will use
the existing Tcl installation in <TT
CLASS="FILENAME"
>/usr</TT
>,
as provided by your Linux distribution. An alternative Tcl
installation can be specified using the parameter
<TT
CLASS="PARAMETER"
><I
>--with-tcl=</I
></TT
>, or alternatively using some
combination of <TT
CLASS="PARAMETER"
><I
>--with-tcl-include</I
></TT
>,
<TT
CLASS="PARAMETER"
><I
>--with-tcl-lib</I
></TT
> and
<TT
CLASS="PARAMETER"
><I
>--with-tcl-version</I
></TT
>. </DD
><DT
><A
HREF="usbs-testing.html#ROOT"
><IMG
SRC="../images/callouts/4.gif"
HSPACE="0"
VSPACE="0"
BORDER="0"
ALT="(4)"></A
></DT
><DD
>One of the host-side executables that gets built,
<SPAN
CLASS="APPLICATION"
>usbchmod</SPAN
>, needs to be installed with suid
root privileges. Although the Linux kernel makes it possible for
applications to perform low-level USB operations such as transmitting
bulk packets, by default access to this functionality is restricted to
programs with superuser privileges. It is undesirable to run a complex
program such as <SPAN
CLASS="APPLICATION"
>usbhost</SPAN
> with such
privileges, especially since the program contains a general-purpose
Tcl interpreter. Therefore when <SPAN
CLASS="APPLICATION"
>usbhost</SPAN
>
starts up and discovers that it does not have sufficient access to the
appropriate entries in <TT
CLASS="FILENAME"
>/proc/bus/usb</TT
>,
it spawns an instance of <SPAN
CLASS="APPLICATION"
>usbchmod</SPAN
> to modify
the permissions on these entries. <SPAN
CLASS="APPLICATION"
>usbchmod</SPAN
>
will only do this for a USB device <TT
CLASS="LITERAL"
>"Red Hat eCos USB
test"</TT
>, so installing this program suid root should not
introduce any security problems.</DD
></DL
></DIV
><P
>During <B
CLASS="COMMAND"
>make install</B
> the following actions will take
place: </P
><P
></P
><OL
TYPE="1"
><LI
><P
><SPAN
CLASS="APPLICATION"
>usbhost</SPAN
> will be installed in <TT
CLASS="FILENAME"
>/usr/local/bin</TT
>,
or some other <TT
CLASS="FILENAME"
>bin</TT
> directory if
the default location is changed at configure-time using a
<TT
CLASS="PARAMETER"
><I
>--prefix=</I
></TT
> or similar option. It will be
installed as the executable
<SPAN
CLASS="APPLICATION"
>usbhost_<version></SPAN
>, for example
<SPAN
CLASS="APPLICATION"
>usbhost_current</SPAN
>, thus allowing several
releases of the USB slave package to co-exist. For convenience a
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -