📄 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"><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+"><LINKREL="HOME"TITLE="eCos Reference Manual"HREF="ecos-ref.html"><LINKREL="UP"TITLE="eCos USB Slave Support"HREF="io-usb-slave.html"><LINKREL="PREVIOUS"TITLE="Writing a USB Device Driver"HREF="usbs-writing.html"><LINKREL="NEXT"TITLE="eCos Support for Developing USB-ethernet Peripherals"HREF="io-usb-slave-eth.html"></HEAD><BODYCLASS="REFENTRY"BGCOLOR="#FFFFFF"TEXT="#000000"LINK="#0000FF"VLINK="#840084"ALINK="#0000FF"><DIVCLASS="NAVHEADER"><TABLESUMMARY="Header navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">eCos Reference Manual</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="usbs-writing.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom"></TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="io-usb-slave-eth.html"ACCESSKEY="N">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><H1><ANAME="USBS-TESTING">Testing</H1><DIVCLASS="REFNAMEDIV"><ANAME="AEN16868"></A><H2>Name</H2>Testing -- Testing of USB Device Drivers</DIV><DIVCLASS="REFSECT1"><ANAME="AEN16871"></A><H2>Introduction</H2><P>The support for USB testing provided by the eCos USB common slavepackage is somewhat different in nature from the kind of testing usedin many other packages. One obvious problem is that USB tests cannotbe run on just a bare target platform: instead the target platformmust be connected to a suitable USB host machine, and that hostmachine must be running appropriate software for the test code tointeract with. This is very different from say a kernel test whichtypically will have no external dependencies. Another importantdifference between USB testing and say a C library<TTCLASS="FUNCTION">strcmp</TT> test is sensitivity to timing and tohardware boundary conditions: although a simple test case that justperforms a small number of USB transfers is better than no testing atall, it should also be possible to run tests for hours or days on end,under a variety of loads. In order to provide the requiredfunctionality the basic architecture of the USB testing support is asfollows: </P><P></P><OLTYPE="1"><LI><P> There is a single target-side program <SPANCLASS="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 <SPANCLASS="APPLICATION">usbhost</SPAN> which will tell it what test or tests to run. <SPANCLASS="APPLICATION">usbtarget</SPAN> provides mechanisms for running a wide range of tests. </P></LI><LI><P> <SPANCLASS="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 <SPANCLASS="STRUCTNAME">usbs_testing_endpoint</SPAN> data structures. </P></LI><LI><P> There is a single host-side program <SPANCLASS="APPLICATION">usbhost</SPAN>, which acts as a counterpart to <SPANCLASS="APPLICATION">usbtarget</SPAN>. Again <SPANCLASS="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 <SPANCLASS="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 <TTCLASS="LITERAL">"Red Hat eCos USB test"</TT>. </P></LI><LI><P> <SPANCLASS="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 <TTCLASS="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 <SPANCLASS="APPLICATION">usbhost</SPAN>, or alternatively writing a single script that just invokes other scripts. </P></LI></OL><P>The current implementation of <SPANCLASS="APPLICATION">usbhost</SPAN>depends heavily on functionality provided by the Linux kernel and inparticular the usbdevfs support. It uses<TTCLASS="FILENAME">/proc/bus/usb/devices</TT> to find out what devicesare attached to the bus, and will then access the device by opening<TTCLASS="FILENAME">/proc/bus/usb/xxx/yyy</TT> and performing<TTCLASS="FUNCTION">ioctl</TT> operations. This allows USB testing to takeplace without having to write a new host-side device driver, butgetting the code working on host machines not running Linux wouldobviously be problematical.</P></DIV><DIVCLASS="REFSECT1"><ANAME="AEN16904"></A><H2>Building and Running the Target-side Code</H2><P>The target-side component of the USB testing software consists of asingle program <SPANCLASS="APPLICATION">usbtarget</SPAN> which containssupport for a range of different tests, under the control of host-sidesoftware. This program is not built by default alongside other eCostest cases since it will only operate in certain environments,specifically when the target board's connector is plugged into a Linuxhost, and when the appropriate host-side software has been installedon that host. Instead the user must enable a configuration option<TTCLASS="LITERAL">CYGBLD_IO_USB_SLAVE_USBTEST</TT> to add the program tothe list of tests for the current configuration.</P><P>Starting the <SPANCLASS="APPLICATION">usbtarget</SPAN> program does notrequire anything unusual, so it can be run in a normal<SPANCLASS="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 USBperipheral is present on the bus either when the<SPANCLASS="APPLICATION">usbtarget</SPAN> initialization is complete orwhen the cable between target and host is connected. The host willperform the normal USB enumeration sequence and discover that theperipheral does not match any known vendor or product id and thatthere is no device driver for <TTCLASS="LITERAL">"Red Hat eCos USBtest"</TT>, so it will ignore the peripheral. When the<SPANCLASS="APPLICATION">usbhost</SPAN> program is run on the host it willconnect to the target-side software, and testing can now commence.</P></DIV><DIVCLASS="REFSECT1"><ANAME="AEN16915"></A><H2>Building and Running the Host-side Code</H2><DIVCLASS="NOTE"><BLOCKQUOTECLASS="NOTE"><P><B>Note: </B>In theory the host-side software should be built when the package isinstalled in the component repository, and removed when a packageis uninstalled. The current eCos administration tool does not providethis 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 aLinux host and the <BCLASS="COMMAND">configure</B> script contains anexplicit test for this. Because the eCos component repository shouldgenerally be treated as a read-only resource the configure script willalso prevent you from trying to build inside the source tree. Insteada separate build tree is required. Hence a typical sequence forbuilding the host-side software would be as follows:</P><TABLEBORDER="5"BGCOLOR="#E0E0F0"WIDTH="70%"><TR><TD><PRECLASS="SCREEN">$ mkdir usbhost_build$ cd usbhost_build$ <repo>packages/io/usb/slave/current/host/configure <ANAME="PATH"><IMGSRC="../images/callouts/1.gif"HSPACE="0"VSPACE="0"BORDER="0"ALT="(1)"></A> <ANAME="VERSION"><IMGSRC="../images/callouts/2.gif"HSPACE="0"VSPACE="0"BORDER="0"ALT="(2)"></A> <args> <ANAME="ARGS"><IMGSRC="../images/callouts/3.gif"HSPACE="0"VSPACE="0"BORDER="0"ALT="(3)"></A>$ make<output from make>$ su <ANAME="ROOT"><IMGSRC="../images/callouts/4.gif"HSPACE="0"VSPACE="0"BORDER="0"ALT="(4)"></A>$ make install<output from make install>$</PRE></TD></TR></TABLE><DIVCLASS="CALLOUTLIST"><DLCOMPACT="COMPACT"><DT><AHREF="usbs-testing.html#PATH"><IMGSRC="../images/callouts/1.gif"HSPACE="0"VSPACE="0"BORDER="0"ALT="(1)"></A></DT><DD>The location of the eCos component repository should be substitutedfor <TTCLASS="LITERAL"><repo></TT>.</DD><DT><AHREF="usbs-testing.html#VERSION"><IMGSRC="../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 thepackage version will be <TTCLASS="FILENAME">current</TT>, as per theexample. If instead the package has been obtained as part of a fulleCos release or as a separate <TTCLASS="FILENAME">.epk</TT> file then theappropriate package version should be used instead of<TTCLASS="FILENAME">current</TT>.</DD><DT><AHREF="usbs-testing.html#ARGS"><IMGSRC="../images/callouts/3.gif"HSPACE="0"VSPACE="0"BORDER="0"ALT="(3)"></A></DT><DD>The <BCLASS="COMMAND">configure</B> script takes the usual arguments suchas <TTCLASS="PARAMETER"><I>--prefix=</I></TT> to specify where the executablesand support files should be installed. The only other parameter thatsome users may wish to specify is the location of a suitable Tclinstallation. By default <SPANCLASS="APPLICATION">usbhost</SPAN> will usethe existing Tcl installation in <TTCLASS="FILENAME">/usr</TT>,as provided by your Linux distribution. An alternative Tclinstallation can be specified using the parameter<TTCLASS="PARAMETER"><I>--with-tcl=</I></TT>, or alternatively using somecombination of <TTCLASS="PARAMETER"><I>--with-tcl-include</I></TT>,<TTCLASS="PARAMETER"><I>--with-tcl-lib</I></TT> and<TTCLASS="PARAMETER"><I>--with-tcl-version</I></TT>. </DD><DT><AHREF="usbs-testing.html#ROOT"><IMGSRC="../images/callouts/4.gif"HSPACE="0"VSPACE="0"BORDER="0"ALT="(4)"></A></DT><DD>One of the host-side executables that gets built,<SPANCLASS="APPLICATION">usbchmod</SPAN>, needs to be installed with suidroot privileges. Although the Linux kernel makes it possible forapplications to perform low-level USB operations such as transmittingbulk packets, by default access to this functionality is restricted toprograms with superuser privileges. It is undesirable to run a complexprogram such as <SPANCLASS="APPLICATION">usbhost</SPAN> with suchprivileges, especially since the program contains a general-purposeTcl interpreter. Therefore when <SPANCLASS="APPLICATION">usbhost</SPAN>starts up and discovers that it does not have sufficient access to theappropriate entries in <TTCLASS="FILENAME">/proc/bus/usb</TT>, it spawns an instance of <SPANCLASS="APPLICATION">usbchmod</SPAN> to modifythe permissions on these entries. <SPANCLASS="APPLICATION">usbchmod</SPAN>will only do this for a USB device <TTCLASS="LITERAL">"Red Hat eCos USBtest"</TT>, so installing this program suid root should notintroduce any security problems.</DD></DL></DIV><P>During <BCLASS="COMMAND">make install</B> the following actions will takeplace: </P><P></P><OLTYPE="1"><LI><P><SPANCLASS="APPLICATION">usbhost</SPAN> will be installed in <TTCLASS="FILENAME">/usr/local/bin</TT>,or some other <TTCLASS="FILENAME">bin</TT> directory ifthe default location is changed at configure-time using a<TTCLASS="PARAMETER"><I>--prefix=</I></TT> or similar option. It will beinstalled as the executable<SPANCLASS="APPLICATION">usbhost_<version></SPAN>, for example<SPANCLASS="APPLICATION">usbhost_current</SPAN>, thus allowing severalreleases of the USB slave package to co-exist. For convenience a⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -