Date: Tue, 10 Feb 2004 11:44:49 -0500 From: Ron Dzierwa <RonDzierwa@comcast.net> To: joe@FreeBSD.org, freebsd-i386@freebsd.org Subject: 5.2 ugen problem Message-ID: <40290A81.E5C4EB26@comcast.net>
next in thread | raw e-mail | index | archive | help
i sent a description of this problem to the i386 mailing list, but haven't got a response yet. I saw the usb keyboard problem and that you were listed as the responsible person, so i thought i could send this description to you in hopes of learning some more about the state of the usb in 5.2. I am developing a kernel driver for the Cypress ezusb-fx2 chip. In order to set up a development environment, i tried to connect the prototype board to the system and use the ugen driver and ezdownload to load a version of test firmware just to see the basics work. I am using an old DFI K6 mobo with a VIA chipset. This whole rig works under 4.9 with no problem, but when i boot into 5.2 and try it i get the following: uhci0: <VIA 83C572 USB controller> port 0xc400-0xc41f irq 10 at device 7.2 on pci0 usb0: <VIA 83C572 USB controller> on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ugen0: Cypress Semiconductor product 0x0081, rev 2.00/0.01, addr 2 ums0: Kensington Kensington USB/PS2 Trackball, rev 1.10/1.00, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. all seems as it should be... I set the usb debug level up and use the ezdownload program to load firmware: bsd5-2# ./usbdebug 9 hw.usb.ugen.debug: 0 -> 9 hw.usb.uhci.debug: 0 -> 9 hw.usb.debug: 0 -> 9 bsd5-2# ezdownload -ev ugen0 Device /dev/ugen0 opened for config Device information: vendor 04b4 (Cypress Semiconductor) product 0081 (product 0x0081) rev 0x0001 addr 2 error 22 setting interface - Invalid argument dmesg has the following: ugenopen: flag=2, mode=8192, unit=0 endpt=0 ugenioctl: cmd=41745570 ugenioctl: cmd=c00c5567 usbd_fill_iface_data: ifaceidx=0 altidx=0 usbd_find_idesc: idx=0(-1) altidx=0(0) len=9 type=2 usbd_find_idesc: idx=0(-1) altidx=0(0) len=9 type=4 usbd_fill_iface_data: found idesc nendpt=0 usbd_alloc_xfer() = 0xc22bc500 usbd_transfer: xfer=0xc22bc500, flags=2, pipe=0xc200d800, running=0 usbd_dump_queue: pipe=0xc200d800 usb_insert_transfer: pipe=0xc200d800 running=0 timeout=5000 uhci_device_control type=0x01, request=0x0b, wValue=0x0000, wIndex=0x0000 len=0, addr=2, endpt=0 usb_event_thread: woke up usb_discover uhci_timeout: uxfer=0xc22bc500 usb_add_task: task=0xc22bc58c usb_task_thread: woke up task=0xc22bc58c uhci_timeout_task: xfer=0xc22bc500 uhci_abort_xfer: xfer=0xc22bc500, status=15 uhci_abort_xfer: stop ii=0xc22bc570 uhci_check_intr: aborted xfer=0xc22bc500 uhci_abort_xfer: callback usb_transfer_complete: pipe=0xc200d800 xfer=0xc22bc500 status=15 actlen=0 usb_transfer_complete: repeat=0 new head=0 uhci_device_ctrl_done: length=0 usbd_start_next: pipe=0xc200d800, xfer=0 usbd_free_xfer: 0xc22bc500 ugenclose: flag=2, mode=8192, unit=0, endpt=0 ugenclose: close control i am not sure that you have to set the interface on the fx2 chip. I have written linux and windoze drivers for the same hardware, and have always been able to use the default interface that is set up when the chip first enumerates. So, I modified ezdownload to allow you to specify a flag that indicates that it should not set the interface, but just get on with the download. When i run it, the application hangs. (not the system, luckily, just the application), and it won't die when kill'ed. Command is: bsd5-2# ezdownload -eva ugen0 Device /dev/ugen0 opened for config Device information: vendor 04b4 (Cypress Semiconductor) product 0081 (product 0x0081) rev 0x0001 addr 2 Fixed Configuration, Interface and Alternative settings to 0,0,0 No /usr/share/usb/firmware/04b4.0081.0001.hex No /usr/share/local/usb/firmware/04b4.0081.0001.hex Read hex file dmesg output is: ugenopen: flag=2, mode=8192, unit=0 endpt=0 ugenioctl: cmd=41745570 ugenioctl: cmd=c018556f usbd_alloc_xfer() = 0xc22bdb00 usbd_transfer: xfer=0xc22bdb00, flags=2, pipe=0xc200d800, running=0 usbd_dump_queue: pipe=0xc200d800 usb_allocmem: use frag=0xc2015ec0 size=1 usb_insert_transfer: pipe=0xc200d800 running=0 timeout=0 uhci_device_control type=0x40, request=0xa0, wValue=0xe600, wIndex=0x0000 len=1, addr=2, endpt=0 uhci_alloc_std_chain: addr=2 endpt=0 len=1 speed=2 flags=0x2 The 5.2 usb system also has problems with device removal and insertion. I can provide dmesg outputs for these problems if desired. If I remove the mouse, the system notices that its gone, then when i plug it back in, the system outputs volumes of dmesg at intervals of several seconds, but it never seems to be able to reconnect the mouse, since the /dev/ums0 device never re-appears. A similar problem happens with the Cypress device. This same system with the same devices works fine under 4.9. Are these problems that are already known about and are being worked on? If not, perhaps i could help in fixing them. I've done kernel and device development on various versions of unix over the last 15 years, so i feel comfortable helping out. I thought it best, though, to see what the state of things were and to see if anybody was already working on these issues before just diving in. any information you can give would be greatly appreciated. thanks, ron.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40290A81.E5C4EB26>