Infrastructure Projects

From coreboot
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

The wiki is being retired!

Documentation is now handled by the same processes we use for code: Add something to the Documentation/ directory in the coreboot repo, and it will be rendered to Contributions welcome!

This page collects a list of projects to improve the infrastructure of coreboot-v2. Infrastructure means those parts of the code that aren't chipset or mainboard specific, but are used by all of them. The idea is to consolidate a list of things "to do" with their status and responsible developers.

In progress

Low/High Tables

SeaBIOS requires a copy of various BIOS tables outside the fseg as it overwrites that segment. Generally clean out the table generation code.

Status: Upstream, implemented on some boards. There are problems on some chipsets/boards because of incorrect CONFIG_VIDEO_MB handling. The might be other issues, too (not clear, yet).

Vendor/chipset Tested Comments
amd/amdfam10 ?
amd/amdht ?
amd/amdk8 ?
amd/amdmct ?
amd/gx1 ?
amd/gx2 ?
amd/lx ?
ibm/cpc710 ?
ibm/cpc925 ?
intel/e7501 ?
intel/e7520 ?
intel/e7525 ?
intel/i3100 ?
intel/i440bx ?
intel/i82810 ?
intel/i82830 ?
intel/i855gme ?
intel/i855pm ?
intel/i945 ?
motorola/mpc107 ?
via/cn400 ?
via/cn700 Y Tested on VIA pc2500e.
via/cx700 ?
via/vt8601 ?
via/vt8623 ?
via/vx800 ?

Developers: Stefan


A filesystem-alike layout for the coreboot image, to enable systems like bayou and to clean up the system in general (eg. no more buildrom).


Upstream, pre-CBFS infrastructure removed.

There are places where using CBFS might be a good idea: Everything that makes use of external files. The VSA code has its own decompress&copy routine, and links a file directly into the coreboot binary. It shouldn't be much work for someone with a machine to test (Geode LX based) to replace that custom code with a CBFS call.

Some boards have issues with CBFS because it requires the whole ROM to be accessible at a quite early point in time (compared to the old mechanism). The following table contains validated knowledge if the ROM mapping happens at the right time.

Vendor/chipset ROM enabled Status / Comments
amd/amd8111 Y An enable_rom() function is implemented and called failover_process(). Untested on hardware, though.
amd/cs5530 Y Not tested on hardware, yet.
amd/cs5535 ?
amd/cs5536 ?
amd/sb600 ?
broadcom/bcm5785 Y An enable_rom() function is implemented and called failover_process(). Untested on hardware, though.
intel/esb6300 ?
intel/i3100 ?
intel/i82371eb Y Build- and runtime-tested on ASUS P2B by Uwe Hermann
intel/i82801ca ?
intel/i82801dbm ?
intel/i82801er ?
intel/i82801gx ?
intel/i82801xx ?
nvidia/ck804 Y An enable_rom() function is implemented and called failover_process(). Untested on hardware, though.
nvidia/mcp55 Y An enable_rom() function is implemented and called failover_process(). Untested on hardware, though.
sis/sis966 Y An enable_rom() function is implemented and called failover_process(). Untested on hardware, though.
via/vt8231 ?
via/vt8235 ?
via/vt8237r ?
via/vt82c686 ?
winbond/w83c553 ?

Developers: Stefan, Ron, Patrick, Myles, Uwe

Config & Build System

The current system of generated Makefiles is non-ideal (for too many reasons for this little margin). Fix it, somehow. Use KConfig to improve the configuration management.

Status: Upstream, boards are converted. Works side-by-side with the old system. Tinybootblock is in, to help Fam10 boards by moving most of the code out of the top-64kb region. Fam10 boards must still be adapted and fixed, all other boards at least require some testing.

Developers: Stefan, Ron, Patrick, Uwe, Cristi


Unify fallback/normal switch

Right now, the decision whether to use fallback or normal is in cache_as_ram_auto.c in many boards. Make that generic again (also helps with further CBFSification at some point).

Status: Patrick created a bootblock that selects fallback or normal, then runs the romstage of them from CBFS. Even CAR is part of the CBFS file. That naturally leads to unification of fallback/normal, as code in that area moves around a lot. Unreleased prototype so far, boots QEMU, available on request.

Developers: Patrick

More ideas

Unify text printing functions

There are several copies of print_* and printk_* in the code. Unify them so everything is happier than before (because the disjoint features are merged).

Unify ACPI

Every ACPI board has its own routines to compile the ACPI sources. Unify that. Also, figure out generic ACPI code and deduplicate it.

Common payload location

Many boards in v2 have different names for the payload in targets/.../ (payload.elf, filo.elf, etherboot.elf, etc) and locations (../payload.elf, or various absolute paths which only work for one developer). The problem will be fixed with kconfig in v2 where the user specifies a payload manually in "make menuconfig".

CMOS layout

Allow (somehow) to define defaults for all CMOS fields, and create a static table from that. Use that at runtime if the CMOS checksum fails.

Unify UMA / onboard video code and config

Unify CONFIG_VIDEO_MB, CONFIG_GFXUMA, and similar options and make all code honor them.

Add / Unify / Test kconfig compile-time options and runtime CMOS options in coreboot

Some coreboot options are compile-time configurable only at the moment ( or kconfig), but should also be runtime-configurable via CMOS/NVRAM options. We should fix this.

  • Make all options (where it makes sense) run-time configurable via CMOS options, in addition to having sane compile-time defaults configured via kconfig.
  • This includes many options which are northbridge-specific, many southbridge-specific, and some board-specific ones.
  • Example options: Enable/disable IDE channel(s) / SATA / USB / SCSI / etc., enable/disable UDMA on older boards, amount of memory used for IGP/UMA, choice between IDE or NAND flash (on CS5536 boards), IDE 40/80 pin cable selection (VT8237R boards for example), and many more.
  • Some of these options are already handled in the code via CMOS options, some are compile-time only so far, so do not yet exist at all.


Port v3 Resource Allocator

The v3 resource allocator should be ported to v2.

Status: Upstream. It's limited to one area for resources, that doesn't overlap with fixed resources.

Developers: Myles