world leader in high performance signal processing
Trace: » zero

Gagdet Zero

Gadget Zero is essential for controller driver testing.

It provides two configurations: one for bulk traffic source/sink, and another for bulk traffic loopback. On the device side it helps verify that the driver stack pass USB-IF and other tests (needed for at least USB branding). On the host side it helps test the USB stack, such as the Linux-USB HCDs and usbcore. If built as a module, start it by modprobe g_zero; no other initialization is needed. (Use the autoresume=N module parameter to make it try triggering remote wakeup N seconds after it's suspended.)

Souce code is drivers/usb/gadget/zero.c

Kernel config of Gagdet Zero

[Linux Kernel Configuration] -→ [Device Drivers] -→ [USB support] -→ [USB Gadget Support]

 <*> Support for USB Gadgets
 <M> USB Gadget Drivers
 <M>   Gadget Zero (DEVELOPMENT)

Testing BF54x USB device/periperal driver with Gadget Zero

Linux USBTEST (Linux 2.6 USB Host)

  • Compile USBTEST module on Linux 2.6 USB host
<M> Support for Host-side USB
[*]   USB device filesystem
<M> USB testing driver (DEVELOPMENT)
  • Install USBTEST module
# modprobe usbtest 
# lsmod | grep usbtest
usbtest                19596  0 
usbcore               138632  7 usbtest,snd_usb_audio,snd_usb_lib,usbhid,ehci_hcd,uhci_hcd
  • get testusb.c and cross compile it for testing
gcc -Wall -g -lpthread -o testusb testusb.c

EZKIT-BF548 USB device side configuration

  • Enable musb mode driver of BF54x
  • Enable Gadget Zero driver and compiling kernel for EZKIT-BF548
  • Install Gadget Zero module
root:~> modprobe g_zero autoresume=5
zero gadget: Gadget Zero, version: St Patrick's Day 2004
zero gadget: using musb_hdrc, OUT ep6out IN ep5in

Test Procedure

  • Connect EZKIT-BF548 with Linux host PC by USB cable and got following message on EZKIT-BF548
root:~> zero gadget: buflen 4096
zero gadget: high speed config #3: source and sink data
  • Get information on the Linux Host PC with USB by using usbtree script
$ mount -t usbfs none /proc/bus/usb
$ ./usbtree 
/: Bus 05.Port 1: Dev 1, Class=root_hub, Drv=ehci_hcd/8p, 480M
    |_ Port 5: Dev 12 Cfg 3/2, If 0, Prod=Gadget Zero, Class=vend., Drv=usbtest, 480M
    |_ Port 8: Dev 3, If 0, Prod=, Class=hub, Drv=hub/4p, 480M
        |_ Port 1: Dev 4, If 0, Prod=USB Optical Mouse, Class=HID, Drv=usbhid, 1.5M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Drv=uhci_hcd/2p, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Drv=uhci_hcd/2p, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Drv=uhci_hcd/2p, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Drv=uhci_hcd/2p, 12M
  • Run “testusb -t9”, for basic operations often used in enumeration.
$ ./testusb -D /proc/bus/usb/005/012 -t9
unknown speed   /proc/bus/usb/005/012
/proc/bus/usb/005/012 test 9,    1.170266 secs
  • Run “testusb -t10”, good at finding problems with fault handling.
$ ./testusb -D /proc/bus/usb/005/012 -t10
unknown speed   /proc/bus/usb/005/012
/proc/bus/usb/005/012 test 10,    1.866462 secs
  • Tests control-OUT transfers, which are essential to support RNDIS network connections to MS-Windows
$ ./testusb -D /proc/bus/usb/005/012 -t14 -c 15000 -s 256 -v 1
unknown speed   /proc/bus/usb/005/012
/proc/bus/usb/005/012 test 14 --> 75 (Value too large for defined data type)
  • Run “testusb -t1”, “testusb -t3”, “testusb -t5”, and “testusb -t7” to test bulk OUT transfers. The scatterlist tests can sustain peak transfer rates for some time, and all the test have modes where they can issue short writes. Use those to cover many different traffic patterns.
$ ./testusb -D /proc/bus/usb/005/012 -t1
unknown speed   /proc/bus/usb/005/012
/proc/bus/usb/005/012 test 1,    0.138782 secs
$ ./testusb -D /proc/bus/usb/005/012 -t3
unknown speed   /proc/bus/usb/005/012
/proc/bus/usb/005/012 test 3,    0.139007 secs
$ ./testusb -D /proc/bus/usb/005/012 -t5
unknown speed   /proc/bus/usb/005/012
/proc/bus/usb/005/012 test 5,    1.302687 secs
$ ./testusb -D /proc/bus/usb/005/012 -t7
unknown speed   /proc/bus/usb/005/012
/proc/bus/usb/005/012 test 7,    1.297654 secs
  • Run “testusb -t2”, “testusb -t4”, “testusb -t6”, and “testusb -t8” to test bulk IN transfers. The scatterlist tests can sustain peak transfer rates for some time.
$ ./testusb -D /proc/bus/usb/005/012 -t2
unknown speed   /proc/bus/usb/005/012
/proc/bus/usb/005/012 test 2,    0.129407 secs
$ ./testusb -D /proc/bus/usb/005/012 -t4
unknown speed   /proc/bus/usb/005/012
/proc/bus/usb/005/012 test 4,    0.136754 secs
$ ./testusb -D /proc/bus/usb/005/012 -t6
unknown speed   /proc/bus/usb/005/012
/proc/bus/usb/005/012 test 6,    0.633172 secs
$ ./testusb -D /proc/bus/usb/005/012 -t8
unknown speed   /proc/bus/usb/005/012
/proc/bus/usb/005/012 test 8,    0.647576 secs
  • All tests should run for at least 24 hours without errors.
  • Repeat the previous tests (except, for now, test 14) using gadgetfs and its usermode test program, to test “deferred response” mode by handling several control transfers in userspace.
  • At least a few times you should disconnect the peripheral from the USB host while each of tests 9, 10, and 14 are running.