Infrastructure Projects: Difference between revisions

From coreboot
Jump to navigation Jump to search
 
(70 intermediate revisions by 9 users not shown)
Line 1: Line 1:
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.
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 =
= In progress =
Line 43: Line 43:
| ?
| ?
| —
| —
|- bgcolor="#dddddd"
| ibm/cpc710
| ?
| —
|- bgcolor="#dddddd"
| ibm/cpc925
| ?
| —
|- bgcolor="#eeeeee"
|- bgcolor="#eeeeee"
| intel/e7501
| intel/e7501
Line 82: Line 72:
| —
| —
|- bgcolor="#eeeeee"
|- bgcolor="#eeeeee"
| intel/i855gme
| intel/i855
| ?
| —
|- bgcolor="#eeeeee"
| intel/i855pm
| ?
| ?
| —
| —
|- bgcolor="#eeeeee"
|- bgcolor="#eeeeee"
| intel/i945
| intel/i945
| ?
| style="background:lime" | Y
| —
| Tested on Kontron 986LCD-M and Roda RK886EX
 
|- bgcolor="#dddddd"
| motorola/mpc107
| ?
| —
 
|- bgcolor="#eeeeee"
|- bgcolor="#eeeeee"
| via/cn400
| via/cn400
Line 128: Line 108:
'''Developers:''' Stefan
'''Developers:''' Stefan


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


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:''' 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.


'''Status:'''
'''Developers:''' Patrick, Uwe


Upstream, pre-CBFS infrastructure removed.
== Move configuration to Kconfig ==


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.
Many boards have lots of <code>#define VAR somevalue</code> 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. <code>util/lint/lint-001-no-global-config-in-romstage</code> helps figuring out what remains to be done.


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


{| border="0" style="font-size: smaller"
'''Developers:''' Patrick, Uwe
|- bgcolor="#6699ff"
! align="left" | Vendor/chipset
! align="left" | ROM enabled
! align="left" | Status / Comments


|- bgcolor="#eeeeee"
== Unify ACPI ==
| amd/amd8111
* Figure out generic ACPI code and deduplicate it.
| style="background:yellow" | Y
* Fix issues like http://www.coreboot.org/pipermail/coreboot/2011-May/065179.html
| An enable_rom() function is implemented and called failover_process(). Untested on hardware, though.
|- bgcolor="#eeeeee"
| amd/cs5530
| style="background:lime" | Y
| Not tested on hardware, yet.
|- bgcolor="#eeeeee"
| amd/cs5535
| ?
| &mdash;
|- bgcolor="#eeeeee"
| amd/cs5536
| ?
| &mdash;
|- bgcolor="#eeeeee"
| amd/sb600
| ?
| &mdash;


|- bgcolor="#dddddd"
Done:
| broadcom/bcm5785
* Every ACPI board has its own routines to compile the ACPI sources. Unify that.
| style="background:yellow" | Y
| An enable_rom() function is implemented and called failover_process(). Untested on hardware, though.


|- bgcolor="#eeeeee"
== CMOS handling ==
| intel/esb6300
| ?
| &mdash;
|- bgcolor="#eeeeee"
| intel/i3100
| ?
| &mdash;
|- bgcolor="#eeeeee"
| intel/i82371eb
| style="background:lime" | Y
| Build- and runtime-tested on ASUS P2B by [[User:Uwe|Uwe Hermann]]
|- bgcolor="#eeeeee"
| intel/i82801ca
| ?
| &mdash;
|- bgcolor="#eeeeee"
| intel/i82801dbm
| ?
| &mdash;
|- bgcolor="#eeeeee"
| intel/i82801er
| ?
| &mdash;
|- bgcolor="#eeeeee"
| intel/i82801gx
| ?
| &mdash;
|- bgcolor="#eeeeee"
| intel/i82801xx
| ?
| &mdash;


|- bgcolor="#dddddd"
The subprojects are ordered in a way that minimizes lost work.
| nvidia/ck804
| style="background:yellow" | Y
| An enable_rom() function is implemented and called failover_process(). Untested on hardware, though.
|- bgcolor="#dddddd"
| nvidia/mcp55
| style="background:yellow" | Y
| An enable_rom() function is implemented and called failover_process(). Untested on hardware, though.


|- bgcolor="#dddddd"
=== CMOS defaults ===
| sis/sis966
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.
| style="background:yellow" | Y
| An enable_rom() function is implemented and called failover_process(). Untested on hardware, though.


|- bgcolor="#eeeeee"
=== CMOS defaults at build time ===
| via/vt8231
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)
| ?
| &mdash;
|- bgcolor="#eeeeee"
| via/vt8235
| ?
| &mdash;
|- bgcolor="#eeeeee"
| via/vt8237r
| ?
| &mdash;
|- bgcolor="#eeeeee"
| via/vt82c686
| ?
| &mdash;


|- bgcolor="#dddddd"
=== Implement a new cmos.layout format ===
| winbond/w83c553
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.
| &mdash;


|}
<code>
400/8 century enum { 0x19="1900", 0x20="2000", 0x21="2100" } default=2000


'''Developers:''' Stefan, Ron, Patrick, Myles, Uwe
408/512 some_string string


== Build System ==
984/16 checksum checksum 392 983
</code>


The current system of generated Makefiles is non-ideal (for too many reasons for this little margin). Fix it, somehow.
=== 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.


'''Status:''' Upstream, boards are converted. Works side-by-side with the old system.
=== 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.


'''Developers:''' Stefan, Ron, Patrick, Uwe, Cristi
=== 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.


== Config System ==
=== 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.


Use KConfig to improve the situation.
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.


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


'''Developers:''' Stefan, Ron, Patrick, Uwe, Cristi
* Make use of global variables where appropriate.


= Prototypes =
Done:
* Provide v3 style global variables framework


== Unify fallback/normal switch ==
== Remove old device_t type ==


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).
The device_t type is currently defined two times inside the coreboot codebase. Once inside src/arch/x86/include/io.h as a u32 (uint32_t) and once inside src/include/device/device.h as a struct.
The first definition is only used during the __PRE_RAM__, __SMM__ and postcar phases/stages, while the second one is used mainly in ramstage (there can be some exception for both cases).
This creates both confusion and possibly subtle errors down the line. In order to address this problem the types pci_devfn_t and pnp_devfn_t have been introduced and should be used to replace the first type of device_t.


'''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.
The changes needed per board/component are usually pretty small and are mostly limited to changing the variable type name and testing that everything still compiles fine.
Sometimes it may be necessary to change some "ifdef guards". If you don't know if the changes are correct, try commenting out the device_t definition inside src/arch/include/io.h and compile again.


'''Developers:''' Patrick
I.e.: In this example (https://review.coreboot.org/#/c/16371/) the only changes needed was the change of types.
You also can deduce which kind of device_t you are dealing with by looking at the functions used and the values that they get assigned.


= More ideas =
= More ideas =


== Unify text printing functions ==
== Handle default boot firmware settings saving at shutdown ==
On some computers, at shutdown, the default boot firmware will save its settings on the boot flash. This is probably done trough SMM.


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).
So when flashing coreboot for the first time with:
# flashrom -p internal build/coreboot.rom
# poweroff
the flash chip will be corrupted, and at the next boot and coreboot might not even boot or act strangely.


== Unify ACPI ==
This could be fixed in coreboot by:
* Adding a generic Kconfig entry in coreboot to allow to reserve a zone in cbfs that should not be touched by coreboot.
* For each affected mainboard, in the mainboard Kconfig, a correspondance between the BIOS versions and the range to reserve could be declared. The BIOS versions could be exposed to the user in make menuconfig.
* Manually selecting the range should also be permitted as a failsafe or testing mechanism.
 
Flashrom is already capable, probably trough DMI, to:
* Identify if coreboot is running on the host system
* To warn the user if she is flashing a coreboot image not meant for the mainboard flashrom is running on.
 
It could then also be extended to:
* Detect the BIOS version
* Check if the coreboot image has a reserved range.
* If not it should warn and also offer the user alternatives advises such as removing the power plug after flashing.
 
Affected mainboards:
* Asrock E350M1
* Asus F2A85M PRO
* Purism Librem 13
 
== 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 (via 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.
 
== 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:
** UDELAY_TSC, TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 (also check UDELAY_IO, APIC, etc.)
** ...
 
Stuff to port from v3 to v4:
 
* All boards that are in v3 but not in v4 (especially Geode LX stuff. Also check amd/model_gx*).
* Some remaining useful Kconfig options.
 
== Clean up Assembler / Linker mess ==
 
* Drop / combine / normalize .ld/.lb/.lds linker scripts.
* Move them to a common place.
* Drop / combine / normalize .inc / .S files.
 
== Geode issues ==
 
* Fix / Unify vsmsetup.c.
* Fix CS5535/CS5536/GX2/LX "chipsetinit" issue.
* Convert openvsa from MASM to something gnu as can use ( Or use JWasm as intermediate solution (it can compile MASM code) http://www.japheth.de/JWasm.html )
 
== Stack and Suspend/Resume ==
 
* Use CONFIG_RAMBASE + HIGH_MEMORY_SAFE instead of 0x40000 for stack.
 
== Fix Suspend/Resume on AMD64 ==
 
* Use cbmem in romstage on the AMD64 board(s) that have suspend/resume.
 
== Clear phases in romstage ==
 
* Split up the code (esp. in romstage) into more sensibly separated phases.
* Maybe use v3 for inspiration where the lines can be drawn.
 
== Refactor SMBUS code ==
 
We have tons of duplication in the smbus/spd related functions and #defines. Every chipset (and sometimes board) does the same with the exception of the 2 or 3 boards that multiplex spd roms.
* Deduplicate SMBUS related defines, they're virtually everywhere (and all the same)
* 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


Every ACPI board has its own routines to compile the ACPI sources. Unify that. Also, figure out generic ACPI code and deduplicate it.
== Move all registers/chip definitions in XML format for all tools ==


== Common payload location ==
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]]


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".
== Device dependency engine ==


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


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.
* Find a good place (or multiple places) where such device decisions can be made
* Refactor the code to make use of it


== Unify UMA / onboard video code and config ==
== Clean out duplicates ==


Unify CONFIG_VIDEO_MB, CONFIG_GFXUMA, and similar options and make all code honor them.
Tools like http://duplo.giants.ch/ or http://pmd.sourceforge.net/cpd.html might be able to help finding duplicates that can be factored out.


= Finished =
== CONFIG_MAX_PHYSICAL_CPUS ==


== Port v3 Resource Allocator ==
CONFIG_MAX_PHYSICAL_CPUS should be dropped. It's set for all boards, but it's only really used by AMD K8 and newer systems (and not on Intel based systems at all).
In the AMD code it is used wrongly:


The v3 resource allocator should be ported to v2.
* for determining which SPD offsets to include
* to determine APIC IDs
* possibly some more things


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


'''Developers:''' Myles
Finished projects are on a [[Infrastructure Projects/Done|separate page]] now

Latest revision as of 12:00, 2 May 2017

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.

Developers: Patrick, Uwe

Unify ACPI

Done:

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

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.

400/8 century enum { 0x19="1900", 0x20="2000", 0x21="2100" } default=2000

408/512 some_string string

984/16 checksum checksum 392 983

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:

  1. a pruned CMOS is a valid configuration
  2. 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

Remove old device_t type

The device_t type is currently defined two times inside the coreboot codebase. Once inside src/arch/x86/include/io.h as a u32 (uint32_t) and once inside src/include/device/device.h as a struct. The first definition is only used during the __PRE_RAM__, __SMM__ and postcar phases/stages, while the second one is used mainly in ramstage (there can be some exception for both cases). This creates both confusion and possibly subtle errors down the line. In order to address this problem the types pci_devfn_t and pnp_devfn_t have been introduced and should be used to replace the first type of device_t.

The changes needed per board/component are usually pretty small and are mostly limited to changing the variable type name and testing that everything still compiles fine. Sometimes it may be necessary to change some "ifdef guards". If you don't know if the changes are correct, try commenting out the device_t definition inside src/arch/include/io.h and compile again.

I.e.: In this example (https://review.coreboot.org/#/c/16371/) the only changes needed was the change of types. You also can deduce which kind of device_t you are dealing with by looking at the functions used and the values that they get assigned.

More ideas

Handle default boot firmware settings saving at shutdown

On some computers, at shutdown, the default boot firmware will save its settings on the boot flash. This is probably done trough SMM.

So when flashing coreboot for the first time with:

# flashrom -p internal build/coreboot.rom
# poweroff

the flash chip will be corrupted, and at the next boot and coreboot might not even boot or act strangely.

This could be fixed in coreboot by:

  • Adding a generic Kconfig entry in coreboot to allow to reserve a zone in cbfs that should not be touched by coreboot.
  • For each affected mainboard, in the mainboard Kconfig, a correspondance between the BIOS versions and the range to reserve could be declared. The BIOS versions could be exposed to the user in make menuconfig.
  • Manually selecting the range should also be permitted as a failsafe or testing mechanism.

Flashrom is already capable, probably trough DMI, to:

  • Identify if coreboot is running on the host system
  • To warn the user if she is flashing a coreboot image not meant for the mainboard flashrom is running on.

It could then also be extended to:

  • Detect the BIOS version
  • Check if the coreboot image has a reserved range.
  • If not it should warn and also offer the user alternatives advises such as removing the power plug after flashing.

Affected mainboards:

  • Asrock E350M1
  • Asus F2A85M PRO
  • Purism Librem 13

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 (via 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.

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:
    • UDELAY_TSC, TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 (also check UDELAY_IO, APIC, etc.)
    • ...

Stuff to port from v3 to v4:

  • All boards that are in v3 but not in v4 (especially Geode LX stuff. Also check amd/model_gx*).
  • Some remaining useful Kconfig options.

Clean up Assembler / Linker mess

  • Drop / combine / normalize .ld/.lb/.lds linker scripts.
  • Move them to a common place.
  • Drop / combine / normalize .inc / .S files.

Geode issues

  • Fix / Unify vsmsetup.c.
  • Fix CS5535/CS5536/GX2/LX "chipsetinit" issue.
  • Convert openvsa from MASM to something gnu as can use ( Or use JWasm as intermediate solution (it can compile MASM code) http://www.japheth.de/JWasm.html )

Stack and Suspend/Resume

  • Use CONFIG_RAMBASE + HIGH_MEMORY_SAFE instead of 0x40000 for stack.

Fix Suspend/Resume on AMD64

  • Use cbmem in romstage on the AMD64 board(s) that have suspend/resume.

Clear phases in romstage

  • Split up the code (esp. in romstage) into more sensibly separated phases.
  • Maybe use v3 for inspiration where the lines can be drawn.

Refactor SMBUS code

We have tons of duplication in the smbus/spd related functions and #defines. Every chipset (and sometimes board) does the same with the exception of the 2 or 3 boards that multiplex spd roms.

  • Deduplicate SMBUS related defines, they're virtually everywhere (and all the same)
  • 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
  • Refactor the code to make use of it

Clean out duplicates

Tools like http://duplo.giants.ch/ or http://pmd.sourceforge.net/cpd.html might be able to help finding duplicates that can be factored out.

CONFIG_MAX_PHYSICAL_CPUS

CONFIG_MAX_PHYSICAL_CPUS should be dropped. It's set for all boards, but it's only really used by AMD K8 and newer systems (and not on Intel based systems at all). In the AMD code it is used wrongly:

  • for determining which SPD offsets to include
  • to determine APIC IDs
  • possibly some more things

Finished

Finished projects are on a separate page now