Date: Sat, 26 Apr 2008 10:25:28 +0800 From: "Xiaofan Chen" <xiaofanc@gmail.com> To: "Hans Petter Selasky" <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: PICDEM FS USB Bootloader under FreeBSD Message-ID: <a276da400804251925j9b0cc50mb3729d2297783f22@mail.gmail.com> In-Reply-To: <200804252354.05828.hselasky@c2i.net> References: <a276da400710120806k636347eew876ee0fb3fc17ab3@mail.gmail.com> <a276da400710160634g3d88b527j550c41223278c9e5@mail.gmail.com> <a276da400804241956r3a7759bp298c76ccdaf8eb76@mail.gmail.com> <200804252354.05828.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 26, 2008 at 5:54 AM, Hans Petter Selasky <hselasky@c2i.net> wrote: > On Friday 25 April 2008, Xiaofan Chen wrote: > > This does not work either with 7.0-Release and the HPS USB stack. > > I will update to the latest SVN version of the HPS stack and see if the > > situation will improve. The bootlaoder does work under Linux (as well as > > Windows) fine with libusb (libusb-win32). > I think it is a fault of your USB device. But at the same time I think that we > can do a better job working around faulty USB devices. The most likely cause > of the problem is that your USB device does not requeue data on what in your > case is endpoint 1 when it receives the clear-stall for endpoint 1. That is > what I suspect. Where was the firmware for your device again? This is from the popular PICDEM FS USB demo board firmware from Microchip. It is very popular among hobbyists as well as many customers because of low cost, free C18 C compiler (no code size limit, but only optimization limit), free samples, DIP package USB chips, lots of examples and good support from Microchip. Microchip USB info: http://www.microchip.com/usb Others and I have identified various firmware bugs in the free USB stack Microchip offers. They have also corrected quite some of them. Reference: http://forum.microchip.com/tm.aspx?m=275422 I will see if the latest V2.1 stack has fixed this issue. I think it has not. I think you have pinpointed the potential bugs in the stall handling code. The question is then why you want to clear stall in the first transfer. > <sidetrack> > When an USB device is broken or it has no driver: > > First you e-mail the manufacturer and complain. > Then you e-mail usb.org and complain. > Then you call your government and complain. > > Anything I forgot ? > If one has the access to the firmware, try to fix it. ;-) In this case, since I have access to the firmware codes and I am quite familiar with it, I will try to fix the firmware. I can totally understand your point as a USB developer for alternative OS like Linux and FreeBSD. Still you can see a lot of Linux USB efforts are to support quirky USB device. It is not that fun, but it is quite important if you care the user experience. A good example from Linux USB; http://kerneltrap.org/mailarchive/linux-kernel/2007/9/13/259148 "It turns out that USB devices suck when it comes to power management issues :(". So maybe it is also true that USB devices suck when it comes to handling clear stall feature request. Xiaofan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a276da400804251925j9b0cc50mb3729d2297783f22>