On Sunday 09 January 2005 12:30 pm, Philipp Schmid wrote:
> I have usb storage devices working so far, but instead of simply trying to
> plug in more and more devices, I would rather use the more systematic
> testing approach presented by the usbtest project
> (http://www.linux-usb.org/usbtest/). So I have a keyspan USA-19 PDA adapter
> that should allow the test firmware to be programmed into and run the tests
> defined in the usbtest module.
>
> Here is where I am at:
>
> o The adapter works in its intended use as a usbserial device on PC
> workstations.
Hey -- for my purposes, the intended use is USB testing! :)
> o On my board (PPC750FX), I can get the keyspan/keyspan_pda drivers to
> successfully upload the driver's firmware, but it seems after the driver
> (i.e. ezusb called from keyspan) issues the CPUCS reset nothing happens. I
> have a usb PTD dump that shows that the reset is being issued to the device,
> but I don't know, if the device ~actually~ resets.
Make sure you're using "good" firmware, there are a couple versions around,
and I think at least one of them has a few issues. But most of it comes
with source code, so that's EZily enough fixed ... ;)
There are two ways the test firmware download works. IN both cases the
chip is held in reset during download, then it starts executing after
the download completes. The two options are: (a) Nothing changes on
USB, it just runs and the host doesn't re-enumerate. Or (b) the chip
drops D+ for long enough to force re-enumeration, normally using very
different product and vendor IDs.
You're using the firmware using option (a), which is the only one where
that confusion happens. Most of the other firmware takes route (b).
> o I have the test kernel module compiled; fxload and the test program are in
> place. Again I can upload the testfw (i.e. ep2_inout.ihx by Martin Diehl -
> I don't know exactly what it does), but I don't see any re-numeration
> happening. So I think I am running into the same problem here as when
> loading the keyspan driver. I have changed the usbtest module to also
> include the device IDs for this device similar to the USA-19Qi, but I am
> thinking it should be using the re-numeration ID's instead.
Yes, ep2_inout.ihx is the very simple firmware that doesn't re-enumerate.
What it does is just sink data sent on ep2out-bulk, and source data
sent on ep2in-bulk. I think it's all zeroes or something similar.
> I'm just a bit unclear on how exactly this test procedure is supposed to
> work. I am unclear whether the usbtest module should use the
> pre-renumeration IDs or the renumeration IDs. I am not too familiar with
> EZUSB, so I am only assuming that once you issue a reset the controller
> should disconnect itself from the port and reconnect itself with the new
> descriptors (correct?). Could it be the HCD simply does not detect a change
> in root hub status (it does however detect (un)plugging)? Is there an easy
> way to force renumeration without powering down the device? Any help or
> pointers would be greatly appreciated (maybe I'm even missing the obvious).
Use different firmware if you want for force re-enumeration ... on the
other hand, you should be able to test just fine using that firmware,
don't feel compelled to switch.
> There is a number of people interested in this isp116x HCD, so I would like
> to help verify it. I won't be able to test it with later kernels, but I
> should be able to help flush out any undetected bugs, if there are any.
>
>
> -------------- info -----------------------
>
> o When loading the HCD and usbtest drivers (after adding device ID to
> id_table):
>
> usb 1-1: new full speed USB device using address 2
> usbtest 1-1:1.0: FX2 device
... it's actually lying here! FX2 has fewer endpoints, even
at full speed. What you show below is the hardware-default
configuration (more or less) of an EZ-USB device ... but it's
using the pre-enumeration device IDs. (Which is part of the
reason that 'testusb' is a bit confused, I guess.)
Yes, that little 8 bit 8051 chip really does have a huge
number of endpoints ... more than most folk can figure out
what to do with.
> usbtest 1-1:1.0: full speed {control bulk-in bulk-out} tests (+alt)
>
> o Device listing (doesn't change with firmware upload, should it change?):
>
> bash-2.05# cat /proc/bus/usb/devices
>
> T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
> B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
> D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
> P: Vendor=0000 ProdID=0000 Rev= 2.06
> S: Manufacturer=Linux 2.6.6 isp116x-hcd
> S: Product=ISP116x Host Controller
> S: SerialNumber=isp1362
> C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
> I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
> E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
>
> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
> D: Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1
> P: Vendor=06cd ProdID=0103 Rev=80.01
> C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
> I: If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbtest
> I: If#= 0 Alt= 1 #EPs=13 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbtest
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=10ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=84(I) 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=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=88(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms
> E: Ad=08(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms
> E: Ad=89(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms
> E: Ad=09(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms
> E: Ad=8a(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms
> E: Ad=0a(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms
> I: If#= 0 Alt= 2 #EPs=13 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbtest
> E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=10ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=84(I) 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=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=88(I) Atr=01(Isoc) MxPS= 256 Ivl=1ms
> E: Ad=08(O) Atr=01(Isoc) MxPS= 256 Ivl=1ms
> E: Ad=89(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms
> E: Ad=09(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms
> E: Ad=8a(I) Atr=01(Isoc) MxPS= 16 Ivl=1ms
> E: Ad=0a(O) Atr=01(Isoc) MxPS= 16 Ivl=1ms
>
> o uploading firmware (uisng fx2, but fx and an21 seem to work as well)
Don't use 'fx2' here, use 'fx' or 'an21'.
The reset commands really _are_ different;
as I recall, they even access different
registers.
> bash-2.05# fxload -v -t fx2 -I testfw.hex -D /proc/bus/usb/001/002
> microcontroller type: fx2
> single stage: load on-chip memory
> open RAM hexfile image testfw.hex
> stop CPU
> write on-chip, addr 0x0000 len 3 (0x0003)
> write on-chip, addr 0x0043 len 3 (0x0003)
> write on-chip, addr 0x0128 len 3 (0x0003)
> write on-chip, addr 0x012c len 3 (0x0003)
> write on-chip, addr 0x0200 len 206 (0x00ce)
> ... WROTE: 218 bytes, 5 segments, avg 43
> reset CPU
>
>
> o Running tests:
>
> # test 0 (seems to complete, but its only a NOP)
As expected. :)
Tests 9 and 10 should probably work here though,
even without loading firmware. Once you can run
test 10 overnight, without seeing any errors,
the HCD will be looking decidedly healthy ... :)
> bash-2.05# ./testusb -D /proc/bus/usb/001/002 -t 0
> ./testusb: /procRunning test #0
> TEST 0: NOP
> /bus/usb/001/002 may see only control tests
> /proc/bus/usb/001/002 test 0, 0.044597 secs
>
> # test 1 (hangs)
>
> bash-2.05# ./testusb -D /proc/bus/usb/001/002 -t 1
> ./testusb: /procRunning test #1
> TEST 1: write 512 bytes 1000 times
> /bus/usb/001/002 may see only control tests
>
> < ... becomes unresponsive ... >
As expected, if you're saying it's an FX2 (it isn't).
Try 'an21' (or 'fx') and it _should_ be much happier.
- Dave
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
