USB Testing on Linux
http://www.linux-usb.org/usbtest/
Linux-USB Gadget API Framework
2003
http://it.linux-usb.org/gadget/
2005
http://www.linux-usb.org/gadget/
SF.net/Projects/SCM Repositories/linux-usb/htdocs/usbtest
http://linux-usb.cvs.sourceforge.net/linux-usb/htdocs/usbtest/
SF.net/Projects/SCM Repositories/linux-usb/htdocs/gadget
http://linux-usb.cvs.sourceforge.net/viewvc/linux-usb/htdocs/gadget/
linux-2.6.27-rc5
Bulk Test
Download usb.c, usbstring.c, usbstring.h, and build them, put them to usb device side. And run:
modprobe gadgetfs;
mkdir /dev/gadget/ -p;
mount -t gadgetfs none /dev/gadget;
ls -l /dev/gadget/;
usb -v &
ls -l /dev/gadget/;
Current result
# modprobe gadgetfs;
gadgetfs: USB Gadget filesystem, version 24 Aug 2004
# mkdir /dev/gadget/ -p;
# mount -t gadgetfs none /dev/gadget;
# ls -l /dev/gadget/;
-rw------- 1 root root 0 Dec 31 17:00 your_pcd_name
# usb -v &
gadgetfs: bound to your_pcd_name driver
/dev/gadget/your_pcd_name ep0 configured
serial="r8z77oqarmbvnpa6bvgo2xllwuo3iu678yvgy753wdb5ivpxp8rnqv9k0hx3bty"
# ls -l /dev/gadget/;
-rw------- 1 root root 0 Dec 31 17:00 your_pcd_name
-rw------- 1 root root 0 Dec 31 17:00 ep1in
-rw------- 1 root root 0 Dec 31 17:00 ep2out
-rw------- 1 root root 0 Dec 31 17:00 ep3in
-rw------- 1 root root 0 Dec 31 17:00 ep4out
-rw------- 1 root root 0 Dec 31 17:00 ep5in
-rw------- 1 root root 0 Dec 31 17:00 ep6out
-rw------- 1 root root 0 Dec 31 17:00 ep7in
-rw------- 1 root root 0 Dec 31 17:00 ep8out
If you saw the following message
# usb -v
?? don't recognize /dev/gadget bulk device
It means that the PCD is not supported by the user mode driver, add PCD dependent init code at autoconfig() in usb.c. (AIO would need alike code in iso_autoconfig())
Isochronous Test
build libaio and install to target
build usb.c with -DAIO option, and load the executables to target
Run with
usb.aio -v -I0 -a20 -s1020 &
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=77912&start=0
NGW100 with isochronous endpoints
~ # gadgetfs-test -I 1 -s 1024
/dev/gadget/atmel_usba_udc ep0 configured
serial="z0z80c5stcvo90iharg8c0d6ktpto2ru9hjq0gjuy1ki5k5p1mvpp98qkfdko92"
aio_in_thread, io_setup: Success
aio_out_thread, io_setup: Success
Linux Host with testusb results showing the errors
...C...
christos@christos-f2x:~/Desktop/testusb$ sudo ./testusb -a -t15 -c 1000 -s 1024
unknown speed /proc/bus/usb/005/014
/proc/bus/usb/005/014 test 15 --> 33 (Numerical argument out of domain)
...D...
christos@christos-f2x:~/Desktop/testusb$ sudo ./testusb -a -t15 -c 1000 -s 1024
unknown speed /proc/bus/usb/005/014
/proc/bus/usb/005/014 test 16 --> 33 (Numerical argument out of domain)
try CONFIG_USB_DEBUG on host side
[linux-usb-devel] usbtest #10 with gadgetfs hangs
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg49604.html
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg49792.html
By David Brownell,
> I thought this had worked before, but maybe I am getting confused with
> my g_zero testing; I believe it's not expected to work with gadgetfs
> and usb.c, is this right?
Right, that sample program doesn't implement the control requests needed
to support test #14. That combo is not expected to work. (Which is not
to say it couldn't be _made_ to work on some platforms.)
Rewriting the usb.c without aio?
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg49835.html
> > it would just be papering over a bug elsewhere. Since
> > that uses a different mechanism in the kernel, it's very possible that
> > would work while the kill_fasync() mechanism stays broken.
>
> When I looked at that code I wondered why it needed any sort of
> asynchronous notification at all: can't it just do a normal blocking
> read until it gets the next event? Anyway, as you say, changing it
> would be papering over.
I don't recall all the reasoning right now, but one issue was that signal
handling in threaded userspace programs is a PITA one of the good ways to
do it is have a thread sitting in sigwait() to collect all async signals
(i.e. not SIGFPE, SIGBUS etc which are clearly thread-specific). In this
case I simplified things and had that thread be the overall control thread
for the (host-visible) device.
And "usb.c" was originally a test program, designed more for flexibility
than anything else. So having a "main event loop" -- single thread style
application model, not pure userspace MT -- could make it easy to evolve
in that way.
Of course, AIO support kind of blows that model out of the water because
the io_getevents() call doesn't play well with poll(), sigwait(), select(),
or anything else. :(
gadgetfs & 2.6.29: clients always returns EAGAIN
http://mail.spinics.net/lists/linux-usb/msg17438.html
Gadgetfs's use of spinlocks
http://mail.spinics.net/lists/linux-usb/msg16994.html
沒有留言:
張貼留言