Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Apr 2008 23:54:04 +0200
From:      Hans Petter Selasky <hselasky@c2i.net>
To:        "Xiaofan Chen" <xiaofanc@gmail.com>
Cc:        freebsd-usb@freebsd.org
Subject:   Re: PICDEM FS USB Bootloader under FreeBSD
Message-ID:  <200804252354.05828.hselasky@c2i.net>
In-Reply-To: <a276da400804241956r3a7759bp298c76ccdaf8eb76@mail.gmail.com>
References:  <a276da400710120806k636347eew876ee0fb3fc17ab3@mail.gmail.com> <a276da400710160634g3d88b527j550c41223278c9e5@mail.gmail.com> <a276da400804241956r3a7759bp298c76ccdaf8eb76@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 25 April 2008, Xiaofan Chen wrote:
> On Tue, Oct 16, 2007 at 9:34 PM, Xiaofan Chen <xiaofanc@gmail.com> wrote:
> > On 10/13/07, Xiaofan Chen <xiaofanc@gmail.com> wrote:
> >  > On 10/13/07, Hans Petter Selasky <hselasky@c2i.net> 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).

Hi,

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?

--HPS

<sidetrack>

I recently came across a good example of a broken USB device. They actually 
had it wired on the mainboard of an Acer Laptop this time. With my new USB 
stack I thought I should do some smart things like caching the Language ID 
string on all USB devices, so that you can pick a language before the string 
retrieval functions are called. But oh no. Being clever does not pay off in 
this world. Instead of returning a STALL to indicate that the control request 
was not supported the device promptly crashed, and the computer locked up 
badly. It wasn't a problem in my USB stack it was the mainboard crashing. Of 
course it works on Windows, because the Windows USB stack will never do these 
kind of smart things. Anyway, I found a generic workaround and that is to 
disable all strings if there are no strings in the USB device descriptor. You 
might not think that this a problem, but read-only functions can very easily 
be available to non-privileged users, possibly posing a DOS risk in a 
multi-user environment.

The truth is that many USB devices are only tested on MS Windows before being 
sold. The bugs that do not show up on MS Windows are assumed to not exist, 
which is not true. When an USB device does not work on FreeBSD it does not 
necessarily mean that there is something wrong with FreeBSD. It can quite 
aswell be the opposite.

I have very often been confronted with big numbers: "We sell x million USB 
units per year. If you think there is something wrong with our product there 
is something wrong with you." blah blah. There is something to the saying 
that when many people are using a product you will know if there is something 
wrong at some point. But, it is the one that finds the problem that is the 
problem. It is the one that arrests the thief that gets the trouble. It is 
ironic and it is a result of the knowledgeless mass.

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 ?

:-)

</sidetrack>

--HPS



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200804252354.05828.hselasky>