coreboot report of May 2012

Posted on 02.06.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 review.coreboot.org. 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,
};

becomes

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.

i915tool

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.