GSoC USB: Not-quite-weekly report #1

The first week passed already, and given the experiences of the last years, the coreboot project decided to request weekly reports from us students, so here is the first report for my USB project.

As presented in my proposal (visible on the GSoC website, but you need to be logged in), I started with OHCI support in libpayload (which I test with FILO).

Before the official start of GSoC I made sure my AMD based board works so I have a working OHCI controller to test on.

While experimenting with the controller, I found that many UHCI data structures in libpayload are public when they could be private (as the OHCI drivers use them internally only). That led to conflicts when defining the OHCI data structures. I made some changes to the USB stack to hide those data structures. It’s an ABI-breaking, API-stable change, so no other code needs to be changed, but when applying the patch, everything must be recompiled – hardly a problem with the typical use cases of libpayload.

Other than that, I spent the time reading the OHCI spec, mapping the register definitions in the spec to data structures, similar to how UHCI is done, and started to write code to detect and initialize OHCI controllers.

I’ll post the changes to USB/UHCI these days, while I’ll wait for the OHCI code until it successfully handled a transfer – doing transfers is my second-next step, after handling the root hub. Each of these steps will give me an indication if initialization is correct.

Right now, it’s just code that compiles, detects the controller version and doesn’t crash while doing something that should resemble initialization. đŸ˜‰