https://www.coreboot.org/api.php?action=feedcontributions&user=Vikram&feedformat=atomcoreboot - User contributions [en]2024-03-29T02:38:17ZUser contributionsMediaWiki 1.40.0https://www.coreboot.org/index.php?title=Infrastructure_Projects&diff=11070Infrastructure Projects2012-04-21T17:23:51Z<p>Vikram: /* Finished */ Add unift build_opt_tbl and nvramtool</p>
<hr />
<div>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.<br />
<br />
= In progress =<br />
<br />
== Low/High Tables ==<br />
<br />
SeaBIOS requires a copy of various BIOS tables outside the fseg as it overwrites that segment. Generally clean out the table generation code.<br />
<br />
'''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).<br />
<br />
{| border="0" style="font-size: smaller"<br />
|- bgcolor="#6699ff"<br />
! align="left" | Vendor/chipset<br />
! align="left" | Tested<br />
! align="left" | Comments<br />
<br />
|- bgcolor="#eeeeee"<br />
| amd/amdfam10<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/amdht<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/amdk8<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/amdmct<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/gx1<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/gx2<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/lx<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/e7501<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/e7520<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/e7525<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i3100<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i440bx<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82810<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82830<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i855<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i945<br />
| style="background:lime" | Y<br />
| Tested on Kontron 986LCD-M and Roda RK886EX<br />
|- bgcolor="#eeeeee"<br />
| via/cn400<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/cn700<br />
| style="background:lime" | Y<br />
| Tested on VIA pc2500e.<br />
|- bgcolor="#eeeeee"<br />
| via/cx700<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/vt8601<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/vt8623<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/vx800<br />
| ?<br />
| &mdash;<br />
<br />
|}<br />
<br />
'''Developers:''' Stefan<br />
<br />
== CBFS ==<br />
<br />
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).<br />
<br />
'''Status:'''<br />
<br />
Upstream, pre-CBFS infrastructure removed.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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)<br />
<br />
{| border="0" style="font-size: smaller"<br />
|- bgcolor="#6699ff"<br />
! align="left" | Vendor/chipset<br />
! align="left" | ROM enabled<br />
! align="left" | Tiny bootblock<br />
! align="left" | Status / Comments<br />
<br />
|- bgcolor="#eeeeee"<br />
| amd/amd8111<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| Not tested on hardware, yet.<br />
|- bgcolor="#eeeeee"<br />
| amd/cs5530<br />
| style="background:lime" | Y<br />
| style="background:red" | N<br />
| Not tested on hardware, yet.<br />
|- bgcolor="#eeeeee"<br />
| amd/cs5535<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/cs5536<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/sb600<br />
| style="background:lime" | Y<br />
| style="background:lime" | Y<br />
| Build- and runtime-tested on siemens/sitemp_g1p1 by [[User:PatrickGeorgi|PatrickGeorgi]].<br />
|- bgcolor="#eeeeee"<br />
| amd/sb700<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| &mdash;<br />
<br />
|- bgcolor="#dddddd"<br />
| broadcom/bcm5785<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| Not tested on hardware, yet.<br />
<br />
|- bgcolor="#eeeeee"<br />
| intel/esb6300<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i3100<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82371eb<br />
| style="background:lime" | Y<br />
| style="background:yellow" | Y<br />
| Build- and runtime-tested on ASUS P2B by [[User:Uwe|Uwe Hermann]].<br />
|- bgcolor="#eeeeee"<br />
| intel/i82801ax<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82801bx<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82801cx<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82801dx<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82801ex<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82801gx<br />
| style="background:lime" | Y<br />
| style="background:lime" | Y<br />
| Build- and runtime-tested on Kontron 986LCD-m by PatrickGeorgi<br />
<br />
|- bgcolor="#dddddd"<br />
| nvidia/ck804<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| Not tested on hardware, yet.<br />
|- bgcolor="#dddddd"<br />
| nvidia/mcp55<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| Not tested on hardware, yet.<br />
<br />
|- bgcolor="#dddddd"<br />
| sis/sis966<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| Not tested on hardware, yet.<br />
<br />
|- bgcolor="#eeeeee"<br />
| via/vt8231<br />
| style="background:yellow" | Y<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/vt8235<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/vt8237r<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/vt82c686<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
<br />
|}<br />
<br />
'''Developers:''' Stefan, Ron, Patrick, Myles, Uwe<br />
<br />
== Tiny Bootblock ==<br />
<br />
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).<br />
<br />
'''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).<br />
<br />
'''Developers:''' Patrick<br />
<br />
== Remove .c includes ==<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
'''Developers:''' Patrick, Uwe<br />
<br />
== Move configuration to Kconfig ==<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
'''Developers:''' Patrick, Uwe<br />
<br />
== Unify ACPI ==<br />
* Figure out generic ACPI code and deduplicate it.<br />
* Fix issues like http://www.coreboot.org/pipermail/coreboot/2011-May/065179.html<br />
<br />
Done:<br />
* Every ACPI board has its own routines to compile the ACPI sources. Unify that.<br />
<br />
== Local APIC addresses ==<br />
<br />
There are several defines in several places that describe the local APIC address:<br />
<br />
* LAPIC_ADDR<br />
* LOCAL_APIC_ADDR (even twice)<br />
* LAPIC_DEFAULT_BASE<br />
<br />
This should be unified.<br />
<br />
'''Developers:''' Patrick<br />
<br />
= More ideas =<br />
<br />
== CMOS handling ==<br />
<br />
The subprojects are ordered in a way that minimizes lost work.<br />
<br />
=== Simplify get_option ===<br />
Replace <code>get_option(VALstart, VALlen, default)</code> with a macro that hides start/len in something like <code>get_option(VAL, default)</code><br />
<br />
=== Implement a new cmos.layout format ===<br />
The current layout is simple to parse, but not so simple to maintain or extend.<br />
Create a format that combines the various fields into a single representation, eg.<br />
<br />
<code><br />
400/8 century enum { 0x19="1900", 0x20="2000", 0x21="2100" }<br />
<br />
408/512 some_string string<br />
<br />
984/16 checksum checksum 392 983<br />
</code><br />
<br />
=== Implement an include statement ===<br />
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.<br />
<br />
=== CMOS defaults ===<br />
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.<br />
In the above format, it could simply be a suffix <code>default=VALUE</code><br />
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.<br />
<br />
=== Value overrides ===<br />
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.<br />
<br />
=== Provide update paths and avoid conflicts in addressing ===<br />
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)<br />
<br />
=== Checksums ===<br />
<br />
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.<br />
<br />
== Unify UMA / onboard video code and config ==<br />
<br />
Unify CONFIG_VIDEO_MB, CONFIG_GFXUMA, and similar options and make all code honor them.<br />
<br />
== Add / Unify / Test kconfig compile-time options and runtime CMOS options in coreboot ==<br />
<br />
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.<br />
<br />
* Make all options (where it makes sense) run-time configurable via CMOS options, in addition to having sane compile-time defaults configured via kconfig.<br />
* This includes many options which are northbridge-specific, many southbridge-specific, and some board-specific ones.<br />
* 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.<br />
* 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.<br />
<br />
== Kconfig TODO ==<br />
<br />
Notes / Style guide:<br />
<br />
* 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.<br />
* Use '''bool''' instead of '''boolean'''.<br />
* Use '''default n''' instead of '''default false'''.<br />
<br />
Various post-conversion things to consider:<br />
<br />
* Consider ways to move crt0-y and ldscript-y out of $(src)/arch/i386/Makefile.inc where appropriate (ie. component specific)<br />
* Make various CONFIG_* variable which were in each board's Kconfig file global or per-chipset options (instead of per-board). Examples:<br />
** UDELAY_TSC, TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 (also check UDELAY_IO, APIC, etc.)<br />
** ...<br />
<br />
Stuff to port from v3 to v4:<br />
<br />
* All boards that are in v3 but not in v4 (especially Geode LX stuff. Also check amd/model_gx*).<br />
* Some remaining useful Kconfig options.<br />
<br />
== USB Debug Console ==<br />
<br />
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.<br />
<br />
== Clean up Assembler / Linker mess ==<br />
<br />
* Drop / combine / normalize .ld/.lb/.lds linker scripts.<br />
* Move them to a common place.<br />
* Drop / combine / normalize .inc / .S files.<br />
<br />
== Geode issues ==<br />
<br />
* Fix / Unify vsmsetup.c.<br />
* Fix CS5535/CS5536/GX2/LX "chipsetinit" issue.<br />
<br />
== Stack and Suspend/Resume ==<br />
<br />
* Use CONFIG_RAMBASE + HIGH_MEMORY_SAFE instead of 0x40000 for stack.<br />
<br />
== Fix Suspend/Resume on AMD64 ==<br />
<br />
* Use cbmem in romstage on the AMD64 board(s) that have suspend/resume.<br />
<br />
== printk into buffer ==<br />
<br />
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).<br />
<br />
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).<br />
<br />
== Global variables ==<br />
<br />
* Port the global variables framework from v3.<br />
* Make use of it where appropriate.<br />
<br />
== Clear phases in romstage ==<br />
<br />
* Split up the code (esp. in romstage) into more sensibly separated phases.<br />
* Maybe use v3 for inspiration where the lines can be drawn.<br />
<br />
== Refactor SMBUS code ==<br />
<br />
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.<br />
* Deduplicate SMBUS related defines, they're virtually everywhere (and all the same)<br />
* Deduplicate the lowlevel functions - they should really be the same (except for some style differences)<br />
* Deduplicate the non-multiplexing highlevel functions. Mark them weak, so multiplexing boards can simply provide their own variant, which override the weak functions automatically<br />
<br />
== Move all registers/chip definitions in XML format for all tools ==<br />
<br />
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]]<br />
<br />
== Device dependency engine ==<br />
<br />
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, ...<br />
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.<br />
<br />
* Find a good place (or multiple places) where such device decisions can be made<br />
* Refactor the code to make use of it<br />
<br />
== Clean out duplicates ==<br />
<br />
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.<br />
<br />
== CONFIG_MAX_PHYSICAL_CPUS ==<br />
<br />
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).<br />
In the AMD code it is used wrongly:<br />
<br />
* for determining which SPD offsets to include<br />
* to determine APIC IDs<br />
* possibly some more things<br />
<br />
= Finished =<br />
<br />
== Port v3 Resource Allocator ==<br />
<br />
The v3 resource allocator should be ported to v4.<br />
<br />
'''Status:''' Upstream. It's limited to one area for resources, that doesn't overlap with fixed resources.<br />
<br />
'''Developers:''' Myles<br />
<br />
== Config & Build System ==<br />
<br />
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.<br />
<br />
'''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!<br />
<br />
'''Developers:''' Stefan, Ron, Patrick, Uwe, Cristi<br />
<br />
== Unify text printing functions ==<br />
<br />
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).<br />
<br />
'''Status:''' Finished.<br />
<br />
'''Developers:''' Patrick, Stefan<br />
<br />
== Common payload location ==<br />
<br />
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".<br />
<br />
'''Status:''' Finished.<br />
<br />
== Fix ALL build warnings ==<br />
<br />
* Someone has to do the deed.<br />
<br />
'''Status:''' Finished, the build usually issues no warnings. If you see warnings/errors, please report a bug.<br />
<br />
== Post codes ==<br />
<br />
Find all outb(x, 0x80) and replace them with post_code(). Use common numbers / defines across the boards.<br />
<br />
'''Status:''' Finished, except for some local delay routines in early smbus code.<br />
<br />
== Use central oprom init ==<br />
<br />
* Get rid of all vgabios.c, make all chipsets with own vgabios.c use devices/oprom/x86.c.<br />
* Use the realmode code for vsmsetup too.<br />
<br />
== Use nvramtool for static option table creation ==<br />
<br />
Instead of maintaining two tools (build_opt_tbl, nvramtool), maintain only one. This mostly requires adding an binary output writer to nvramtool, a cmos.layout parser already exists.<br />
<br />
'''Status:''' Finished, upstream.<br />
<br />
'''Developers:''' Vikram</div>Vikramhttps://www.coreboot.org/index.php?title=Infrastructure_Projects&diff=11069Infrastructure Projects2012-04-21T17:20:16Z<p>Vikram: /* More ideas */ Removed unify build_opt_tbl and nvramtool as it is done</p>
<hr />
<div>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.<br />
<br />
= In progress =<br />
<br />
== Low/High Tables ==<br />
<br />
SeaBIOS requires a copy of various BIOS tables outside the fseg as it overwrites that segment. Generally clean out the table generation code.<br />
<br />
'''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).<br />
<br />
{| border="0" style="font-size: smaller"<br />
|- bgcolor="#6699ff"<br />
! align="left" | Vendor/chipset<br />
! align="left" | Tested<br />
! align="left" | Comments<br />
<br />
|- bgcolor="#eeeeee"<br />
| amd/amdfam10<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/amdht<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/amdk8<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/amdmct<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/gx1<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/gx2<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/lx<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/e7501<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/e7520<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/e7525<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i3100<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i440bx<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82810<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82830<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i855<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i945<br />
| style="background:lime" | Y<br />
| Tested on Kontron 986LCD-M and Roda RK886EX<br />
|- bgcolor="#eeeeee"<br />
| via/cn400<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/cn700<br />
| style="background:lime" | Y<br />
| Tested on VIA pc2500e.<br />
|- bgcolor="#eeeeee"<br />
| via/cx700<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/vt8601<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/vt8623<br />
| ?<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/vx800<br />
| ?<br />
| &mdash;<br />
<br />
|}<br />
<br />
'''Developers:''' Stefan<br />
<br />
== CBFS ==<br />
<br />
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).<br />
<br />
'''Status:'''<br />
<br />
Upstream, pre-CBFS infrastructure removed.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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)<br />
<br />
{| border="0" style="font-size: smaller"<br />
|- bgcolor="#6699ff"<br />
! align="left" | Vendor/chipset<br />
! align="left" | ROM enabled<br />
! align="left" | Tiny bootblock<br />
! align="left" | Status / Comments<br />
<br />
|- bgcolor="#eeeeee"<br />
| amd/amd8111<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| Not tested on hardware, yet.<br />
|- bgcolor="#eeeeee"<br />
| amd/cs5530<br />
| style="background:lime" | Y<br />
| style="background:red" | N<br />
| Not tested on hardware, yet.<br />
|- bgcolor="#eeeeee"<br />
| amd/cs5535<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/cs5536<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| amd/sb600<br />
| style="background:lime" | Y<br />
| style="background:lime" | Y<br />
| Build- and runtime-tested on siemens/sitemp_g1p1 by [[User:PatrickGeorgi|PatrickGeorgi]].<br />
|- bgcolor="#eeeeee"<br />
| amd/sb700<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| &mdash;<br />
<br />
|- bgcolor="#dddddd"<br />
| broadcom/bcm5785<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| Not tested on hardware, yet.<br />
<br />
|- bgcolor="#eeeeee"<br />
| intel/esb6300<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i3100<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82371eb<br />
| style="background:lime" | Y<br />
| style="background:yellow" | Y<br />
| Build- and runtime-tested on ASUS P2B by [[User:Uwe|Uwe Hermann]].<br />
|- bgcolor="#eeeeee"<br />
| intel/i82801ax<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82801bx<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82801cx<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82801dx<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82801ex<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| intel/i82801gx<br />
| style="background:lime" | Y<br />
| style="background:lime" | Y<br />
| Build- and runtime-tested on Kontron 986LCD-m by PatrickGeorgi<br />
<br />
|- bgcolor="#dddddd"<br />
| nvidia/ck804<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| Not tested on hardware, yet.<br />
|- bgcolor="#dddddd"<br />
| nvidia/mcp55<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| Not tested on hardware, yet.<br />
<br />
|- bgcolor="#dddddd"<br />
| sis/sis966<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| Not tested on hardware, yet.<br />
<br />
|- bgcolor="#eeeeee"<br />
| via/vt8231<br />
| style="background:yellow" | Y<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/vt8235<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/vt8237r<br />
| style="background:yellow" | Y<br />
| style="background:yellow" | Y<br />
| &mdash;<br />
|- bgcolor="#eeeeee"<br />
| via/vt82c686<br />
| style="background:red" | N<br />
| style="background:red" | N<br />
| &mdash;<br />
<br />
|}<br />
<br />
'''Developers:''' Stefan, Ron, Patrick, Myles, Uwe<br />
<br />
== Tiny Bootblock ==<br />
<br />
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).<br />
<br />
'''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).<br />
<br />
'''Developers:''' Patrick<br />
<br />
== Remove .c includes ==<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
'''Developers:''' Patrick, Uwe<br />
<br />
== Move configuration to Kconfig ==<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
'''Developers:''' Patrick, Uwe<br />
<br />
== Unify ACPI ==<br />
* Figure out generic ACPI code and deduplicate it.<br />
* Fix issues like http://www.coreboot.org/pipermail/coreboot/2011-May/065179.html<br />
<br />
Done:<br />
* Every ACPI board has its own routines to compile the ACPI sources. Unify that.<br />
<br />
== Local APIC addresses ==<br />
<br />
There are several defines in several places that describe the local APIC address:<br />
<br />
* LAPIC_ADDR<br />
* LOCAL_APIC_ADDR (even twice)<br />
* LAPIC_DEFAULT_BASE<br />
<br />
This should be unified.<br />
<br />
'''Developers:''' Patrick<br />
<br />
= More ideas =<br />
<br />
== CMOS handling ==<br />
<br />
The subprojects are ordered in a way that minimizes lost work.<br />
<br />
=== Simplify get_option ===<br />
Replace <code>get_option(VALstart, VALlen, default)</code> with a macro that hides start/len in something like <code>get_option(VAL, default)</code><br />
<br />
=== Implement a new cmos.layout format ===<br />
The current layout is simple to parse, but not so simple to maintain or extend.<br />
Create a format that combines the various fields into a single representation, eg.<br />
<br />
<code><br />
400/8 century enum { 0x19="1900", 0x20="2000", 0x21="2100" }<br />
<br />
408/512 some_string string<br />
<br />
984/16 checksum checksum 392 983<br />
</code><br />
<br />
=== Implement an include statement ===<br />
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.<br />
<br />
=== CMOS defaults ===<br />
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.<br />
In the above format, it could simply be a suffix <code>default=VALUE</code><br />
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.<br />
<br />
=== Value overrides ===<br />
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.<br />
<br />
=== Provide update paths and avoid conflicts in addressing ===<br />
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)<br />
<br />
=== Checksums ===<br />
<br />
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.<br />
<br />
== Unify UMA / onboard video code and config ==<br />
<br />
Unify CONFIG_VIDEO_MB, CONFIG_GFXUMA, and similar options and make all code honor them.<br />
<br />
== Add / Unify / Test kconfig compile-time options and runtime CMOS options in coreboot ==<br />
<br />
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.<br />
<br />
* Make all options (where it makes sense) run-time configurable via CMOS options, in addition to having sane compile-time defaults configured via kconfig.<br />
* This includes many options which are northbridge-specific, many southbridge-specific, and some board-specific ones.<br />
* 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.<br />
* 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.<br />
<br />
== Kconfig TODO ==<br />
<br />
Notes / Style guide:<br />
<br />
* 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.<br />
* Use '''bool''' instead of '''boolean'''.<br />
* Use '''default n''' instead of '''default false'''.<br />
<br />
Various post-conversion things to consider:<br />
<br />
* Consider ways to move crt0-y and ldscript-y out of $(src)/arch/i386/Makefile.inc where appropriate (ie. component specific)<br />
* Make various CONFIG_* variable which were in each board's Kconfig file global or per-chipset options (instead of per-board). Examples:<br />
** UDELAY_TSC, TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 (also check UDELAY_IO, APIC, etc.)<br />
** ...<br />
<br />
Stuff to port from v3 to v4:<br />
<br />
* All boards that are in v3 but not in v4 (especially Geode LX stuff. Also check amd/model_gx*).<br />
* Some remaining useful Kconfig options.<br />
<br />
== USB Debug Console ==<br />
<br />
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.<br />
<br />
== Clean up Assembler / Linker mess ==<br />
<br />
* Drop / combine / normalize .ld/.lb/.lds linker scripts.<br />
* Move them to a common place.<br />
* Drop / combine / normalize .inc / .S files.<br />
<br />
== Geode issues ==<br />
<br />
* Fix / Unify vsmsetup.c.<br />
* Fix CS5535/CS5536/GX2/LX "chipsetinit" issue.<br />
<br />
== Stack and Suspend/Resume ==<br />
<br />
* Use CONFIG_RAMBASE + HIGH_MEMORY_SAFE instead of 0x40000 for stack.<br />
<br />
== Fix Suspend/Resume on AMD64 ==<br />
<br />
* Use cbmem in romstage on the AMD64 board(s) that have suspend/resume.<br />
<br />
== printk into buffer ==<br />
<br />
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).<br />
<br />
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).<br />
<br />
== Global variables ==<br />
<br />
* Port the global variables framework from v3.<br />
* Make use of it where appropriate.<br />
<br />
== Clear phases in romstage ==<br />
<br />
* Split up the code (esp. in romstage) into more sensibly separated phases.<br />
* Maybe use v3 for inspiration where the lines can be drawn.<br />
<br />
== Refactor SMBUS code ==<br />
<br />
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.<br />
* Deduplicate SMBUS related defines, they're virtually everywhere (and all the same)<br />
* Deduplicate the lowlevel functions - they should really be the same (except for some style differences)<br />
* Deduplicate the non-multiplexing highlevel functions. Mark them weak, so multiplexing boards can simply provide their own variant, which override the weak functions automatically<br />
<br />
== Move all registers/chip definitions in XML format for all tools ==<br />
<br />
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]]<br />
<br />
== Device dependency engine ==<br />
<br />
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, ...<br />
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.<br />
<br />
* Find a good place (or multiple places) where such device decisions can be made<br />
* Refactor the code to make use of it<br />
<br />
== Clean out duplicates ==<br />
<br />
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.<br />
<br />
== CONFIG_MAX_PHYSICAL_CPUS ==<br />
<br />
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).<br />
In the AMD code it is used wrongly:<br />
<br />
* for determining which SPD offsets to include<br />
* to determine APIC IDs<br />
* possibly some more things<br />
<br />
= Finished =<br />
<br />
== Port v3 Resource Allocator ==<br />
<br />
The v3 resource allocator should be ported to v4.<br />
<br />
'''Status:''' Upstream. It's limited to one area for resources, that doesn't overlap with fixed resources.<br />
<br />
'''Developers:''' Myles<br />
<br />
== Config & Build System ==<br />
<br />
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.<br />
<br />
'''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!<br />
<br />
'''Developers:''' Stefan, Ron, Patrick, Uwe, Cristi<br />
<br />
== Unify text printing functions ==<br />
<br />
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).<br />
<br />
'''Status:''' Finished.<br />
<br />
'''Developers:''' Patrick, Stefan<br />
<br />
== Common payload location ==<br />
<br />
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".<br />
<br />
'''Status:''' Finished.<br />
<br />
== Fix ALL build warnings ==<br />
<br />
* Someone has to do the deed.<br />
<br />
'''Status:''' Finished, the build usually issues no warnings. If you see warnings/errors, please report a bug.<br />
<br />
== Post codes ==<br />
<br />
Find all outb(x, 0x80) and replace them with post_code(). Use common numbers / defines across the boards.<br />
<br />
'''Status:''' Finished, except for some local delay routines in early smbus code.<br />
<br />
== Use central oprom init ==<br />
<br />
* Get rid of all vgabios.c, make all chipsets with own vgabios.c use devices/oprom/x86.c.<br />
* Use the realmode code for vsmsetup too.</div>Vikramhttps://www.coreboot.org/index.php?title=Supported_Chipsets_and_Devices&diff=10966Supported Chipsets and Devices2012-01-26T13:31:55Z<p>Vikram: </p>
<hr />
<div>'''coreboot v4''' is the current stable coreboot tree recommended for productive use and for porting new boards.<br />
* If a device is not supported by coreboot v4, try [[Supported_Chipsets_and_Devices#Devices_supported_in_coreboot_v1|checking coreboot v1]] or [[Supported_Chipsets_and_Devices#Devices_supported_in_coreboot_v3|coreboot v3]] for support.<br />
* In general it is '''not''' recommended to use coreboot v3 &mdash; this was an experimental development tree which is gradually being merged into v4.<br />
* Also, coreboot v1 should be avoided (if v4 can be used instead for your board), as it has been unmaintained for a long time. However, it is definitely desirable to port boards from v1 to v4 whereever possible.<br />
<br />
See also [[Supported Motherboards]].<br />
<br />
== Devices supported in coreboot v4 ==<br />
<br />
{| border="0" valign="top"<br />
| valign="top"|<br />
<br />
'''Northbridges'''<br />
<br />
{| border="0" style="font-size: smaller" valign="top"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | Northbridge<br />
! align="left" | Status<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| Fam14h - G-Series<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| Fam12h - Llano<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| Fam10h<br />
| style="background:lime" | OK<sup>16</sup><br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| K8<br />
| style="background: lime " | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| GX1<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| GX&nbsp;(GX2)<br />
| style="background: lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| LX<br />
| style="background: lime" | OK<br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| E7501<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| E7520<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| E7525<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 3100<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 82443BX&nbsp;(440BX)<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 82810<br />
| style="background:yellow" | WIP<sup>9</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 82830<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 82855<br />
| style="background:yellow" | WIP<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| EP80579 (Tolapai)<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 945<br />
| style="background:lime" | OK<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| SiS<br />
| SiS761GX<br />
| style="background:lime" | OK<br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| VT8601 (PLE133)<br />
| style="background:yellow" | WIP<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| VT8623 (CLE266)<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| K8T890<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| K8M890<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| CN400<br />
| ?<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| CN700<br />
| style="background:lime" | OK<sup>14</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| CX700<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| VX800<br />
| style="background:yellow" | WIP<br />
<br />
|}<br />
<br />
| valign="top"|<br />
<br />
'''Southbridges'''<br />
<br />
{| border="0" style="font-size: smaller" valign="top"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | Southbridge<br />
! align="left" | Status<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| AMD8111<br />
| style="background: lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| AMD8131<br />
| style="background: lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| AMD8132<br />
| style="background: lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| AMD8151<br />
| style="background: lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| CS5530/CS5530A<br />
| style="background:yellow" | WIP<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| CS5535<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| CS5536<br />
| style="background: lime " | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| RS690<br />
| style="background: lime " | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| SB600<br />
| style="background: lime " | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| RS780/RS785<br />
| style="background: lime " | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| SB700/SB7x0<br />
| style="background: lime " | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| SR56x0<br />
| style="background: lime " | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| SB5100<br />
| style="background: lime " | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| SB800<br />
| style="background: lime " | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Broadcom<br />
| BCM21000<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Broadcom<br />
| BCM5780<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Broadcom<br />
| BCM5785<br />
| style="background:lime" | OK<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 6300ESB (ESB6300)<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 3100<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 82371EB&nbsp;(PIIX4E)<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 82801AA/AB&nbsp;(ICH/ICH0)<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 82801BA/BAM&nbsp;(ICH2/ICH2-M)<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 82801CA/CAM&nbsp;(ICH3-S/ICH3-M)<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 82801DB/DBL/DBM<br/>(ICH4/ICH4-L/ICH4-M)<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 82801EB/ER&nbsp;(ICH5/ICH5R)<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 82801GX&nbsp;(ICH7)<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 82870<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| PXHD<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| EP80579 (Tolapai)<br />
| style="background:lime" | OK<br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| NVIDIA<br />
| CK804<br />
| style="background:lime" | OK<sup>17</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| NVIDIA<br />
| MCP55<br />
| style="background:lime" | OK<sup>17</sup><br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Ricoh<br />
| RL5C476<br />
| style="background:#eeeeee" | ?<br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| SiS<br />
| SiS966(L)<br />
| style="background:lime" | OK<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| VIA<br />
| VT8231<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| VIA<br />
| VT8235<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| VIA<br />
| VT8237R<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| VIA<br />
| VT8237A<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| VIA<br />
| VT8237S<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| VIA<br />
| VT82C686<br />
| style="background:yellow" | WIP<br />
<br />
|}<br />
<br />
| valign="top"|<br />
<br />
'''Super I/Os'''<br />
<br />
{| border="0" style="font-size: smaller" valign="top"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | Super&nbsp;I/O<br />
! align="left" | Status<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| ASUS<br />
| A8000<br />
| style="background:lime" | OK<sup>12</sup>, <sup>13</sup><br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| Fintek<br />
| F71805F/FG<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Fintek<br />
| F71859<br />
| style="background:yellow" | OK<sup>19</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| Fintek<br />
| F71863F/FG<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Fintek<br />
| F71872F/FG<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Fintek<br />
| F71889<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Fintek<br />
| F81865F<br />
| style="background:yellow" | WIP<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| ITE<br />
| IT8661F<br />
| style="background:yellow" | OK<sup>5</sup><br />
|- bgcolor="#eeeeee" valign="top"<br />
| ITE<br />
| IT8671F<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| ITE<br />
| IT8673F<br />
| style="background:yellow" | OK<sup>5</sup><br />
|- bgcolor="#eeeeee" valign="top"<br />
| ITE<br />
| IT8705F<br />
| style="background:yellow" | OK<sup>5</sup><br />
|- bgcolor="#eeeeee" valign="top"<br />
| ITE<br />
| IT8712F<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| ITE<br />
| IT8716F<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| ITE<br />
| IT8718F<br />
| style="background:yellow" | OK<sup>5</sup><br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 3100<br />
| style="background:lime" | OK<sup>15</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| EP80579 (Tolapai)<br />
| style="background:lime" | OK<sup>15</sup><br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| PC8374<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| PC87309<br />
| style="background:yellow" | OK<sup>5</sup><br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| PC87351<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| PC87360<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| PC87366<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| PC87417<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| PC87427<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| PC97307 <br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| PC97317<br />
| style="background:#eeeeee" | ?<br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| ServerEngines<br />
| PILOT<br />
| style="background:yellow" | OK<sup>18</sup><br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| FDC37M70x<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| FDC37B80x<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| FDC37B78x<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| FDC37B72x<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| FDC37B81x<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| FDC37M60x<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| LPC47B27x<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| LPC47M10x<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| LPC47M112<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| LPC47M13x<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| LPC47M15x<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| LPC47M192<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| LPC47B397<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| DME1737<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| SCH5307<br />
| style="background:lime" | OK<sup>12</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| SMSC&reg;<br />
| LPC47N217<br />
| style="background:#dddddd" | ?<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| VIA<br />
| VT1211<br />
| style="background:#eeeeee" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| VIA<br />
| VT82C686(A/B)<br />
| style="background:yellow" | OK<sup>5</sup><br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| Winbond&trade;<br />
| W83627DHG<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Winbond&trade;<br />
| W83627UHG<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Winbond&trade;<br />
| W83627EHG/HF/EHF/THF<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Winbond&trade;<br />
| W83697HF/HG<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Winbond&trade;<br />
| W83627THF/THG<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Winbond&trade;<br />
| W83977F<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Winbond&trade;<br />
| W83977TF<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Winbond&trade;<br />
| W83977EF<br />
| style="background:lime" | OK<sup>4</sup><br />
|}<br />
<br />
| valign="top"|<br />
<br />
'''CPUs'''<br />
<br />
{| border="0" style="font-size: smaller"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Type<br />
! align="left" | CPU<br />
! align="left" | Status<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| x86<br />
| AMD<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| x86<br />
| Intel&reg;<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| x86<br />
| VIA<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Emulated<br />
| QEMU<br />
| style="background:lime" | OK<br />
|}<br />
<br />
'''SOCs'''<br />
<br />
{| border="0" style="font-size: smaller" valign="top"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | SOC<br />
! align="left" | Status<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| Elan SC520<br />
| style="background: lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| EP80579 (Tolapai)<br />
| style="background: lime" | OK<br />
|}<br />
<br />
|}<br />
<br />
<small><br />
<sup>4</sup> The W83977EF works fine with the W83977TF code (the pre-RAM serial part at least).<br /><br />
<sup>5</sup> Pre-RAM serial output works fine, but nothing else, yet.<br /><br />
<sup>9</sup> Works mostly, but currently there are some limitations as to which RAM DIMMs can be used.<br /><br />
<sup>12</sup> All these Super I/O chips should be supported by the "smscsuperio" driver. Only the ASUS A8000 is tested, though. The floppy disk controller, the parallel port, the serial ports (COM1 + COM2), and the keyboard should work for all chips. More advanced stuff may need more work, though.<br /><br />
<sup>13</sup> The ASUS A8000 Super I/O seems to be a rebranded SMSC DME1737.<br /><br />
<sup>14</sup> Working, but not widely tested, yet. Works with single DIMM DDR2.<br /><br />
<sup>15</sup> The Intel 3100/EP80579 UARTs and watchdog timer are integrated as a Super I/O-like device; only the UARTs have been tested so far.<br /><br />
<sup>16</sup> Two implementations: Rev B-C supported in coreboot, Rev D-E support via AGESA<br /><br />
<sup>17</sup> MCP55 and CK804 are supported, but no open documents are available from NVIDIA.<br /><br />
<sup>18</sup> Partially supported, but not all features implemented.<br /><br />
<sup>19</sup> Only support for serial port 1 implemented, everything else is unsupported so far due to lack of datasheet.<br /><br />
</small><br />
<br />
== Devices supported in coreboot v3 ==<br />
<br />
<div style="color: #ff0000">coreboot v3 was an experimental development tree of coreboot which should not be used anymore (there are only very few exceptions)! Most features from v3 are gradually being merged into v4.</div><br />
<br />
{| border="0" valign="top"<br />
| valign="top"|<br />
<br />
'''Northbridges'''<br />
<br />
{| border="0" style="font-size: smaller" valign="top"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | Northbridge<br />
! align="left" | Status<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| Geode&nbsp;LX<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| Geode&nbsp;K8<br />
| style="background:orange" | WIP<br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 82443BX&nbsp;(440BX)<br />
| style="background:orange" | WIP<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 945<br />
| style="background:orange" | WIP<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| VIA<br />
| CN700<br />
| style="background:orange" | WIP<br />
<br />
|}<br />
<br />
| valign="top"|<br />
<br />
'''Southbridges'''<br />
<br />
{| border="0" style="font-size: smaller" valign="top"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | Southbridge<br />
! align="left" | Status<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| AMD-8111<br />
| style="background:yellow" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| AMD-8132<br />
| style="background:yellow" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| AMD-8151<br />
| style="background:yellow" | ?<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| CS5536<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| RS690<br />
| style="background: lime " | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| SB600<br />
| style="background: lime " | OK<br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 82371EB&nbsp;(PIIX4E)<br />
| style="background:orange" | WIP<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 82801GX&nbsp;(ICH7)<br />
| style="background:orange" | WIP<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NVIDIA<br />
| MCP55<br />
| style="background:orange" | WIP<sup>1</sup><br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| VT8237R<br />
| style="background:orange" | WIP<br />
<br />
|}<br />
<br />
| valign="top"|<br />
<br />
'''Super I/Os'''<br />
<br />
{| border="0" style="font-size: smaller" valign="top"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | Super&nbsp;I/O<br />
! align="left" | Status<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Fintek<br />
| F71805F<br />
| style="background:orange" | WIP<br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| ITE<br />
| IT8712F<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| ITE<br />
| IT8716F<br />
| style="background:lime" | OK<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| VIA<br />
| VT1211<br />
| style="background:orange" | WIP<br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| Winbond&trade;<br />
| W83627HF<br />
| style="background:lime" | OK<br />
|- bgcolor="#dddddd" valign="top"<br />
| Winbond&trade;<br />
| W83627THG<br />
| style="background:lime" | OK<br />
<br />
|}<br />
<br />
| valign="top"|<br />
<br />
'''CPUs'''<br />
<br />
{| border="0" style="font-size: smaller"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Type<br />
! align="left" | CPU<br />
! align="left" | Status<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| Geode LX<br />
| style="background:lime" | OK<br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| K8<br />
| style="background:orange" | WIP<br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| Generic<br />
| i586<br />
| style="background:orange" | WIP<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel<br />
| Core Duo / Core 2 Duo<br />
| style="background:orange" | WIP<br />
<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| C7<br />
| style="background:orange" | WIP<br />
<br />
|}<br />
<br />
|}<br />
<br />
<small><br />
<sup>1</sup> MCP55 and CK804 are supported, but no open documents are available from NVIDIA.<br />
</small><br />
<br />
== Devices supported in coreboot v1 ==<br />
<br />
Not all devices have been ported from coreboot v1 to coreboot v4, yet (check "v4?" field). If you want to work on such a port contact us on the [[Mailinglist|mailing list]].<br />
<br />
{| border="0" valign="top"<br />
| valign="top"|<br />
<br />
'''Northbridges'''<br />
<br />
{| border="0" style="font-size: smaller" valign="top"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | Northbridge<br />
! align="left" | Status<br />
! align="left" | v4?<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Acer<br />
| M1631<br />
| style="background:#eeeeee" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| Alpha<br />
| Tsunami<br />
| style="background:#dddddd" | ?<br />
| style="background:#dddddd" | &mdash;<sup>3</sup><br />
|- bgcolor="#eeeeee" valign="top"<br />
| AMD<br />
| AMD76x<br />
| style="background:#eeeeee" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 430TX<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 440BX<br />
| style="background:#dddddd" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 440GX<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 82815EP<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 82830<br />
| style="background:#dddddd" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| 82860<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| E7500<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| E7501<br />
| style="background:#dddddd" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#dddddd" valign="top"<br />
| Intel&reg;<br />
| E7505<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Micron<br />
| 21PAD<br />
| style="background:#eeeeee" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| Motorola<br />
| MPC107<br />
| style="background:#dddddd" | ?<br />
| style="background:#dddddd" | &mdash;<sup>3</sup><br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC/AMD<br />
| GX1<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| VT694<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| VT8601<br />
| style="background:#dddddd" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| VT8623<br />
| style="background:#dddddd" | ?<br />
| style="background:lime" | Yes<br />
|}<br />
<br />
| valign="top"|<br />
<br />
'''Southbridges'''<br />
<br />
{| border="0" style="font-size: smaller" valign="top"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | Southbridge<br />
! align="left" | Status<br />
! align="left" | v4?<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Acer<br />
| M1535<br />
| style="background:#eeeeee" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Acer<br />
| M1543<br />
| style="background:#eeeeee" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| AMD<br />
| AMD766<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| AMD<br />
| AMD768<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 82801<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 82801CA<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 82801DB<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| 82870<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Intel&reg;<br />
| PIIX4E<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#dddddd" valign="top"<br />
| NSC/AMD<br />
| CS5530<br />
| style="background:#dddddd" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#dddddd" valign="top"<br />
| NSC<br />
| SCX200<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#eeeeee" valign="top"<br />
| VIA<br />
| VT8231<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| VIA<br />
| VT8235<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| VIA<br />
| VT82C686<br />
| style="background:#eeeeee" | ?<br />
| style="background:yellow" | WIP<sup>2</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| Winbond&trade;<br />
| W83C553<br />
| style="background:#dddddd" | ?<br />
| style="background:#dddddd" | &mdash;<sup>3</sup><br />
|}<br />
<br />
| valign="top"|<br />
<br />
'''Super I/Os'''<br />
<br />
{| border="0" style="font-size: smaller" valign="top"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | Super&nbsp;I/O<br />
! align="left" | Status<br />
! align="left" | v4?<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Acer<br />
| M1535<br />
| style="background:#eeeeee" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| ITE<br />
| IT8671F<br />
| style="background:#dddddd" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| PC87309<br />
| style="background:lime" | OK<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| PC87351<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| PC97307<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| PC97317<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#dddddd" valign="top"<br />
| SiS<br />
| 950<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#eeeeee" valign="top"<br />
| SMC<br />
| FDC37B72X<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| SMC<br />
| FDC37B78X<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| SMC<br />
| FDC37B807<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| SMC<br />
| FDC37C669<br />
| style="background:#eeeeee" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#eeeeee" valign="top"<br />
| SMC<br />
| FDC37C67X<br />
| style="background:#eeeeee" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#eeeeee" valign="top"<br />
| SMC<br />
| FDC37N769<br />
| style="background:#eeeeee" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| VT1211<br />
| style="background:#dddddd" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| VT8231<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| VIA<br />
| VT82C686<br />
| style="background:#dddddd" | ?<br />
| style="background:yellow" | WIP<sup>2</sup><br />
|- bgcolor="#eeeeee" valign="top"<br />
| Winbond&trade;<br />
| W83627HF<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Winbond&trade;<br />
| W83877TF<br />
| style="background:#eeeeee" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Winbond&trade;<br />
| W83977EF<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<sup>1</sup><br />
|}<br />
<br />
| valign="top"|<br />
<br />
'''North-/Southbridges'''<br />
<br />
{| border="0" style="font-size: smaller" valign="top"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Vendor<br />
! align="left" | North/South<br />
! align="left" | Status<br />
! align="left" | v4?<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| NSC<br />
| SCX200<br />
| style="background:#eeeeee" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| SiS<br />
| 540<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| SiS<br />
| 550<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| SiS<br />
| 630<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| SiS<br />
| 635<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| SiS<br />
| 730<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#dddddd" valign="top"<br />
| SiS<br />
| 735<br />
| style="background:#dddddd" | ?<br />
| style="background:red" | No<br />
|- bgcolor="#eeeeee" valign="top"<br />
| ST<br />
| STPC<br />
| style="background:#eeeeee" | ?<br />
| style="background:red" | No<br />
|}<br />
<br />
'''CPUs'''<br />
<br />
{| border="0" style="font-size: smaller"<br />
|- bgcolor="#6699dd"<br />
! align="left" | Type<br />
! align="left" | CPU<br />
! align="left" | Status<br />
! align="left" | v4?<br />
<br />
|- bgcolor="#eeeeee" valign="top"<br />
| Alpha<br />
| EV6<br />
| style="background:#eeeeee" | ?<br />
| style="background:#eeeeee" | &mdash;<sup>3</sup><br />
|- bgcolor="#dddddd" valign="top"<br />
| PowerPC<br />
| ?<br />
| style="background:#dddddd" | ?<br />
| style="background:#dddddd" | &mdash;<sup>3</sup><br />
|- bgcolor="#eeeeee" valign="top"<br />
| x86<br />
| AMD<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| x86<br />
| Intel&reg;<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|- bgcolor="#eeeeee" valign="top"<br />
| x86<br />
| VIA<br />
| style="background:#eeeeee" | ?<br />
| style="background:lime" | Yes<br />
|}<br />
<br />
|}<br />
<br />
<small><br />
<sup>1</sup> The W83977EF works fine with the W83977TF code in coreboot v4 (the pre-RAM serial part at least).<br /><br />
<sup>2</sup> Pre-RAM serial output works in coreboot v4, but the rest is not supported, yet.<br /><br />
<sup>3</sup> Will not be ported anytime soon, we focus on x86 in coreboot v4.<br /><br />
</small><br />
<br />
__FORCETOC__</div>Vikramhttps://www.coreboot.org/index.php?title=Developer_Manual&diff=10962Developer Manual2011-12-26T10:13:43Z<p>Vikram: /* View From The CPU: Intel Architecture */</p>
<hr />
<div></div>Vikramhttps://www.coreboot.org/index.php?title=Git&diff=10961Git2011-12-25T19:36:58Z<p>Vikram: /* Evolving patches */</p>
<hr />
<div>= Gerrit =<br />
As part of our move to [https://code.google.com/p/gerrit/ gerrit], [http://gitscm.com/ git] was introduced as primary SCM.<br />
<br />
== Register with gerrit ==<br />
For authenticated access (to submit patches) you'll need a gerrit account which you can register at http://review.coreboot.org/.<br />
You also need to add your ssh key(s) (used for authenticating your connections to the repo) and your email address(es) (used to match up Signed-off-by: statements) to your gerrit user data at http://review.coreboot.org/#settings.<br />
<br />
=== OpenID ===<br />
It seems that gerrit is picky about the OpenID format. Always provide a full URL, including protocol (ie. http:// or https:// prefix). Unfortunately the error messages are non-intuitive (but will improve in the future)<br />
<br />
== Gerrit workflow ==<br />
Gerrit interprets each Git commit as an individual change. Changes are autobuilt by [http://jenkins-ci.org/ Jenkins], and can be reviewed by developers. Once a change has gotten a positive review and has no build issues, it is applied to the master branch. Thus, no developer directly pushes to master.<br />
<br />
Reviews grant points on a scale from -2 to 2. The meaning is:<br />
* -2: Do not merge (blocks gerrit from merging)<br />
* -1: I'd prefer you don't merge it<br />
* 0: neutral<br />
* +1: Looks good, but I won't make the last call on it<br />
* +2: Looks good, go ahead and merge (gerrit provides a "submit" function once it has a +2 vote)<br />
<br />
-2 and +2 are only available to core developers as it's comparable to commit rights in SVN.<br />
<br />
=== Gerrit and CLI ===<br />
Reviews normally happens through the website.<br />
<br />
Since gerrit exposes an interface through its ssh daemon, it's also possible to do reviews from CLI or mail. Unfortunately there doesn't seem to be any standing tradition on how to build a workflow around these parts, so we'll document our best practices here once they settled.<br />
<br />
=== Gerrit and Email ===<br />
Gerrit has poor email integration (in fact, it doesn't really have any at all). We send a couple of notifications to the mailing list, but that is a coreboot specific extension. Peter intends to build a mail-to-gerrit gateway should the need arise.<br />
<br />
This gateway will provide:<br />
* no patch submission mechanism ("git push" is CLI friendly)<br />
* patch review (maybe openpgp signed "Acked-by" mails)<br />
* patch submission (automatically with Acked-by?)<br />
* maybe patch rejection? (openpgp signed "Nacked-by" mails)<br />
<br />
= Accessing the repository =<br />
The repository can be accessed using ssh (with public key authentication) or http (anonymous read-only or read-write using user/password authentication). The latter is particularily interesting for people behind firewalls, but requires git to be version 1.6.6 or newer (for "Smart HTTP" transfer). The http password can be generated (and regenerated if necessary) at http://review.coreboot.org/#settings,http-password.<br />
<br />
git clone ssh://<username>@review.coreboot.org:29418/coreboot<br />
<br />
git clone <nowiki>http://[<username>:<password>@]review.coreboot.org/p/coreboot.git</nowiki><br />
<br />
Inside the checkout you should install the commit-msg hook which prepares commit messages to fit the style required by gerrit. This needs to happen only once per clone and can be done with<br />
<br />
wget -O .git/hooks/commit-msg <nowiki>http://review.coreboot.org/tools/hooks/commit-msg</nowiki> && \<br />
chmod +x .git/hooks/commit-msg<br />
<br />
Alternatively, you could also just run<br />
<br />
make gitconfig<br />
<br />
= Working with Git =<br />
<br />
Git is a distributed version control system. This means that you can manage commits and branches completely without restriction in your local clone of the coreboot repository. Peter wrote [http://www.coreboot.org/pipermail/coreboot/2011-June/065427.html a Git introduction] after the switch to Git had been announced on the mailing list.<br />
<br />
== Commit messages ==<br />
Git does not enforce a commit message style, although perhaps it should. For all aspects of Git to work the best, it's important to follow these simple guidelines for commit messages:<br />
<br />
# The first line of the commit message has a short (less than 65 characters, absolute maximum is 75) summary<br />
# The second line is empty (no whitespace at all)<br />
# The third and any number of following lines contain a longer description of the commit as is neccessary, including relevant background information and quite possibly rationale for why the issue was solved in this particular way. These lines should never be longer than 75 characters.<br />
# The next line is empty (no whitespace at all)<br />
# A Change-Id: line to let gerrit track this logical change<br />
# A Signed-off-by: line according to [[Development_Guidelines#Sign-off_Procedure|the development guidelines]]<br />
<br />
Please do not create Change-Id: and Signed-off-by: manually because it is boring and error-prone. Instead, please install the commit-msg hook as described [[#Accessing_the_repository|above]], and remember to always use '''git commit -s''' to have git add your Signed-off-by: automatically.<br />
<br />
Here is an example of a well-formatted commit message:<br />
examplecomponent: Refactor duplicated setup into a function<br />
<br />
Setting up the demo device correctly requires the exact same register<br />
values to be written into each of the PCI device functions. Moving the<br />
writes into a function allows also otherexamplecomponent to use them.<br />
<br />
Signed-off-by: Joe Hacker <joe@hacker.email><br />
<br />
The example is missing a Change-Id: line. This is OK because Joe Hacker has set up the commit-msg hook [[#Authenticated_read/write_access|as mentioned above]], which adds a Change-Id: automatically when the commit message is saved.<br />
<br />
=== Guidelines on commit message content ===<br />
<br />
* If anyone involved in coreboot reads your comment in a year, she/he shall still be able to understand what your commit is about, without analyzing the code.<br />
* Double-check that you're really committing what you think you are, e.g. by typing the following in the top-level coreboot directory:<br />
git show<br />
<br />
== Pushing changes ==<br />
First ensure that the git remote you want to use for pushing refers to an ssh:// URL (see [[Git#Authenticated read/write access|Authenticated read/write access]] above). If you need to change this after the fact, ie. if you registered on gerrit only after having cloned anonymously, you can. Assuming that your remote is called ''origin'' (this is the default) you can run:<br />
<br />
git config remote.origin.url ssh://<username>@review.coreboot.org:29418/coreboot<br />
<br />
Then run the following command once, to tell git that by default you want to submit all commits in the currently checked-out branch for review on gerrit:<br />
<br />
git config remote.origin.push HEAD:refs/for/master<br />
<br />
After this, the command to push your changes is:<br />
<br />
git push origin<br />
<br />
If you always push from the same or a few branches the workflow can be simplified further by running once for each branch:<br />
<br />
git config branch.<particularbranchname>.remote origin<br />
<br />
...after which you then push changes with any of the configured branches checked out with a simple:<br />
<br />
git push<br />
<br />
Pushing several commits not yet in the coreboot repository at once will create one review request on gerrit per commit. <br />
<br />
'''NB!''' If you have applied patches from gerrit on a branch and you later push that branch, gerrit will think that you are submitting new versions of the patches that you had applied. This may or may not be what you intend. You can always run<br />
<br />
git log origin/master..<br />
<br />
before '''git push''' to verify which commits you are about to send for review.<br />
<br />
For automating patch submission further (ie. more ways of simplifying the command line), see the last paragraph of [http://review.coreboot.org/Documentation/user-upload.html#push_create this gerrit documentation].<br />
<br />
== Evolving patches ==<br />
<br />
Often it might happen that the patch you sent for approval is not good enough from the first attempt. Gerrit and git make it easy to track patch evolution during the review process until patches meet our quality standards and are ready for approval.<br />
<br />
You can easily modify a patch sent to gerrit by you or even by someone else. Just apply it locally using one of the possible ways to do it, make a new local commit that fixes the issues reported by the reviewers, then rebase the change by preserving the same Change-ID. We recommend you to use the git rebase command in interactive mode, <br />
<br />
git rebase -i master<br />
<br />
then commit and push the updated patch.<br />
<br />
== Further Git reading ==<br />
There are tons of git tutorials out there. Take a look at some of these documents:<br />
* http://git-scm.com/<br />
* http://www.kernel.org/pub/software/scm/git/docs/v1.7.5.4/gittutorial.html<br />
* http://git.or.cz/course/svn.html<br />
* and in particular the [http://progit.org/ Pro Git book]<br />
<br />
Please also feel free to ask Git questions in the [[IRC|coreboot IRC channel]] or on the [[Mailinglist|mailing list]].<br />
<br />
= Browsing =<br />
<br />
See http://review.coreboot.org/gitweb?p=coreboot.git</div>Vikramhttps://www.coreboot.org/index.php?title=IRC&diff=10762IRC2011-05-19T14:20:43Z<p>Vikram: Changed the URL to directly goto IRC channel</p>
<hr />
<div>Some of the coreboot developers and users hang out in the channel on [http://webchat.freenode.net/?channels=coreboot #coreboot] and [http://webchat.freenode.net/?channels=flashrom #flashrom]. <br />
<br />
Here you have the chance to talk to people being involved or interested in this project. Most of the discussion is tech talk. Questions on coreboot, OpenBIOS, firmware and related topics are welcome in '''#coreboot'''. Questions on [[flashrom]] are welcome in '''#flashrom'''.<br />
<br />
Most people are in CET timezone, so don't give up when the channels seem very quiet for some time.</div>Vikramhttps://www.coreboot.org/index.php?title=Developer_Manual&diff=10748Developer Manual2011-05-13T19:39:45Z<p>Vikram: Fixed the location of files mentioned.</p>
<hr />
<div></div>Vikram