[haiku-bugs] Re: [Haiku] #11619: No USB on Poulsbo hardware

  • From: "edglex" <trac@xxxxxxxxxxxx>
  • Date: Fri, 05 Jun 2015 09:10:26 -0000

#11619: No USB on Poulsbo hardware
--------------------------------+----------------------------
Reporter: edglex | Owner: mmlr
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: Drivers/USB/EHCI | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 1 | Platform: x86
--------------------------------+----------------------------

Comment (by edglex):

Replying to [comment:18 mmlr]:

Replying to [comment:13 edglex]:
I've been poking at this for a while today. With the supplied patch,
we're in an infinite loop. Apparently this happens with some hardware, it
is reported as a bug in illumos (https://www.illumos.org/issues/4225) and
Linux actually only ever loops 64 times here before giving up. I've
checked and booting Linux I get an error that BIOS handoff failed, but USB
still works in Linux.

In PCI getting a value of 255 generally means an error or not present
device. So an extended capability pointer of 255 likely hints at a failure
to actually read the corresponding register, not that the capability
pointer actually has a value of 255.

This makes sense.


Also since the device doesn't advertise the PCIe capability it should be
treated like a normal PCI device (which is usual for EHCI devices). In
that case the config space is only 256 bytes to begin with, making an
offset of 255 bytes not useful.

Does this mean that the config read/write checks ((size == 4 && (offset &
3) != 0)) are ok? It's odd because linux gives an offset of 0x33 for the
legacy support register, which would also fail this check.


The bug report you linked describes exactly the same issue.

I noticed that Linux also attempts to disable interrupts and take
control regardless of whether this worked, so I attempted to do the same
thing (as well as looping 64 times before giving up), but although this
allows me to boot, I get reports that at least one of the writes failed,
and I still don't have working USB.

That's what the Haiku implementation does as well. It does only do so if
it finds the corresponding legacy support register, because it can't unset
the semaphore if there isn't one.


The patch above that loops over all the legacy support registers wasn't
doing this, so I added it.


Generally not using the hand off mechanism is unproblematic as long as
the firmware does not have any SMIs (System Management Interrupts) enabled
on the device. Since the SMI enabled registers are also within the legacy
support registers, the same as above applies.

A failing reset would further point towards not actually getting
sensible values from/to the registers at all, as a reset should always
work (even if legacy support was enabled).

Yes, I'm pretty well certain that these values are wrong.


To debug this, please enable full tracing in ehci.cpp and also output
and post the value of the full EHCI_HCCPARAMS register:

{{{
TRACE_ALWAYS("host controller parameters: %#" B_PRIx32 "\n",
ReadCapReg32(EHCI_HCCPARAMS));
}}}

If reading the register fails as suspected it should output 0xffffffff.

I already did that, and am fairly sure that I did indeed get 0xffffffff.


I also tried through a hub, to rule out it being the same problem as
9118.

#9118 is not related to this. It is the opposite case where the UHCI
root port doesn't work whereas the EHCI one does (and using a 2.0 hub
causes the root port to be driven by EHCI).

What I don't understand is why it is failing to read/write the PCI
config register, this seems to be crucial. Any idea? I'm having trouble
following the rest of the linux spaghetti code, so can't figure out what
they do next.

The BSDs usually have code that is much easier to follow if you want to
compare other implementations.

Yes I have also been looking at the freebsd code, it is much more similar
to the haiku code (and I see at least the structure of some of the haiku
code is based on netbsd). It is hard to know how useful it is though,
because I don't know if USB is working under freebsd on this hardware.
Perhaps I should boot a live freebsd version and find out.

Thanks for your help!

--
Ticket URL: <https://dev.haiku-os.org/ticket/11619#comment:19>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: