USB problems

[Bernd Walter]

On Wed, Dec 29, 2004 at 08:12:19AM +1100, John Birrell wrote:
> On Tue, Dec 28, 2004 at 09:28:33PM +0100, Bernd Walter wrote:
> > Well, getting a stall on control endpoint is an error, but getting an
> > error on string descriptors shouldn't stop further processing.
> 
> Windows obviously begs to differ. This reference design comes from the
> Singapore lab of Philips which I believe also contains the engineers
> who contributed to the USB specification.

I develop hardware with Philips components myself, so I know what you
are talking about.
The hardware is good, but docs and samples are a mess and full of bugs.

> The firmware code looks like it was written by an inexperienced hardware
> engineer. It is only provided as an example by Philips. They intend you
> to write your own when you build your own board. I will do that when I
> get the ability to burn 8051 code. In the meantime, I want FreeBSD's
> USB implementation to function as well as Windows. That means coming
> up with an implementation that tolerates the control endpoint being
> stalled.

I prefered not to use Philips code as a starting point for my own
hardware.

> > > The string descriptors are returned normally by the device, except for the
> > > fact that it sets the stall bit on the control endpoint.
> > 
> > Here is the device broken, unless FreeBSD's request is not correct.
> 
> Windows can talk to it though, so at least it's possible to get around
> aspects of the device which, I agree, are probably broken.

The point is that we use common generic code, while windows does not.

> The thing that nags me, though, is that this is a 'reference design' and
> that means that any company choosing to build an MPEG2 encoder based
> on Philips' SAA7114, SAA6752 and ISP1581 is going to start with this
> firmware code and build a product that probably has the same behaviour.
> Philips only offer support to companies who are planning to by large
> numbers of chips. That means I'm on my own here. I can't communicate
> with their engineers in Singapore. I've tried - they won't respond.

I understand this problem - I've seen lots of broken firmware in code
and it's always a surprise that it runs anywhere.

> > The device shouldn't stall on requesting partial descriptors.
> > IIRC FreeBSD changed the way how descriptors are fetched normaly in
> > that it doesn't trust the size fields anymore and asks for more data
> > than required.
> 
> It also shouldn't stall getting the configuration. Or getting status.
> But it is coded to do that.

Ack.

> > > The FreeBSD code *never* takes into account that the control endpoint
> > > stall will be cleared with the next setup packet.
> > 
> > Maybe the host controller needs any kind of unstall mimic, but not the
> > device.
> > The question is more what happens with further requests after that
> > error.
> 
> Further requests start with a setup packet, so the stall is cleared when
> that is received. The problem is that FreeBSD gives up on talking to the
> device because it treats the stall condition as an error. It isn't
> even possible for FreeBSD to get past the device initialisation because
> the first 8 bytes of the device descriptor are returned with the stall
> bit set. At that point, FreeBSD barfs.

In the windows world this generic handling is part of the driver code
so firmware developers don't even have to think about building compliant
devices as long as their driver does the right thing.
On the other hand windows is much blown with spread generic code and
since each driver does a full port reset it also takes very long for
a device to come up.

What we really need is some kind of sanity check for stalled answers.
One might think that a stall on requesting the device descriptor can't
be true, but in this case it's a high speed device why simply just
isn't prepared to be asked for 8 bytes.
The brokeness in the device is very likely that it expects beeing asked
for exactly the length the firmware developer had in mind to get asked
for.
Many firmware developers forget that fact that an USB device is just a
slave and has to do whatever the host wants.
They don't think a device as beeing an event handler.

> > You just don't know if the received data is correct when receiving
> > a stall - especially for requests without data.
> > This is something to hand up to the driver which might have a clue
> > about a specific device brokenness.
> 
> A problem with FreeBSD's code is that some of the places where the driver
> *could* interpret the stall condition differently and actually handled
> in common routines that are hard-coded to treat the stall as an error.

Agreed, but it's hard to do this in a generic way - a stall is still
an error.

> Take the configuration descriptor as an example. The FreeBSD code tries
> to get the first 9 bytes to discover the wTotalLength, then it goes and
> gets the full descriptor (including interfaces and endpoints). In the
> case of this rogue device, the get of the first 9 bytes results in a
> stall. FreeBSD's code then fails the entire configuration descriptor
> get and it isn't possible for a driver to configure the device.

I don't know the situation at other places, but in this case we can
savely request the full descriptor length for high speed devices.
High speed devices are required to have large control pipe sizes.
It's very likely that the device behaves differently when running
full speed - also asking for partial descriptors is perfectly legal
under every condition.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd at bwct.de                                  info at bwct.de