Infrastructure Projects: Difference between revisions

From coreboot
Jump to navigation Jump to search
(move enable_rom table to cbfs in Infrastructure_Projects)
m (More usable TOC, small updates.)
Line 1: Line 1:
This page collects a list of projects to improve the infrastructure of coreboot-v2.
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.
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 =


= In progress =
== Low/High Tables ==
== 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.
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. Problems on others.
'''Status:''' Upstream, implemented on some boards. Problems on others.
=== Developers ===
 
Stefan
'''Developers:''' Stefan


== CBFS ==
== 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 ===
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.
Upstream, pre-CBFS infrastructure removed.


Some boards have issues with CBFS because it requires the whole ROM to be present 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.
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.


{| border="0" style="font-size: smaller"
{| border="0" style="font-size: smaller"
Line 122: Line 124:
|}
|}


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


== Build System ==
== Build System ==
The current system of generated Makefiles is non-ideal (for too many reasons for this little margin). Fix it, somehow
 
=== Status ===
The current system of generated Makefiles is non-ideal (for too many reasons for this little margin). Fix it, somehow.
Upstream, boards are converted. Works side-by-side with the old system.
 
=== Developers ===
'''Status:''' Upstream, boards are converted. Works side-by-side with the old system.
Stefan, Ron, Patrick, Uwe, Cristi
 
'''Developers:''' Stefan, Ron, Patrick, Uwe, Cristi


== Config System ==
== Config System ==
Use KConfig to improve the situation.
Use KConfig to improve the situation.
=== Status ===
 
Upstream, boards are converted. Works side-by-side with the old system.
'''Status:''' Upstream, boards are converted. Works side-by-side with the old system.
=== Developers ===
 
Stefan, Ron, Patrick, Uwe, Cristi
'''Developers:''' Stefan, Ron, Patrick, Uwe, Cristi


= Prototypes =
= Prototypes =
== Unify fallback/normal switch ==
== 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).
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 ===
 
I 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.
'''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.
Unreleased prototype so far, boots QEmu, available on request
 
=== Developers ===
'''Developers:''' Patrick
Patrick
= Done =
== 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


= More ideas =
= More ideas =
== Unify text printing functions ==
== 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).
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 ==
== 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
 
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 ==
== Common payload location ==
Many boards in v2 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).
 
We should fix this by using '''../payload.elf''' as common payload name/location for all boards.
Many boards in v2 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 in v2 where the user specifies a payload manually in "make menuconfig".
A long-term solution will probably be the use of Kconfig in v2 where the user specifies a payload manually as in v3.


== CMOS layout ==
== 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.
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.
= Finished =
== 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

Revision as of 15:49, 14 October 2009

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. Problems on others.

Developers: Stefan

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.

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

Build System

The current system of generated Makefiles is non-ideal (for too many reasons for this little margin). Fix it, somehow.

Status: Upstream, boards are converted. Works side-by-side with the old system.

Developers: Stefan, Ron, Patrick, Uwe, Cristi

Config System

Use KConfig to improve the situation.

Status: Upstream, boards are converted. Works side-by-side with the old system.

Developers: Stefan, Ron, Patrick, Uwe, Cristi

Prototypes

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

Finished

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