On Mon, 30 Sep 2002, David Brownell wrote:
> Here's an initial whack at a Linux-USB test framework. I've found
> it useful so far; it's turned up real bugs we'll want to fix. It's
> worth a look from you if you're concerned with robustness, stability,
> or correctness of the USB core/hcd code. Or just wanted some more
> involved USB sanity checks, to give questionable hardware a once-over.
>
> It supports a hands-off automated test mode, and I imagine it gaining
> more tests (easy to add them!) and helping regression-test new kernels.
> It also spits out some performance numbers that could sometimes help,
> like most tools that act as traffic generators.
I didn't had time yet to look into details but this sounds like a very
important improvement for linux-usb - Thanks for bringing this up!
>
> The framework has three parts:
>
> * Test Devices (Firmware). A lot of widely available products can
> be used by downloading EZ-USB test firmware.
> (not provided here)
>
> * Kernel driver(s). I keep thinking this would best be put in
> the standard distribution, so it stays up to date and serves as
> a more executable version of the Linux-USB API spec.
> ATTACHED as 'usbtest-930.patch'
>
> * Test harness. User mode programs to talk to the kernel driver,
> running tests, making whatever reports are needed.
> ATTACHED as 'testusb.c'
>
> Unlike the old 'usbstress', this uses usbfs only to locate devices (and
> that could be changed); it's not using it to do I/O. It's testing with
> normal driver APIs, with URBs and so on.
>
> More information is at the end of this note, including sample test runs
> and test output. (For slightly older versions of what I've attached.)
>
> Some questions I have:
>
> * Do you also think we should have a test framework?
Absolutely. Having the framework for regression testing is a big win IMHO.
>
> * What else should it do, if you want one?
What about triggering the error paths, i.e. some firmware which produces
typical device failure modes (like responding too slowly or issues with
descriptor passing)?
>
> * Does anyone know of another one of these (not 'usbstress-0.3')?
> I'm under the impression most testing is whether a particular
> driver behaves, which can leave huge gaps in test coverage.
>
> * Is this the right way to factor such a framework?
The firmware/driver/userland-testsuite approach sounds good to me.
Probably there is some need for including hotplug and/or usbfs features,
particularly when targeting connect/disconnect issues.
>
> * Who will help write test cases?
Well, my hope is this would evolve with time. IMHO this is where most
effort and contribution is needed. Once we have the framework running,
I believe people could (and hopefully will) start making testcases for
example when fixing issues with their stuff.
>
> * Who can help write test firmware?
I think I could. Something like data source/sink or loopback for EZUSB-FX.
Note I have such stuff partly ready here for my testing - need some
cleanup and checks, but I believe I could provide this rather soon. It
makes use of special FX-features so it won't run neither on FX2 nor old
EZUSB (AN2131) devices.
>
> * Where should the different harness components live?
>
> I think one plausible scheme would put the kernel driver into the 2.5
> tree, and the other stuff in some linux-usb page at SourceForge along
> with documentation ("how to set it up and use it") and so on.
Second this.
>
> - Dave
>
>
> DEVICE FIRMWARE
>
> The test driver currently needs device firmware that just sinks or sources
> data ... the stuff of basic chip SDK examples.
>
> Right now I'm using a tweaked version of some firmware that's available with
> the Cypress FX2 SDK, since it works at either full or high speed. This is
> what its descriptors look like at full speed; for high speed the maximum
> packet sizes are of course 512 bytes (except for ep0, which is still 64).
>
> T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> P: Vendor=0547 ProdID=1002 Rev= 0.00
> S: Manufacturer=Cypress
> S: Product=Bulk Source: EZ-USB FX2
> C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
> I: If#= 0 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbtest
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=88(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
>
> It's likely that GPL'd test firmware will appear at some point. It should
> be easy to make use SA-1100 based PDAs to do this, for example. And even
> with all its quirks, I'm sure SDCC is up to the job of supporting that much
> for FX or FX2 devices; anyone with an FX-based serial adapter can run such
I've never tried sdcc - but I do use the generic asxxxx (i.e. as8051) for
most FX firmware work. sdcc comes with a modified version of asxxxx so it
should just work as well. Note the linker creates intel hex format with 32
bytes per record. So whatever you use for firmware download, it should be
prepared to deal with this.
Martin
-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server
today at http://www.ServePath.com/indexfm.htm
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
