> 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!

I somehow just couldn't see Linux-USB taking its next big step
forward in reliability without some automated help like this ... :)


>>   * 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)?

Absolutely.   The most that can be tested with dumb firmware that
sinks/sources packets is software-induced errors, which means just
canceling requests (by unlinking them).  Endpoint halts certainly
deserve specific test cases (and clearing of halts).

It'd be good to have firmware that'd create more than just "typical"
(for who?) failure modes, in fact.  Request error N in 17 packets...


>>   * 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.

Good point.  They're different parts of the USB subsystem than I was
focussing on, but they still need testing!


>>   * 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.

Absolutely..


>>   * Who can help write test firmware?
> 
> 
> I think I could. Something like data source/sink or loopback for EZUSB-FX.

Great!  Right now it's expecting to talk to a data source/sink.  A useful
update would be sourcing patterned data, so dropouts can be noticed.  Could
you help get a GPL'd version of that together?

And loopback is needed too.  I'd like to see a loopback that buffers more
than a single packet, so the read side and write side of "loopback and check
data" style tests would have the opportunity to get out of sync.


> 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.

Hmm, it'd be better to be less specialized.  I have a random set of
EZ-USB devices, but they're all either FX2 or AN2131.  What FX-only
features?  I didn't notice many differences apart from eeprom load,
but then I'd probably have missed them.


>>   * 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.

Well, Greg agreed about the driver, so that leaves a SF.net page.
Something like http://www.linux-usb.org/testing/ is easy enough.
Volunteers appreciated ... :)



>>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

Which one must unfortunately use, since 'sdcc' emits such crappy code
for things like const/static arrays.  (Wastes lots of memory doing a
runtime init, so you have to use assembler for device descriptors as
well as the interrupt vectors.  There's only 8KB, after all!)


> 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.

I thought the version I had generated just 16 bytes?
Maybe I didn't get that far.  Easy to tweak 'fxload'
to handle that, if needed.

- Dave





-------------------------------------------------------
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

Reply via email to