GSoC USB: xHCI part 1

I started implementing the xHCI driver. The first obstacle was to overcome a weird lack of configuration of the card (it’s a PCIe device) by coreboot. First I suspected that something went wrong because it uses a 64bit memory BAR, but then it was just a disabled PCIe bus in the devicetree.cb.

Thanks to Stefan for working out that issue.

However, the last days weren’t wasted, as I read the xHCI spec again and again, to build a mental image of how things interact in that standard.

Now I’m chugging along with implementing the data structures in C that xHCI requires (many more than in the older USB HCI specs)

GSoC USB: mid-term report

I stopped doing weekly reports at some point, for a very simple reason: I had few to report, except maybe my frustration that I couldn’t find the bugs in my OHCI driver that prevented some (but not all) devices from working.

So I spent the last weeks tracking down these issues and reading specs and more specs. Both OHCI and xHCI – the latter because it’s part two of my project, and because I was close to giving up OHCI for now and working on xHCI first. It’s an independent task, so that could have been done easily.

Today, I managed to hunt down the bug. It was a simple fix once I found out what’s up. While this uncovered more problems, I can move forward again.

To prevent me from hanging 4 weeks on the next bug, I’ll start on xHCI nonetheless, while doing OHCI on the sideline. Most of OHCI is done, and I guess I can start pushing code upstream soon – just one feature (interrupt transfers, so keyboards work) and a couple of cleanups are missing.

GSoC USB: first successful transfer

Just got this:
FILO version 0.6.0 () Fri Jun 11 13:38:04 GMT 2010
00:03.2 0223:1166.2 EHCI controller
Not supported.
00:03.1 0223:1166.1 OHCI controller
00:03.0 0223:1166.0 OHCI controller
fullspeed device
device 0x3606:0x0151 is USB 2.0 (MSC)
it uses SCSI transparent command set
it uses Bulk-Only Transport protocol
using endpoint 82 as in, 1 as out
has 1 luns
Waiting for device to become ready... ok.
spin up. OK.
Reading capacity of mass storage device.
has 256000 blocks sized 512b
boot:

For this to work, the OHCI root hub must work (to find the USB device), control transfers must work (setup the address, get some general information about it, like “SCSI”, “Bulk-Only”, endpoints, and LUNs), and bulk transfers must work (“256000 blocks of 512b” is got through SCSI/MMC2 commands via bulk)

There’s still quite some work left, as this only works on selected USB devices (more timing resilient than the others?) and errors are neither detected nor handled so far.

Once this is stable and survives all my USB gear, I have to implement interrupt transfers (mostly for keyboards) and my first part of GSoC, OHCI, is done. ­čÖé

USB development for this year’s GSoC

After starting the USB stack in libpayload in the Google Summer of Code of 2007, I’m back this year to implement some more drivers.┬áSo far, we support UHCI Controllers – that is, USB1.x on Via and Intel chipsets.

There are also patches to support OHCI which are under GPL licensing As libpayload ist BSD-licensed, this make it unsuitable for inclusion.┬áSo this year I’ll do a clean implementation of OHCI to get this matter settled.

With this, all USB1.x controllers except for some very rare pre-standard controllers will be supported. This also includes USB2 boards, which means all current mainboards out there, as USB2 simply requires “companion controllers” (which are usually OHCI or UHCI) for USB1 modes.

After this is done, I’ll start on USB3 support. USB3 is still relatively new, but there are two reasons to start working on it:

  1. USB3 will be more popular in the next years, so doing it now ensures that we have one issue less to care about.
  2. Unlike with USB2, xHCI (the host controller standard for USB3) doesn’t use the companion concept, but requires the controller to support USB1 to USB3 itself. This means that old drivers (for UHCI, OHCI or EHCI) won’t find any controller to work with on such boards.

Implementing OHCI and xHCI ensures that all current boards as well as those of the near future will be supportable by libpayload and its users.