[SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly

[edward wandasiewicz]

On Sat, Dec 19, 2015 at 2:12 AM, Kevin O'Connor <kevin at koconnor.net> wrote:
> On Sat, Dec 19, 2015 at 01:49:04AM +0000, edward wandasiewicz wrote:
>> Is it a technically a manufacturer messing up the USB spec definitions it
>> should be following?
>
> That's a great question, and I don't know the answer to it.  It would
> be great if there was some guidance in the USB3 spec to help here as
> that would help point out if this is a controller, device, or software
> issue.

I think this is a device issue.

Running OpenBSD on the Pixel 2015, I can confirm the controller is
XHCI - there is no EHCI hardware on the Pixel.

See http://marc.info/?l=openbsd-misc&m=144804232014901&w=2 to verify

The drive specs are USB 3

See http://www.philips.co.uk/c-p/FM64FD145B_10/usb-flash-drive/specifications

We can't rule out the possibility of a manufacturing defect either,
for early release USB devices, with such a long / delayed drive
detection time, versus the rest of the population of devices, which
seem to do so in a more realistic / manageable time delay.

It's good we were able to find out the cause of the problem, and how
to resolve it, but it highlights what manufactures can be up to.

I'd be tempted to not solve the issue, if the behaviour can be
undefined with other people's working hardware.

I could be wrong...

Edward.


>
>> Of all the USB drives I've come across, this Philips one is the only one
>> that behaves like this.
>>
>> It's like its saying "hey, I'm a USB 2.0 spec device, no wait a moment, I'm
>> really a USB 3.0 spec device." and we turn around and say "make ya mind
>> up", by which time it's too late.
>
> We've seen this USB2/3 confusion pop up a few times before - for
> example, see:
>   http://www.seabios.org/pipermail/seabios/2015-November/009907.html
>   http://www.seabios.org/pipermail/seabios/2015-August/009626.html
>   http://www.seabios.org/pipermail/seabios/2014-June/008151.html
>
> This is the first time I've seen a report of a device/controller
> having the confusion long enough for the USB2 instance to survive
> through full drive detection.  (FYI, some of the issues in the emails
> above I think were resolved with other fixes.)
>
>> Sometimes we just can't fix every problem.
>>
>> Granted this one is a tough one to solve.
>
> I don't think it's that difficult to address your particular hardware
> - for example, see the patch below on top of the testing branch.  It's
> unclear to me, however, what implications a change like the one below
> would have on other people's hardware.  :-(
>
> -Kevin
>
>
> --- a/src/hw/usb.c
> +++ b/src/hw/usb.c
> @@ -441,10 +441,14 @@ usb_hub_port_setup(void *data)
>      mutex_unlock(&hub->cntl->resetlock);
>
>      // Make sure device is still present (catches some weird USB3 devices)
> -    ret = hub->op->detect(hub, port);
> -    if (ret <= 0) {
> -        hub->op->disconnect(hub, port);
> -        goto done;
> +    if (hub->cntl->type == USB_TYPE_XHCI && usbdev->speed == USB_HIGHSPEED) {
> +        while (!timer_check(hub->detectend))
> +            yield();
> +        ret = hub->op->detect(hub, port);
> +        if (ret <= 0) {
> +            hub->op->disconnect(hub, port);
> +            goto done;
> +        }
>      }
>
>      // Configure the device