Replace <code>get_option(VALstart, VALlen, default)</code> with a macro that hides start/len in something like <code>get_option(VAL, default)</code>

Replace <code>get_option(VALstart, VALlen, default)</code> with a macro that hides start/len in something like <code>get_option(VAL, default)</code>

+

+

=== CMOS defaults ===

+

CMOS defaults are kept in src/mainboard/*/*/cmos.default and stored in CBFS. Provide an alternative implementation of get_option and/or cmos_read (likely the latter) that is used for !USE_OPTION_TABLE, and provides cmos.default data (or 0 for everything if absent). Check that the default values for failing get_option() calls that are scattered across the tree remain the same, then drop them.

+

+

=== CMOS defaults at build time ===

+

Create a #define file (similar to config.h or build.h) and allow to resolve get_option at build time in the !USE_OPTION_TABLE case (will require some advanced macro magic)

That way, we can have global fields (RTC, century byte), per chipset component fields (defined by northbrigde/southbridge/superio), per mainboard fields at their appropriate places.

That way, we can have global fields (RTC, century byte), per chipset component fields (defined by northbrigde/southbridge/superio), per mainboard fields at their appropriate places.

−

−

=== CMOS defaults ===

−

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.

−

In the above format, it could simply be a suffix <code>default=VALUE</code>

−

Also drop the "default" argument in get_options. As components have their own cmos.layout snippets, we can always take those definitions' defaults, even if mainboards don't make use of CMOS themselves.

=== Value overrides ===

=== Value overrides ===

Line 162:

Line 163:

=== Provide update paths and avoid conflicts in addressing ===

=== Provide update paths and avoid conflicts in addressing ===

−

Research topic: How could updates to nvram configuration (eg. new fields) be handled safely, and how could we get away from carving out the CMOS memory space manually? (one proposal: http://article.gmane.org/gmane.linux.bios/64572)

+

One way to go at this: Add smarts to flashrom: When running from coreboot, it has current cmos.layout and the table, as well as the new cmos.layout (and the new defaults). Take new defaults, fill up with current settings, and write the result to CMOS. This provides automatic values for new configuration options.

−

+

−

Simple solution: Add smarts to flashrom: When running from coreboot, it has current cmos.layout and the table, as well as the new cmos.layout (and the new defaults). Take new defaults, fill up with current settings, and write the result to CMOS. This provides automatic values for new configuration options.

+

=== Checksums ===

=== Checksums ===

+

The CMOS checksum situation is still muddied. coreboot master now uses the PCBIOS encoding scheme, which has one advantage (compatibility with Linux's /dev/nvram driver) and two disadvantages:

+

# a pruned CMOS is a valid configuration

+

# a vendor BIOS CMOS configuration is considered valid even though it's all crap from a coreboot perspective.

−

The Linux kernel driver expects a non-inverted CMOS checksum for the "PC" area. coreboot inverts this checksum, which makes nvram unusable for the driver. This should be fixed.

+

If we continue to care about /dev/nvram, the location of the checksum is for all intents and purposes fixed (to what vendor BIOSes do), so we could as well drop it from our configuration and hardcode it.

−

+

== Global variables ==

== Global variables ==

Line 179:

Line 180:

= More ideas =

= More ideas =

+

+

== Unify IT8718F and IT8728F / Refactor IT8718F ==

+

+

The IT8718F and IT8728F superios are nearly identical. It is unclear if they can use the same code, however, IT8718F requires #include "...ealry_serial.c" in romstage whereas IT8728F does not. IT8728F code also provides better abstraction. If they cannot be merged, at least refactor IT8718F code to more closely match the IT8728F code.

== Unify UMA / onboard video code and config ==

== Unify UMA / onboard video code and config ==

Line 271:

Line 276:

== Add a config for selecting a SeaBIOS git revision ==

== Add a config for selecting a SeaBIOS git revision ==

+

Currently there is only the choice between coreboot master and the lastest stable revision.

Currently there is only the choice between coreboot master and the lastest stable revision.

= Finished =

= Finished =

−

== Port v3 Resource Allocator ==

+

Finished projects are on a [[Infrastructure Projects/Done|separate page]] now

−

+

−

The v3 resource allocator should be ported to v4.

+

−

+

−

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

+

−

+

−

'''Developers:''' Myles

+

−

+

−

== 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. Old system is gone. All boards build. HOWEVER, not all boards have been boot-tested yet, please report any issues you encounter!

+

−

+

−

'''Developers:''' Stefan, Ron, Patrick, Uwe, Cristi

+

−

+

−

== 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).

+

−

+

−

'''Status:''' Finished.

+

−

+

−

'''Developers:''' Patrick, Stefan

+

−

+

−

== Common payload location ==

+

−

+

−

Many boards have different names for the payload in targets/.../Config.lb (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, where the user specifies a payload manually in "make menuconfig".

+

−

+

−

'''Status:''' Finished.

+

−

+

−

== Fix ALL build warnings ==

+

−

+

−

* Someone has to do the deed.

+

−

+

−

'''Status:''' Finished, the build usually issues no warnings. If you see warnings/errors, please report a bug.

+

−

+

−

== Post codes ==

+

−

+

−

Find all outb(x, 0x80) and replace them with post_code(). Use common numbers / defines across the boards.

+

−

+

−

'''Status:''' Finished, except for some local delay routines in early smbus code.

+

−

+

−

== Use central oprom init ==

+

−

+

−

* Get rid of all vgabios.c, make all chipsets with own vgabios.c use devices/oprom/x86.c.

There are several defines in several places that describe the local APIC address:

+

−

+

−

* LAPIC_ADDR

+

−

* LOCAL_APIC_ADDR (even twice)

+

−

* LAPIC_DEFAULT_BASE

+

−

+

−

This should be unified.

+

−

+

−

'''Developers:''' Patrick

+

−

+

−

== printk into buffer ==

+

−

+

−

Port the v3 feature that printk can write into a buffer (that might be usable from the client OS, or dumped to output, as soon as output exists).

+

−

+

−

Consider use cases first (no need to provide buffer support, if all it would be useful for is buffering pre-CAR messages - which can't be buffered).

+

−

+

−

'''Developers:''' ChromiumOS Team

+

−

+

−

== USB Debug Console ==

+

−

+

−

Fix USB debug console and make the Kconfig choice actually work. Right now it's possible to transmit single characters but it's not really hooked up.

+

−

+

−

'''Developers:''' SvenS

+

−

+

−

== CBFS ==

+

−

+

−

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).

+

−

+

−

'''Status:'''

+

−

+

−

Upstream, pre-CBFS infrastructure removed.

+

−

+

−

There are places where using CBFS might be a good idea: Everything that makes use of external files, for example the VSA code in the Geode chipset code. VSA is converted, and tested on a couple of configurations, but untested on others.

+

−

+

−

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.

+

−

+

−

All boards that manage to boot in a tinybootblock configuration are capable at least for the used ROM size (it might be that larger ROMs would fail because they require mapping the larger space)

+

−

+

−

{| border="0" style="font-size: smaller"

+

−

|- bgcolor="#6699ff"

+

−

! align="left" | Vendor/chipset

+

−

! align="left" | ROM enabled

+

−

! align="left" | Tiny bootblock

+

−

! align="left" | Status / Comments

+

−

+

−

|- bgcolor="#eeeeee"

+

−

| amd/amd8111

+

−

| style="background:yellow" | Y

+

−

| style="background:yellow" | Y

+

−

| Not tested on hardware, yet.

+

−

|- bgcolor="#eeeeee"

+

−

| amd/cs5530

+

−

| style="background:lime" | Y

+

−

| style="background:red" | N

+

−

| Not tested on hardware, yet.

+

−

|- bgcolor="#eeeeee"

+

−

| amd/cs5535

+

−

| style="background:red" | N

+

−

| style="background:red" | N

+

−

| &mdash;

+

−

|- bgcolor="#eeeeee"

+

−

| amd/cs5536

+

−

| style="background:red" | N

+

−

| style="background:red" | N

+

−

| &mdash;

+

−

|- bgcolor="#eeeeee"

+

−

| amd/sb600

+

−

| style="background:lime" | Y

+

−

| style="background:lime" | Y

+

−

| Build- and runtime-tested on siemens/sitemp_g1p1 by [[User:PatrickGeorgi|PatrickGeorgi]].

+

−

|- bgcolor="#eeeeee"

+

−

| amd/sb700

+

−

| style="background:yellow" | Y

+

−

| style="background:yellow" | Y

+

−

| &mdash;

+

−

+

−

|- bgcolor="#dddddd"

+

−

| broadcom/bcm5785

+

−

| style="background:yellow" | Y

+

−

| style="background:yellow" | Y

+

−

| Not tested on hardware, yet.

+

−

+

−

|- bgcolor="#eeeeee"

+

−

| intel/esb6300

+

−

| style="background:red" | N

+

−

| style="background:red" | N

+

−

| &mdash;

+

−

|- bgcolor="#eeeeee"

+

−

| intel/i3100

+

−

| style="background:red" | N

+

−

| style="background:red" | N

+

−

| &mdash;

+

−

|- bgcolor="#eeeeee"

+

−

| intel/i82371eb

+

−

| style="background:lime" | Y

+

−

| style="background:yellow" | Y

+

−

| Build- and runtime-tested on ASUS P2B by [[User:Uwe|Uwe Hermann]].

+

−

|- bgcolor="#eeeeee"

+

−

| intel/i82801ax

+

−

| style="background:red" | N

+

−

| style="background:red" | N

+

−

| &mdash;

+

−

|- bgcolor="#eeeeee"

+

−

| intel/i82801bx

+

−

| style="background:red" | N

+

−

| style="background:red" | N

+

−

| &mdash;

+

−

|- bgcolor="#eeeeee"

+

−

| intel/i82801cx

+

−

| style="background:red" | N

+

−

| style="background:red" | N

+

−

| &mdash;

+

−

|- bgcolor="#eeeeee"

+

−

| intel/i82801dx

+

−

| style="background:red" | N

+

−

| style="background:red" | N

+

−

| &mdash;

+

−

|- bgcolor="#eeeeee"

+

−

| intel/i82801ex

+

−

| style="background:red" | N

+

−

| style="background:red" | N

+

−

| &mdash;

+

−

|- bgcolor="#eeeeee"

+

−

| intel/i82801gx

+

−

| style="background:lime" | Y

+

−

| style="background:lime" | Y

+

−

| Build- and runtime-tested on Kontron 986LCD-m by PatrickGeorgi

+

−

+

−

|- bgcolor="#dddddd"

+

−

| nvidia/ck804

+

−

| style="background:yellow" | Y

+

−

| style="background:yellow" | Y

+

−

| Not tested on hardware, yet.

+

−

|- bgcolor="#dddddd"

+

−

| nvidia/mcp55

+

−

| style="background:yellow" | Y

+

−

| style="background:yellow" | Y

+

−

| Not tested on hardware, yet.

+

−

+

−

|- bgcolor="#dddddd"

+

−

| sis/sis966

+

−

| style="background:yellow" | Y

+

−

| style="background:yellow" | Y

+

−

| Not tested on hardware, yet.

+

−

+

−

|- bgcolor="#eeeeee"

+

−

| via/vt8231

+

−

| style="background:yellow" | Y

+

−

| style="background:red" | N

+

−

| &mdash;

+

−

|- bgcolor="#eeeeee"

+

−

| via/vt8235

+

−

| style="background:red" | N

+

−

| style="background:red" | N

+

−

| &mdash;

+

−

|- bgcolor="#eeeeee"

+

−

| via/vt8237r

+

−

| style="background:yellow" | Y

+

−

| style="background:yellow" | Y

+

−

| &mdash;

+

−

|- bgcolor="#eeeeee"

+

−

| via/vt82c686

+

−

| style="background:red" | N

+

−

| style="background:red" | N

+

−

| &mdash;

+

−

+

−

|}

+

−

+

−

'''Developers:''' Stefan, Ron, Patrick, Myles, Uwe

+

−

+

−

== Tiny Bootblock ==

+

−

+

−

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:''' Available in Kconfig, works on a couple of boards. Requires per southbridge changes (and northbridge in some cases) on many boards (related to ROM enable, see CBFS section).

+

−

+

−

'''Developers:''' Patrick

+

Latest revision as of 07:41, 16 February 2015

This page collects a list of projects to improve the infrastructure of coreboot v4. 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

?

—

intel/e7501

?

—

intel/e7520

?

—

intel/e7525

?

—

intel/i3100

?

—

intel/i440bx

?

—

intel/i82810

?

—

intel/i82830

?

—

intel/i855

?

—

intel/i945

Y

Tested on Kontron 986LCD-M and Roda RK886EX

via/cn400

?

—

via/cn700

Y

Tested on VIA pc2500e.

via/cx700

?

—

via/vt8601

?

—

via/vt8623

?

—

via/vx800

?

—

Developers: Stefan

Remove .c includes

Currently we include lots of code in the romstage using the preprocessor. This makes it harder to support new boards (where chipset components are supported already) and maintenance in general. So we should get rid of it where possible, using the linker for CAR boards and the build system for the remaining non-CAR boards appropriately.

Status: CAR boards only for now, to keep the project manageable. i945 is modified already, and boards based on it have only one or two remaining source files they include. Interacts with the next project "Move configuration to Kconfig", which ensures that code still sees all configuration when it is compiled separately.

Developers: Patrick, Uwe

Move configuration to Kconfig

Many boards have lots of #define VAR somevalue statements in their romstage.c which define how certain component drivers are compiled. With Kconfig, there's a better place to store them. This project is about moving all configuration values out of romstage.c (and other places if appropriate) and into Kconfig. util/lint/lint-001-no-global-config-in-romstage helps figuring out what remains to be done.

Status: Intel and VIA based boards should be mostly configuration free, AMD boards still have defines in their romstage. AMD/AGESA Boards have platform_cfg.h for which a solution should be found.

Unify ACPI

Every ACPI board has its own routines to compile the ACPI sources. Unify that.

CMOS handling

The subprojects are ordered in a way that minimizes lost work.

Done: Simplify get_option

Replace get_option(VALstart, VALlen, default) with a macro that hides start/len in something like get_option(VAL, default)

CMOS defaults

CMOS defaults are kept in src/mainboard/*/*/cmos.default and stored in CBFS. Provide an alternative implementation of get_option and/or cmos_read (likely the latter) that is used for !USE_OPTION_TABLE, and provides cmos.default data (or 0 for everything if absent). Check that the default values for failing get_option() calls that are scattered across the tree remain the same, then drop them.

CMOS defaults at build time

Create a #define file (similar to config.h or build.h) and allow to resolve get_option at build time in the !USE_OPTION_TABLE case (will require some advanced macro magic)

Implement a new cmos.layout format

The current layout is simple to parse, but not so simple to maintain or extend.
Create a format that combines the various fields into a single representation, eg.

Implement an include statement

That way, we can have global fields (RTC, century byte), per chipset component fields (defined by northbrigde/southbridge/superio), per mainboard fields at their appropriate places.

Value overrides

A chipset might provide options (eg. SATA/IDE) that a board might override (eg. because it doesn't provide IDE even if the chipset would support it). Allow the mainboard to override config options. This wouldn't just set a new default, but drop the option from CMOS entirely, hardcoding the value in the build. Some autogenerated #ifdef/#define magic might help there.

Provide update paths and avoid conflicts in addressing

One way to go at this: Add smarts to flashrom: When running from coreboot, it has current cmos.layout and the table, as well as the new cmos.layout (and the new defaults). Take new defaults, fill up with current settings, and write the result to CMOS. This provides automatic values for new configuration options.

Checksums

The CMOS checksum situation is still muddied. coreboot master now uses the PCBIOS encoding scheme, which has one advantage (compatibility with Linux's /dev/nvram driver) and two disadvantages:

a pruned CMOS is a valid configuration

a vendor BIOS CMOS configuration is considered valid even though it's all crap from a coreboot perspective.

If we continue to care about /dev/nvram, the location of the checksum is for all intents and purposes fixed (to what vendor BIOSes do), so we could as well drop it from our configuration and hardcode it.

Global variables

Make use of global variables where appropriate.

Done:

Provide v3 style global variables framework

More ideas

Unify IT8718F and IT8728F / Refactor IT8718F

The IT8718F and IT8728F superios are nearly identical. It is unclear if they can use the same code, however, IT8718F requires #include "...ealry_serial.c" in romstage whereas IT8728F does not. IT8728F code also provides better abstraction. If they cannot be merged, at least refactor IT8718F code to more closely match the IT8728F code.

Unify UMA / onboard video code and config

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

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.

Kconfig TODO

Notes / Style guide:

Any bool variables that are (re-)defined to 'y' in Kconfig files can be simplified by using select FOO instead of the usual paragraph, as long as they're defined globally as default n boolean elsewhere.

Use bool instead of boolean.

Use default n instead of default false.

Various post-conversion things to consider:

Consider ways to move crt0-y and ldscript-y out of $(src)/arch/i386/Makefile.inc where appropriate (ie. component specific)

Make various CONFIG_* variable which were in each board's Kconfig file global or per-chipset options (instead of per-board). Examples:

Deduplicate the lowlevel functions - they should really be the same (except for some style differences)

Deduplicate the non-multiplexing highlevel functions. Mark them weak, so multiplexing boards can simply provide their own variant, which override the weak functions automatically

Move all registers/chip definitions in XML format for all tools

For easy creating definitions of new chips, or editing old register definitions, improve readability support, and add support for humanless parsing the logs we decide move all data for msrtool, inteltool, superiotool, etc in XML-based format. See here: XML

Device dependency engine

We have a couple of places where we want to disable (or otherwise reconfigure) a device if another one is active: SATA and IDE covering the same ports, integrated graphics / plugin video cards, ...
Right now, such things are done "somewhere", usually far away from any meaningful context. This idea isn't as actionable as the others as it's still missing even a sketch of a design.

Find a good place (or multiple places) where such device decisions can be made