All posts by Patrick Georgi

coreboot report of May 2012

Let's see if I can keep up with this monthly report of what happened in the project.

Changes in the repository

New boards

Gigabyte MA785GM-US2H was already committed, but not hooked up properly.

"blobs" repository

We provide a new repository for binary components and hooked it up in the build. So far it provides binaries for the Intel Sandybridge and Ivybridge platform, as well as the AMD Geode VSA binary that used to be distributed by Marc Jones.

The latter could be replaced by source in the main repository as soon as someone takes the time to port the VSA source (also part of the repository) from MASM assembly to some syntax compatible with our build system.

For VSA, the build system was slightly extended so its cbfs-files mechanism can be used to add coreboot stages.

SeaBIOS mirror

We mirror the SeaBIOS repository on This isn't meant for patch submissions to SeaBIOS, but it provides a more robust source for the repository when using the build method that automatically integrates SeaBIOS in coreboot when behind firewalls.

Sandybridge support

Google provided various commits to improve their initial contributed code for Sandybridge and Ivybridge chipsets and boards.

Simplify using a driver for multiple PCI IDs

Instead of defining a device structure for a larger number of devices (eg. multiple revisions of the same device), extend them so they can optionally cover a set of devices.

static const struct pci_driver pch_sata_ahci_driver __pci_driver = {
   .ops    = &sata_ops,
   .vendor = PCI_VENDOR_ID_INTEL,
   .device = 0x1c02,
static const struct pci_driver pch_sata_mobile_ahci_driver __pci_driver = {
   .ops    = &sata_ops,
   .vendor = PCI_VENDOR_ID_INTEL,
   .device = 0x1c03,


static const struct pci_driver pch_sata_driver __pci_driver = {
    .ops    = &sata_ops,
    .vendor = PCI_VENDOR_ID_INTEL,
    .devices = { 0x1c02, 0x1c03 },

Remove Kconfig options

Stefan dropped CONFIG_MAX_PHYSICAL_CPUS on non-AMD boards. This Kconfig option is only used on AMD boards, but should eventually be removed there, too.

Fixed long time bug in Intel microcode update code

We used to have a couple of issues with cpuid in the past. It's an opcode that modifies a whole lot of registers, and we didn't always teach gcc about all of them.

The latest victim is Intel microcode updates - or rather, one of the earlier ones, since the code was broken since 2004. It only triggered bugs in later code if the compiler tried to reuse values in clobbered registers, and was rather elusive.

roda/rk886ex: Expose VGA devices

This one is interesting as it explains some of the less well documented properties in coreboot, devices in devicetree.cb:

As a rule of thumb, all devices should be listed (and not commented out) that are on-board. While coreboot can find them on its own, it only marks devices as "on mainboard" that are explicitely mentioned - among other things, the VGABIOS execution system uses that to determine the VGABIOS location, but we also run set_subsystem only on onboard hardware.

Console output

There were improvements to console output: The ACPI generation code can print PSS table entries as it generates them. The CBFS code prints more helpful debug output now. * MTRR debug output is more useful now.

Preprocessor mangling

Some preprocessor idioms were unified. CONFIG_FOO==1 became CONFIG_FOO, CONFIG_FOO==0 became !CONFIG_FOO.

We also added the config_enabled macro recently introduced with Linux. It works both for the preprocessor and inside code, and will allow us to eventually reduce the amount of changes we carry around in our version of Kconfig.


Ron committed his research project, a set of Coccinelle scripts to convert Linux KMS code to code that can eventually be run from coreboot, as VGABIOS replacement.

AMD unification

Various aspects of AMD code were unified into generic code: FADT table generation for sb800, cbtypes.h was copied across AMD southbridge drivers,

Add SPI flash driver for Intel chipsets

After AMD added a tiny (and highly specialized) SPI driver for sb800, we now also have support to write to SPI flash on Intel chipsets. Like with AMD, it's used to store configuration data that is required on wakeup-from-S3.

GSoC USB: Conclusion

Now that GSoC is coming to an end, I prepared the patches and pushed the code upstream.

r5691 contains the work done until today, which is what I’ll post as my final result to GSoC, too. Work won’t end on it however, so expect more patches in the future.


OHCI works – except for interrupt transfers, which are mostly used (in boot environments at least) for keyboards.


That one is more complicated than the other controllers combined, and while I made a couple of stupid mistakes that held me up for longer than I wanted, there are aspects in xHCI that make the bootstrap of the driver harder than I’d like it to be.

Once you got the command and event channels set up, it seems that xHCI provides a neat interface for getting all kinds of status information out of it. The only problem is that setting up these channels seems to be more complicated than the entire bring up of UHCI – at least, that’s where I’m stuck right now.

I’ll get back to it, but I hope that a couple of days of doing something else will help me to finally see the problem.


Doing both drivers was ambitious. While I didn’t have the burden of creating the stack design, and learning USB in the first place, like I had in 2007 (when I worked on UHCI for GSoC), it’s still two specifications to understand, two way of communication between the controller and the host system, and finally two drivers to write.

It was fun, but I’ll be more conservative in choosing my project, and estimating the required effort, next time. It’s much easier (and also more satisfying) to add some tasks when the job is done early than to remove them – especially when you get to strip milestones because the hardware is acting up.

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

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.