''They are very fast moving. The European Brown Hare (Lepus europaeus) can run at speeds of up to 72 km/h (45 mph).'' --[http://en.wikipedia.org/wiki/Hare Wikipedia]

== coreboot Logo License ==

The logo for the coreboot project is released under the following license.

:Copyright © 2008 Konsult Stuge
:Copyright © 2008 coresystems GmbH

:This logo or a modified version may be used by anyone to refer to the coreboot project, but does not indicate endorsement by the project.

In particular, we encourage you to use the logo for the purpose of advertising support for coreboot. This includes, but is not limited to, the following uses:

* computer systems that come preloaded with coreboot and such that support coreboot through a flash upgrade.
* enhancements and projects related to coreboot such as payloads, coreboot ports to new systems and utilities that are to be used in systems also using coreboot
* coreboot documentation
* posters, clothing, presentations and other promotion material referring to the coreboot project

Please make the image a link to http://www.coreboot.org/ if you use it on a web page.

== Graphical usage guidelines ==

The logo is in sharp contrast with the background. The normal appearance is black on white. When the logo must be used on dark background, a white or bright area surrounds it, or it is inverted to white on black instead of the normal black on white.

== Logo kit archive ==

[[Media:Coreboot_logo_kit.zip|Coreboot_logo_kit.zip]] contains all files on this page in a convenient archive.

== Individual files ==

You can also download individual files that suit your usage.

=== Full logo with name ===

[[Image:Coreboot_full_web.png]]

Download [[Media:Coreboot_full.svg|SVG]], [[Media:Coreboot_full_highres.png|high-resolution PNG]] or [[Media:Coreboot_full_web.png|low-resolution PNG]].

=== Logo without name ===

[[Image:Coreboot_hare_web.png]]

Download [[Media:Coreboot_hare.svg|SVG]], [[Media:Coreboot_hare_highres.png|high-resolution PNG]] or [[Media:Coreboot_hare_web.png|low-resolution PNG]] or [[Media:coreboot64px.png|64px icon]].

=== Name only ===

[[Image:Coreboot_name_web.png]]

Download [[Media:Coreboot_name.svg|SVG]], [[Media:Coreboot_name_highres.png|high-resolution PNG]] or [[Media:Coreboot_name_web.png|low-resolution PNG]].

=== Page footer with stripe and name ===

[[Image:Coreboot_footer_web.png]]

Download [[Media:Coreboot_footer.svg|SVG]], [[Media:Coreboot_footer_highres.png|high-resolution PNG]] or [[Media:Coreboot_footer_web.png|low-resolution PNG]].

=== Combination logo with name and thick stripe ===

[[Image:Coreboot_combo_web.png]]

Download [[Media:Coreboot_combo.svg|SVG]], [[Media:Coreboot_combo_highres.png|high-resolution PNG]] or [[Media:Coreboot_combo_web.png|low-resolution PNG]].

== Credits ==

Image and typography was created by [http://www.breakfastdesign.nu/ Breakfast Design]. Post design work was done by [http://spookypanda.se/ Spooky Panda]. The coreboot logo was sponsored by:

* [http://stuge.se/ Konsult Stuge]
* [http://www.coresystems.de/ coresystems GmbH]
* [http://kwlug.org/ Kitchener Waterloo Linux User Group] and Richard Weait

2013-03-15T20:38:02Z

PatrickGeorgi: /* Infrastructure for automatic code checking */

The following are some ideas that have come up in the community. Some are more or less suitable for GSoC and prospective students' application should expand on some ideas and pair back others.

== Linux Firmware Kit, BITS ==

There are various test suites for firmware aspects, esp. those that interacts with the operating systems. Unfortunately, some of these projects are dead, some seem to be forked and developed semi-publically, and having all that stuff in lots of different places is a big hassle.

The goal of this project is to pick up the pieces, and create a single tool (most likely a bootable CD/USB drive image) that can be booted on vendor BIOS (for the Red Hat and Canonical developers that work on these) as well as coreboot (preferably seabios and FILO to improve testability - is an issue created/fixed by coreboot or seabios?). This can then be improved in various ways.

There's also intel-gpu-tools that might have some useful tests (at least for intel-boards): http://article.gmane.org/gmane.comp.video.dri.devel/63948

When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.

Required knowledge for this task: Not so much coreboot/firmware level, but you should have some idea of the boot process of a Linux system (as these test suites are mostly Linux based). GSoC probably won't provide enough time to learn all that (Linux boot process, firmware interfaces such as ACPI) and still develop the tools in some useful way.

Further reading: https://wiki.ubuntu.com/Kernel/Reference/fwts http://biosbits.org/ http://linuxfirmwarekit.org/

== Infrastructure for automatic code checking ==
We already have a build bot that builds various configurations of coreboot. It would be nice to extend it with various code validation routines, for example:
* Validate that there's no regression in doxygen documentation (eg. are all arguments to functions still explained in @param tags, eg. after new arguments were added?)
* Make code lint clean (and maybe extend lint to not fall into our traps), and run lint over the tree. Report regressions
* Use LLVM's static code checking facilities, report regressions.
* Work on code coverage support for coreboot code (dump data into ram, or via serial. Provide tools to fetch it). Analyse that data.

'''Links'''
* LLVM tools: [http://clang.llvm.org/StaticAnalysis.html Clang static analyser], [http://llvm.org/ProjectsWithLLVM/#Calysto SSA assertion checker], http://klee.llvm.org/
* Lint tools: [http://lclint.cs.virginia.edu/ Splint]
* Coverage: [http://ltp.sourceforge.net/test/coverage/lcov.php LCOV], [http://ggcov.sourceforge.net GGCOV]
* Semantic Tester: https://code.google.com/p/c-semantics/
* [http://frama-c.com/ Frama-C]

'''Mentors'''
* [[User:Stepan|Stefan Reinauer]], [[User:PatrickGeorgi|Patrick Georgi]]

== coreboot test suite ==
Create a test suite to gather and report coreboot mainboard and payload settings. This project may leverage libpayload, coreinfo, memtest86, BITS, and other tools like benchmarks for CPU and RAM performance. Konstantin Aladyshev reported according to the benchmark [http://www.cs.virginia.edu/stream/ STREAM], RAM access on his system with coreboot is four times slower than with the proprietary vendor BIOS. Such issues should be easily spotted with the test suite.

The suite should gather result and report them at summary and detailed levels. The goal is to help coreboot developers identify problems and to test coreboot features. This project should work closely with the testing rig and test reporting projects. It is important the the student considers how testing and reporting can be extended as features and tests are added in the future.

'''Links'''
* [http://biosbits.org/ BITS]
* [[Supported Motherboards]]

'''Mentors'''
* [[User:MJones|Marc Jones]], [[User:PatrickGeorgi|Patrick Georgi]]

== coreboot cheap testing rig ==
The goal of this project is to create a cheap testing rig which works with the existing board test infrastructure. We have a hardware test system since 2006:
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/Slides-LinuxBIOS-QA.pdf Quality Assurance Talk (Slides)]
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestIntegrationManual.pdf Test Integration Manual]
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/DevelopersManual.pdf Test Developers Manual]
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestSpecification.pdf Test Specification]

The initial version of our testing rig used a remote power switch and was rather expensive. With cheaper technologies such as X10, it's possible to drop the testing costs per board significantly.

'''Links'''
* http://qa.coresystems.de
* [[InSystemFlasher]] is a cheap DIY hardware prototype for building an automated testing rig for modern SPI-based boards. This could be used as a starting point.

'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]

== coreboot mainboard test result reporting ==
One of the biggest challenges in coreboot is support many systems in the same codebase. As systems age and coreboot continues to develop, the condition of mainboards becomes unknown. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. This project would work closely with the coreboot test suite project and/or the hardware test rig project. A good example of test results gathering and reporting is done by the Phoronix/Openbenchmark. The student should investigate other test and reporting solutions to leverage the best options for coreboot. It is important the the student considers how testing and reporting can be extended as features and tests are added in the future.

'''Links'''
* http://openbenchmarking.org/
* http://www.coreboot.org/Supported_Motherboards

'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]
* [[User:MJones|Marc Jones]]

== coreboot ports for Family14 mainboards ==
Identify potential mainboards to port based on the recently released AMD Family 14 support. The goal would be to support publicly available plaftorms with a number of payloads and operating systems.

'''Mentors'''
*[[User:Jason Wang|QingPei Wang]]

== coreboot ACPI/S3/power managment ==
coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific. Create a generic solution for ACPI table generation and S3 support.

'''Mentors'''
*

==coreboot port to ARM SOC's with PCIe==

[http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm Xilinx Zynq-7030]

[http://www.altera.com/devices/fpga/cyclone-v-fpgas/hard-processor-system/cyv-soc-hps.html Altera Cyclone V ]

[http://www.st.com/internet/mcu/product/251211.jsp ST spear1340]

[[ARM]] SOC's with PCIe are available. These systems can take advantage of coreboot's strength in properly configuring PCI devices, fast boot time and payload support.

Note that coreboot has in the past supported three different CPUs (x86, Alpha, PPC), so the structure is there for adding in a new processor family.
We will need to find the right platform to do the work, but I (Ron) can provide a board and JTAG debugger if needed.

There was an ARM project started in 2011.

http://blogs.coreboot.org/blog/2011/05/11/gsoc2011-project-porting-coreboot-to-arm-architecture/

'''Mentors'''
* Bari Ari
* [[User:Rminnich|Ron Minnich]]
* [[User:Jason Wang|QingPei Wang]]

== coreboot panic room ==

Create a safe boot solution for coreboot to easily and cheaply recover the system in case of a panic().

Ron would like to base this solution around SerialICE. The basic idea is that the system always boots to SerialICE. There is a test in CMOS for 'last boot worked' and, if this is set, SerialICE finds a coreboot in cbfs and runs it. If 'last boot worked' is not set, or the user hits some magic keyboard sequence, SerialICE takes control.

SerialICE needs to be extended (not much) to make this work. Having this capability would make it possible for Ron to get some very hard ports working that are just not possible today. At the same time, there are lots of hardware boards to test this idea on, so it should be easy to get it working.

It might be possible to integrate this into the coreboot build as a bootblock option (in the same spot as the fallback/normal switch and the simple loader).

There was a panic room project started in 2011
http://blogs.coreboot.org/blog/2011/05/09/gsoc-project-coreboot-panic-room-diagnostics-also-remote-flashing/

'''Mentors'''
* [[User:Rminnich|Ron Minnich]]

== Board config infrastructure ==

Design data structures that host information about the board layout so coreboot can better initialize components and generate all kinds of tables (mptable, pirq, acpi, ...) from that dynamically (at build or runtime, as appropriate). Adapt boards to use that instead of the current hardcodes.

'''Links'''
* ?

'''Mentors'''
* ?

== Refactor AMD code ==

AMD K8 and AMD Fam10 are different enough to have their own code. This is unfortunate, as you have to decide which CPU type you use in a given mainboard. Refactor AMD code so a single image can support both chip types on a given board. Also move tables from get_bus_conf and the like to the device tree or kconfig options (or runtime detection), as appropriate.

'''Links'''
* ?

'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]

GSoC

2013-03-15T20:36:38Z

PatrickGeorgi:

__FORCETOC__

= Google Summer of Code 2013 =

Welcome to the coreboot's [http://www.google-melange.com/gsoc/homepage/google/gsoc2013 Google Summer of Code 2013] page.

We are preparing to apply for GSoC 2013. Please continue to add your ideas to the [[Project Ideas|projects page]].

If you have questions, comments, or concerns, please send them to the [[Mailinglist|mailing list]] or join us in [[IRC]].

The coreboot project may also host payload and [http://flashrom.org/GSoC flashrom] projects.
 

[[Previous GSoC Projects|Previous coreboot GSoC projects]]

= Call for Mentors and Project Ideas =
Google has announced the 2013 GSoC program. coreboot had been a GSoC participant in the past, but was not accepted in 2012 and we would like to change that this year. The GSoC project acceptance has become much more competitive and the project ideas and student recruitment pages has become key in getting accepted. Our project ideas were not flushed out enough in the application process and we didn't have a complete mentors list/assignment for those projects.

I think that coreboot has some extremely talented people involved in the project and students should be attracted to the experience of working with our mentors as much as the potential projects.

What we need to apply for GSoC 2013:

Project Admins - We need a person or two to be the main liaison between coreboot and GSoC. This person(s) register the project, fills out the application, leads and organizes the projects and mentors.

Mentors - We need a pool of mentors willing to support students on a number of levels; Helping them from the very beginning with project ideas and writing their applications, project and development time management, research, communication, documentation, drive deadlines.

Mentor biographies - To improve out GSoC recruitment, i would like to have a one paragraph biography for each of our mentors. It should contain what your coreboot experience and contributions. Something about your work and/or education experience and maybe some other personal information. Maybe where you are located. It helps to have mentors can be matched with the students culture.

Project ideas - We also need complete project ideas with pointers to background data and what the expected outcome would be. We need a list of potential mentors for each project idea.

coreboot GSoC support roles - Even if you can't commit to being a full time mentor, we could use your help with the coreboot promotion, student recruitment, wiki, project ideas, blog postings, and code reviews , and encouragement and advice to students and mentors.

Important dates:
March18 - 29 - Org applications. We should have a list of mentors and suitable project ideas, policies, etc by this date.
April 1 - 5- GSoC application review
April 8 - Org acceptance
April 22 - May 5 - student applications

If you are interested in helping, please feel free to contact me and/or start updating the wiki and add yourself and/or project ideas.

= People involved =

{| class="wikitable"
|-
! Name !! Role !! Comms
|-
| David Hendricks || flashrom: possible mentor || IRC: dhendrix, [http://www.flashrom.org/mailman/listinfo/flashrom flashrom ML]
|-
| Stefan Tauner || flashrom: organizer/possible mentor/wannabe student || IRC: stefanct, [http://www.flashrom.org/mailman/listinfo/flashrom flashrom ML]
|-
| Patrick Georgi || coreboot: possible co-organizer, possible co-mentor ("co-" since on vacation during GSoC period) || IRC: patrickg, pgeorgi
|-
| Marc Jones || coreboot: co-organizer and mentor || IRC: marcj
|-
| Kyösti Mälkki || serialice: wannabe student || IRC: kmalkki, [http://www.serialice.com/mailman/listinfo/serialice SerialICE ML]
|-
|}

Infrastructure Projects

2013-03-15T09:56:33Z

PatrickGeorgi: /* Finished */ fix link

Infrastructure Projects

2013-03-15T09:56:06Z

PatrickGeorgi: move finished infrastructure projects to their own page

Infrastructure Projects/Done

2013-03-15T09:55:56Z

PatrickGeorgi: move finished infrastructure projects on their own page

== Port v3 Resource Allocator ==

The v3 resource allocator should be ported to v4.

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

'''Developers:''' Myles

== Config & Build System ==

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

'''Status:''' Upstream, boards are converted. Old system is gone. All boards build. HOWEVER, not all boards have been boot-tested yet, please report any issues you encounter!

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

== Unify text printing functions ==

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

'''Status:''' Finished.

'''Developers:''' Patrick, Stefan

== Common payload location ==

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

'''Status:''' Finished.

== Fix ALL build warnings ==

* Someone has to do the deed.

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

== Post codes ==

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

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

== Use central oprom init ==

* Get rid of all vgabios.c, make all chipsets with own vgabios.c use devices/oprom/x86.c.
* Use the realmode code for vsmsetup too.

== Use nvramtool for static option table creation ==

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.

'''Status:''' Finished, upstream.

'''Developers:''' Vikram

== Local APIC addresses ==

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

* LAPIC_ADDR
* LOCAL_APIC_ADDR (even twice)
* LAPIC_DEFAULT_BASE

This should be unified.

'''Developers:''' Patrick

== printk into buffer ==

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

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

'''Developers:''' ChromiumOS Team

== USB Debug Console ==

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

'''Developers:''' SvenS

== CBFS ==

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

'''Status:'''

Upstream, pre-CBFS infrastructure removed.

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

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

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

{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
! align="left" | Vendor/chipset
! align="left" | ROM enabled
! align="left" | Tiny bootblock
! align="left" | Status / Comments

|- bgcolor="#eeeeee"
| amd/amd8111
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.
|- bgcolor="#eeeeee"
| amd/cs5530
| style="background:lime" | Y
| style="background:red" | N
| Not tested on hardware, yet.
|- bgcolor="#eeeeee"
| amd/cs5535
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| amd/cs5536
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| amd/sb600
| style="background:lime" | Y
| style="background:lime" | Y
| Build- and runtime-tested on siemens/sitemp_g1p1 by [[User:PatrickGeorgi|PatrickGeorgi]].
|- bgcolor="#eeeeee"
| amd/sb700
| style="background:yellow" | Y
| style="background:yellow" | Y
| —

|- bgcolor="#dddddd"
| broadcom/bcm5785
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#eeeeee"
| intel/esb6300
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i3100
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82371eb
| style="background:lime" | Y
| style="background:yellow" | Y
| Build- and runtime-tested on ASUS P2B by [[User:Uwe|Uwe Hermann]].
|- bgcolor="#eeeeee"
| intel/i82801ax
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801bx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801cx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801dx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801ex
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801gx
| style="background:lime" | Y
| style="background:lime" | Y
| Build- and runtime-tested on Kontron 986LCD-m by PatrickGeorgi

|- bgcolor="#dddddd"
| nvidia/ck804
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.
|- bgcolor="#dddddd"
| nvidia/mcp55
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#dddddd"
| sis/sis966
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#eeeeee"
| via/vt8231
| style="background:yellow" | Y
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| via/vt8235
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| via/vt8237r
| style="background:yellow" | Y
| style="background:yellow" | Y
| —
|- bgcolor="#eeeeee"
| via/vt82c686
| style="background:red" | N
| style="background:red" | N
| —

|}

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

== Tiny Bootblock ==

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

'''Status:''' Available in Kconfig, works on a couple of boards. Requires per southbridge changes (and northbridge in some cases) on many boards (related to ROM enable, see CBFS section).

'''Developers:''' Patrick

GSoC

2013-03-14T12:29:21Z

PatrickGeorgi: /* People involved */

__FORCETOC__

= Google Summer of Code 2013 =

Welcome to the coreboot's [http://www.google-melange.com/gsoc/homepage/google/gsoc2013 Google Summer of Code 2013] page.

We are preparing to apply for GSoC 2013. Please continue to add you ideas to the [[Project Ideas|projects page]].

If you have questions, comments, or concerns, please send them to the [[Mailinglist|mailing list]] or join us in [[IRC]].

The coreboot project may also host payload and [http://flashrom.org/GSoC flashrom] projects.
 

[[Previous GSoC Projects|Previous coreboot GSoC projects]]

= Call for Mentors and Project Ideas =
Google has announced the 2013 GSoC program. coreboot had been a GSoC participant in the past, but was not accepted in 2012 and we would like to change that this year. The GSoC project acceptance has become much more competitive and the project ideas and student recruitment pages has become key in getting accepted. Our project ideas were not flushed out enough in the application process and we didn't have a complete mentors list/assignment for those projects.

I think that coreboot has some extremely talented people involved in the project and students should be attracted to the experience of working with our mentors as much as the potential projects.

What we need to apply for GSoC 2013:

Project Admins - We need a person or two to be the main liaison between coreboot and GSoC. This person(s) register the project, fills out the application, leads and organizes the projects and mentors.

Mentors - We need a pool of mentors willing to support students on a number of levels; Helping them from the very beginning with project ideas and writing their applications, project and development time management, research, communication, documentation, drive deadlines.

Mentor biographies - To improve out GSoC recruitment, i would like to have a one paragraph biography for each of our mentors. It should contain what your coreboot experience and contributions. Something about your work and/or education experience and maybe some other personal information. Maybe where you are located. It helps to have mentors can be matched with the students culture.

Project ideas - We also need complete project ideas with pointers to background data and what the expected outcome would be. We need a list of potential mentors for each project idea.

coreboot GSoC support roles - Even if you can't commit to being a full time mentor, we could use your help with the coreboot promotion, student recruitment, wiki, project ideas, blog postings, and code reviews , and encouragement and advice to students and mentors.

Important dates:
March18 - 29 - Org applications. We should have a list of mentors and suitable project ideas, policies, etc by this date.
April 1 - 5- GSoC application review
April 8 - Org acceptance
April 22 - May 5 - student applications

If you are interested in helping, please feel free to contact me and/or start updating the wiki and add yourself and/or project ideas.

= People involved =

{| class="wikitable"
|-
! Name !! Role !! Comms
|-
| David Hendricks || flashrom: possible mentor || IRC: dhendrix, [http://www.flashrom.org/mailman/listinfo/flashrom flashrom ML]
|-
| Stefan Tauner || flashrom: organizer/possible mentor/wannabe student || IRC: stefanct, [http://www.flashrom.org/mailman/listinfo/flashrom flashrom ML]
|-
| Patrick Georgi || coreboot: possible co-organizer, possible co-mentor ("co-" since on vacation during GSoC period) || IRC: patrickg, pgeorgi
|-
|}

GSoC

2013-03-14T12:29:07Z

PatrickGeorgi: /* People involved */

__FORCETOC__

= Google Summer of Code 2013 =

Welcome to the coreboot's [http://www.google-melange.com/gsoc/homepage/google/gsoc2013 Google Summer of Code 2013] page.

We are preparing to apply for GSoC 2013. Please continue to add you ideas to the [[Project Ideas|projects page]].

If you have questions, comments, or concerns, please send them to the [[Mailinglist|mailing list]] or join us in [[IRC]].

The coreboot project may also host payload and [http://flashrom.org/GSoC flashrom] projects.
 

[[Previous GSoC Projects|Previous coreboot GSoC projects]]

= Call for Mentors and Project Ideas =
Google has announced the 2013 GSoC program. coreboot had been a GSoC participant in the past, but was not accepted in 2012 and we would like to change that this year. The GSoC project acceptance has become much more competitive and the project ideas and student recruitment pages has become key in getting accepted. Our project ideas were not flushed out enough in the application process and we didn't have a complete mentors list/assignment for those projects.

I think that coreboot has some extremely talented people involved in the project and students should be attracted to the experience of working with our mentors as much as the potential projects.

What we need to apply for GSoC 2013:

Project Admins - We need a person or two to be the main liaison between coreboot and GSoC. This person(s) register the project, fills out the application, leads and organizes the projects and mentors.

Mentors - We need a pool of mentors willing to support students on a number of levels; Helping them from the very beginning with project ideas and writing their applications, project and development time management, research, communication, documentation, drive deadlines.

Mentor biographies - To improve out GSoC recruitment, i would like to have a one paragraph biography for each of our mentors. It should contain what your coreboot experience and contributions. Something about your work and/or education experience and maybe some other personal information. Maybe where you are located. It helps to have mentors can be matched with the students culture.

Project ideas - We also need complete project ideas with pointers to background data and what the expected outcome would be. We need a list of potential mentors for each project idea.

coreboot GSoC support roles - Even if you can't commit to being a full time mentor, we could use your help with the coreboot promotion, student recruitment, wiki, project ideas, blog postings, and code reviews , and encouragement and advice to students and mentors.

Important dates:
March18 - 29 - Org applications. We should have a list of mentors and suitable project ideas, policies, etc by this date.
April 1 - 5- GSoC application review
April 8 - Org acceptance
April 22 - May 5 - student applications

If you are interested in helping, please feel free to contact me and/or start updating the wiki and add yourself and/or project ideas.

= People involved =

{| class="wikitable"
|-
! Name !! Role !! Comms
|-
| David Hendricks || flashrom: possible mentor || IRC: dhendrix, [http://www.flashrom.org/mailman/listinfo/flashrom flashrom ML]
|-
| Stefan Tauner || flashrom: organizer/possible mentor/wannabe student || IRC: stefanct, [http://www.flashrom.org/mailman/listinfo/flashrom flashrom ML]
|-
| Patrick Georgi || coreboot: possible co-organizer, possible co-mentor ("co-" since on vacation within GSoC period) || IRC: patrickg, pgeorgi
|-
|}

Project Ideas

2013-03-08T08:08:21Z

PatrickGeorgi: /* coreboot test suite */

The following are some ideas that have come up in the community. Some are more or less suitable for GSoC and prospective students' application should expand on some ideas and pair back others.

== Linux Firmware Kit, BITS ==

There are various test suites for firmware aspects, esp. those that interacts with the operating systems. Unfortunately, some of these projects are dead, some seem to be forked and developed semi-publically, and having all that stuff in lots of different places is a big hassle.

The goal of this project is to pick up the pieces, and create a single tool (most likely a bootable CD/USB drive image) that can be booted on vendor BIOS (for the Red Hat and Canonical developers that work on these) as well as coreboot (preferably seabios and FILO to improve testability - is an issue created/fixed by coreboot or seabios?). This can then be improved in various ways.

There's also intel-gpu-tools that might have some useful tests (at least for intel-boards): http://article.gmane.org/gmane.comp.video.dri.devel/63948

When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.

Required knowledge for this task: Not so much coreboot/firmware level, but you should have some idea of the boot process of a Linux system (as these test suites are mostly Linux based). GSoC probably won't provide enough time to learn all that (Linux boot process, firmware interfaces such as ACPI) and still develop the tools in some useful way.

Further reading: https://wiki.ubuntu.com/Kernel/Reference/fwts http://biosbits.org/ http://linuxfirmwarekit.org/

== Infrastructure for automatic code checking ==
We already have a build bot that builds various configurations of coreboot. It would be nice to extend it with various code validation routines, for example:
* Validate that there's no regression in doxygen documentation (eg. are all arguments to functions still explained in @param tags, eg. after new arguments were added?)
* Make code lint clean (and maybe extend lint to not fall into our traps), and run lint over the tree. Report regressions
* Use LLVM's static code checking facilities, report regressions.
* Work on code coverage support for coreboot code (dump data into ram, or via serial. Provide tools to fetch it). Analyse that data.

'''Links'''
* LLVM tools: [http://clang.llvm.org/StaticAnalysis.html Clang static analyser], [http://llvm.org/ProjectsWithLLVM/#Calysto SSA assertion checker], http://klee.llvm.org/
* Lint tools: [http://lclint.cs.virginia.edu/ Splint]
* Coverage: [http://ltp.sourceforge.net/test/coverage/lcov.php LCOV], [http://ggcov.sourceforge.net GGCOV]
* Semantic Tester: https://code.google.com/p/c-semantics/

'''Mentors'''
* [[User:Stepan|Stefan Reinauer]], [[User:PatrickGeorgi|Patrick Georgi]]

== coreboot test suite ==
Create a test suite to gather and report coreboot mainboard and payload settings. This project may leverage libpayload, coreinfo, memtest86, BITS, and other tools like benchmarks for CPU and RAM performance. Konstantin Aladyshev reported according to the benchmark [http://www.cs.virginia.edu/stream/ STREAM], RAM access on his system with coreboot is four times slower than with the proprietary vendor BIOS. Such issues should be easily spotted with the test suite.

The suite should gather result and report them at summary and detailed levels. The goal is to help coreboot developers identify problems and to test coreboot features. This project should work closely with the testing rig and test reporting projects. It is important the the student considers how testing and reporting can be extended as features and tests are added in the future.

'''Links'''
* [http://biosbits.org/ BITS]
* [[Supported Motherboards]]

'''Mentors'''
* [[User:MJones|Marc Jones]], [[User:PatrickGeorgi|Patrick Georgi]]

== coreboot cheap testing rig ==
The goal of this project is to create a cheap testing rig which works with the existing board test infrastructure. We have a hardware test system since 2006:
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/Slides-LinuxBIOS-QA.pdf Quality Assurance Talk (Slides)]
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestIntegrationManual.pdf Test Integration Manual]
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/DevelopersManual.pdf Test Developers Manual]
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestSpecification.pdf Test Specification]

The initial version of our testing rig used a remote power switch and was rather expensive. With cheaper technologies such as X10, it's possible to drop the testing costs per board significantly.

'''Links'''
* http://qa.coresystems.de
* [[InSystemFlasher]] is a cheap DIY hardware prototype for building an automated testing rig for modern SPI-based boards. This could be used as a starting point.

'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]

== coreboot mainboard test result reporting ==
One of the biggest challenges in coreboot is support many systems in the same codebase. As systems age and coreboot continues to develop, the condition of mainboards becomes unknown. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. This project would work closely with the coreboot test suite project and/or the hardware test rig project. A good example of test results gathering and reporting is done by the Phoronix/Openbenchmark. The student should investigate other test and reporting solutions to leverage the best options for coreboot. It is important the the student considers how testing and reporting can be extended as features and tests are added in the future.

'''Links'''
* http://openbenchmarking.org/
* http://www.coreboot.org/Supported_Motherboards

'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]
* [[User:MJones|Marc Jones]]

== coreboot ports for Family14 mainboards ==
Identify potential mainboards to port based on the recently released AMD Family 14 support. The goal would be to support publicly available plaftorms with a number of payloads and operating systems.

'''Mentors'''
*[[User:Jason Wang|QingPei Wang]]

== coreboot ACPI/S3/power managment ==
coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific. Create a generic solution for ACPI table generation and S3 support.

'''Mentors'''
*

==coreboot port to ARM SOC's with PCIe==

[http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm Xilinx Zynq-7030]

[http://www.altera.com/devices/fpga/cyclone-v-fpgas/hard-processor-system/cyv-soc-hps.html Altera Cyclone V ]

[http://www.st.com/internet/mcu/product/251211.jsp ST spear1340]

[[ARM]] SOC's with PCIe are available. These systems can take advantage of coreboot's strength in properly configuring PCI devices, fast boot time and payload support.

Note that coreboot has in the past supported three different CPUs (x86, Alpha, PPC), so the structure is there for adding in a new processor family.
We will need to find the right platform to do the work, but I (Ron) can provide a board and JTAG debugger if needed.

There was an ARM project started in 2011.

http://blogs.coreboot.org/blog/2011/05/11/gsoc2011-project-porting-coreboot-to-arm-architecture/

'''Mentors'''
* Bari Ari
* [[User:Rminnich|Ron Minnich]]
* [[User:Jason Wang|QingPei Wang]]

== coreboot panic room ==

Create a safe boot solution for coreboot to easily and cheaply recover the system in case of a panic().

Ron would like to base this solution around SerialICE. The basic idea is that the system always boots to SerialICE. There is a test in CMOS for 'last boot worked' and, if this is set, SerialICE finds a coreboot in cbfs and runs it. If 'last boot worked' is not set, or the user hits some magic keyboard sequence, SerialICE takes control.

SerialICE needs to be extended (not much) to make this work. Having this capability would make it possible for Ron to get some very hard ports working that are just not possible today. At the same time, there are lots of hardware boards to test this idea on, so it should be easy to get it working.

It might be possible to integrate this into the coreboot build as a bootblock option (in the same spot as the fallback/normal switch and the simple loader).

There was a panic room project started in 2011
http://blogs.coreboot.org/blog/2011/05/09/gsoc-project-coreboot-panic-room-diagnostics-also-remote-flashing/

'''Mentors'''
* [[User:Rminnich|Ron Minnich]]

== Board config infrastructure ==

Design data structures that host information about the board layout so coreboot can better initialize components and generate all kinds of tables (mptable, pirq, acpi, ...) from that dynamically (at build or runtime, as appropriate). Adapt boards to use that instead of the current hardcodes.

'''Links'''
* ?

'''Mentors'''
* ?

== Refactor AMD code ==

AMD K8 and AMD Fam10 are different enough to have their own code. This is unfortunate, as you have to decide which CPU type you use in a given mainboard. Refactor AMD code so a single image can support both chip types on a given board. Also move tables from get_bus_conf and the like to the device tree or kconfig options (or runtime detection), as appropriate.

'''Links'''
* ?

'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]

Project Ideas

2013-03-08T08:07:28Z

PatrickGeorgi: /* Infrastructure for automatic code checking */ more links to tools

The following are some ideas that have come up in the community. Some are more or less suitable for GSoC and prospective students' application should expand on some ideas and pair back others.

== Linux Firmware Kit, BITS ==

There are various test suites for firmware aspects, esp. those that interacts with the operating systems. Unfortunately, some of these projects are dead, some seem to be forked and developed semi-publically, and having all that stuff in lots of different places is a big hassle.

The goal of this project is to pick up the pieces, and create a single tool (most likely a bootable CD/USB drive image) that can be booted on vendor BIOS (for the Red Hat and Canonical developers that work on these) as well as coreboot (preferably seabios and FILO to improve testability - is an issue created/fixed by coreboot or seabios?). This can then be improved in various ways.

There's also intel-gpu-tools that might have some useful tests (at least for intel-boards): http://article.gmane.org/gmane.comp.video.dri.devel/63948

When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.

Required knowledge for this task: Not so much coreboot/firmware level, but you should have some idea of the boot process of a Linux system (as these test suites are mostly Linux based). GSoC probably won't provide enough time to learn all that (Linux boot process, firmware interfaces such as ACPI) and still develop the tools in some useful way.

Further reading: https://wiki.ubuntu.com/Kernel/Reference/fwts http://biosbits.org/ http://linuxfirmwarekit.org/

== Infrastructure for automatic code checking ==
We already have a build bot that builds various configurations of coreboot. It would be nice to extend it with various code validation routines, for example:
* Validate that there's no regression in doxygen documentation (eg. are all arguments to functions still explained in @param tags, eg. after new arguments were added?)
* Make code lint clean (and maybe extend lint to not fall into our traps), and run lint over the tree. Report regressions
* Use LLVM's static code checking facilities, report regressions.
* Work on code coverage support for coreboot code (dump data into ram, or via serial. Provide tools to fetch it). Analyse that data.

'''Links'''
* LLVM tools: [http://clang.llvm.org/StaticAnalysis.html Clang static analyser], [http://llvm.org/ProjectsWithLLVM/#Calysto SSA assertion checker], http://klee.llvm.org/
* Lint tools: [http://lclint.cs.virginia.edu/ Splint]
* Coverage: [http://ltp.sourceforge.net/test/coverage/lcov.php LCOV], [http://ggcov.sourceforge.net GGCOV]
* Semantic Tester: https://code.google.com/p/c-semantics/

'''Mentors'''
* [[User:Stepan|Stefan Reinauer]], [[User:PatrickGeorgi|Patrick Georgi]]

== coreboot test suite ==
Create a test suite to gather and report coreboot mainboard and payload settings. This project may leverage libpayload, coreinfo, memtest86, BITS, and other tools like benchmarks for CPU and RAM performance. The user Konstantin Aladyshev reported according to the benchmark [http://www.cs.virginia.edu/stream/ STREAM], RAM access on his system with coreboot is four times slower than with the proprietary vendor BIOS. Such issues should be easily spotted with the test suite.

The suite should gather result and report them at summary and detailed levels. The goal is to help coreboot developers identify problems and to test coreboot features. This project should work closely with the testing rig and test reporting projects. It is important the the student considers how testing and reporting can be extended as features and tests are added in the future.

'''Links'''
* [http://biosbits.org/ BITS]
* [[Supported Motherboards]]

'''Mentors'''
* [[User:MJones|Marc Jones]]

== coreboot cheap testing rig ==
The goal of this project is to create a cheap testing rig which works with the existing board test infrastructure. We have a hardware test system since 2006:
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/Slides-LinuxBIOS-QA.pdf Quality Assurance Talk (Slides)]
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestIntegrationManual.pdf Test Integration Manual]
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/DevelopersManual.pdf Test Developers Manual]
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestSpecification.pdf Test Specification]

The initial version of our testing rig used a remote power switch and was rather expensive. With cheaper technologies such as X10, it's possible to drop the testing costs per board significantly.

'''Links'''
* http://qa.coresystems.de
* [[InSystemFlasher]] is a cheap DIY hardware prototype for building an automated testing rig for modern SPI-based boards. This could be used as a starting point.

'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]

== coreboot mainboard test result reporting ==
One of the biggest challenges in coreboot is support many systems in the same codebase. As systems age and coreboot continues to develop, the condition of mainboards becomes unknown. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. This project would work closely with the coreboot test suite project and/or the hardware test rig project. A good example of test results gathering and reporting is done by the Phoronix/Openbenchmark. The student should investigate other test and reporting solutions to leverage the best options for coreboot. It is important the the student considers how testing and reporting can be extended as features and tests are added in the future.

'''Links'''
* http://openbenchmarking.org/
* http://www.coreboot.org/Supported_Motherboards

'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]
* [[User:MJones|Marc Jones]]

== coreboot ports for Family14 mainboards ==
Identify potential mainboards to port based on the recently released AMD Family 14 support. The goal would be to support publicly available plaftorms with a number of payloads and operating systems.

'''Mentors'''
*[[User:Jason Wang|QingPei Wang]]

== coreboot ACPI/S3/power managment ==
coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific. Create a generic solution for ACPI table generation and S3 support.

'''Mentors'''
*

==coreboot port to ARM SOC's with PCIe==

[http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm Xilinx Zynq-7030]

[http://www.altera.com/devices/fpga/cyclone-v-fpgas/hard-processor-system/cyv-soc-hps.html Altera Cyclone V ]

[http://www.st.com/internet/mcu/product/251211.jsp ST spear1340]

[[ARM]] SOC's with PCIe are available. These systems can take advantage of coreboot's strength in properly configuring PCI devices, fast boot time and payload support.

Note that coreboot has in the past supported three different CPUs (x86, Alpha, PPC), so the structure is there for adding in a new processor family.
We will need to find the right platform to do the work, but I (Ron) can provide a board and JTAG debugger if needed.

There was an ARM project started in 2011.

http://blogs.coreboot.org/blog/2011/05/11/gsoc2011-project-porting-coreboot-to-arm-architecture/

'''Mentors'''
* Bari Ari
* [[User:Rminnich|Ron Minnich]]
* [[User:Jason Wang|QingPei Wang]]

== coreboot panic room ==

Create a safe boot solution for coreboot to easily and cheaply recover the system in case of a panic().

Ron would like to base this solution around SerialICE. The basic idea is that the system always boots to SerialICE. There is a test in CMOS for 'last boot worked' and, if this is set, SerialICE finds a coreboot in cbfs and runs it. If 'last boot worked' is not set, or the user hits some magic keyboard sequence, SerialICE takes control.

SerialICE needs to be extended (not much) to make this work. Having this capability would make it possible for Ron to get some very hard ports working that are just not possible today. At the same time, there are lots of hardware boards to test this idea on, so it should be easy to get it working.

It might be possible to integrate this into the coreboot build as a bootblock option (in the same spot as the fallback/normal switch and the simple loader).

There was a panic room project started in 2011
http://blogs.coreboot.org/blog/2011/05/09/gsoc-project-coreboot-panic-room-diagnostics-also-remote-flashing/

'''Mentors'''
* [[User:Rminnich|Ron Minnich]]

== Board config infrastructure ==

Design data structures that host information about the board layout so coreboot can better initialize components and generate all kinds of tables (mptable, pirq, acpi, ...) from that dynamically (at build or runtime, as appropriate). Adapt boards to use that instead of the current hardcodes.

'''Links'''
* ?

'''Mentors'''
* ?

== Refactor AMD code ==

AMD K8 and AMD Fam10 are different enough to have their own code. This is unfortunate, as you have to decide which CPU type you use in a given mainboard. Refactor AMD code so a single image can support both chip types on a given board. Also move tables from get_bus_conf and the like to the device tree or kconfig options (or runtime detection), as appropriate.

'''Links'''
* ?

'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]

ACPI

2013-02-22T19:57:58Z

PatrickGeorgi: /* Windows Errors */

This page contains some (developer) documentation about how ACPI can be used in coreboot.

= ACPI setup HOWTO =

Please have a look at the files in [http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/mainboard/asus/a8v-e_se src/mainboard/asus/a8v-e_se]. Please also check out http://acpi.info, which contains the ACPI specification.

== Set up hardware ==

Set the '''PMIO base address''' to some known address, and set up the desired ACPI IRQ (usually IRQ9; sometimes it is called the SCI interrupt).

== Fixed ACPI Description Table (FADT) ==

You may skip this section if your SB has it already. Just call it from your MB ACPI setup code (check M2V-MX SE for details).

Now you will need to create an ACPI table which describes the I/O port location for kernel ACPI implementation. This is the '''FACP''' table. You will need to create the '''fadt.c''' file and fill in the I/O port values plus IRQ:

<pre>
fadt->sci_int = 9;
fadt->pm1a_evt_blk = VT8237R_ACPI_IO_BASE;
fadt->pm1b_evt_blk = 0x0;
fadt->pm1a_cnt_blk = VT8237R_ACPI_IO_BASE + 0x4;
fadt->pm1b_cnt_blk = 0x0;
fadt->pm2_cnt_blk = 0x0;
fadt->pm_tmr_blk = VT8237R_ACPI_IO_BASE + 0x8;
fadt->gpe0_blk = VT8237R_ACPI_IO_BASE + 0x20;
fadt->gpe1_blk = 0x0;
</pre>

In this example the ACPI IRQ is 9, and the '''PM1A event block''' starts at VT8237R_ACPI_IO_BASE. You may obtain some values from '''cat /proc/ioport''' if running with the proprietary BIOS. Not all blocks are necessary—usually only PM1A PMTMR and GPE0 are used. Please note that this table has the I/O port information stored twice using different formats. Please consult the ACPI specification for details. Most settings in '''fadt.c''' can use their default values.

If Linux complains about "IRQ 9 nobody cared", recheck these values. The gpeX_blk must span both status and enable bits (which is easy to get wrong given the unclear documentation on this). If GPE0_STS is 64bit, you have to configure 16 bytes (or 128 bits in the x_* variant).

ACPI spec says to set only one of FIRMWARE_CTRL and X_FIRMWARE_CTRL, which is different to how other x_* values are handled. Set firmware_ctrl if located at <4GB, x_firmware_ctrl if located at >=4GB, and set the other value to 0. It's generally more useful to set firmware_ctrl (to support 32bit operating systems).

== Differentiated System Description Table (DSDT) ==

The '''DSDT table''' contains a bytecode that is executed by a driver in the kernel. This table stores also '''ACPI routing information''' in '''_PRT''' methods. You may add those _PRT methods later.

==== Generic part of DSDT ====

A very generic DSDT table would look similar to the ASUS A8V-E/ASUS M2V-MX SE [http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/mainboard/asus/a8v-e_se/dsdt.asl src/mainboard/asus/a8v-e_se/dsdt.asl] file.

<pre>
Scope (\_PR)
{
Processor (\_PR.CPU0, 0x00, 0x000000, 0x00) {}
Processor (\_PR.CPU1, 0x01, 0x000000, 0x00) {}
}
</pre>

This is here for compatibility. More interesting is:

<pre>
/* For now only define 2 power states:
* - S0 which is fully on
* - S5 which is soft off
* any others would involve declaring the wake up methods
*/
Name (\_S0, Package () {0x00, 0x00, 0x00, 0x00 })
Name (\_S5, Package () {0x02, 0x02, 0x00, 0x00 })
</pre>

This defines the SLP_TYP fields in PM1A register. In my case I need to store 010 to perform soft-off, and 000 to wake up. Modify it to fit your chipset needs.

==== Interrupt routing in DSDT ====

The _PRT methods define the routing, similar to PIR and MP Table.

<pre>
Package (0x04) { 0x000BFFFF, 0x00, 0x00, 0x10 }, //slot 0xB
Package (0x04) { 0x000BFFFF, 0x01, 0x00, 0x11 },
Package (0x04) { 0x000BFFFF, 0x02, 0x00, 0x12 },
Package (0x04) { 0x000BFFFF, 0x03, 0x00, 0x13 },
</pre>

This defines the slot 0xB (all functions FFFF) routing as follows:

<pre>
INTA -> IRQ16
INTB -> IRQ17
INTC -> IRQ18
INTD -> IRQ19
</pre>

Note: you cannot indicate the special functions like:

<pre>
Package (0x04) { 0x000F0001, 0x00, 0x00, 0x14 }, // 0xf Native IDE IRQ 20
</pre>

It means 0:0f.1 INTA is routed to IRQ20. Linux likes it. Windows does not (code 12). The ACPI standard requires that function is always 0xffff.

Please note that the 0x10, 0x11 are called '''GSI (global system interrupt)'''. All your interrupts routed through first APIC will start with 0x00, second APIC will perhaps start at IRQ24 etc. This example has no support for legacy PIC routing. For PIC routing you would need to alter the rest of the fields in the _PRT package and also crete PIRQA-PIRQD special devices.

The described above uses static IRQ assignments. Some chipsets like MPC55/CK804 have a configuration register which indicates what APIC pins are routed to what interrupt. Those typically use dynamic IRQ routing which provides a '''_CRS''' and '''_SRS''' methods to set such registers. For now, those registers are filled in MP-Table setup of each MCP55/CK804 board. All you need is to have static wiring like the MP-Table has.

The rest of the file contains just some legacy devices to make certain OS installers happy. Don't forget to install the '''iasl''' compiler and also adjust the coreboot buildsystem to build the binary DSDT for you.

=== CPU Power Management ===

The CPU power management is hardware specific. It is described in ACPI specs and also in AMD BIOS and Kernel Developer guide. The rest of this section describes the AMD specific part. AMD needs ACPI objects which describe the similar info as the legacy PowerNow table. Check the BKDG for details.

The content of the tables must be generated at runtime, which is a bit of a problem, because the AML code must be generated or DSDT patched. There is an '''acpigen''' infrastructure to generate the AML code.

The actual content for family 0fh revF and later P-States can be generated by complex algorithm implemented in amd_model_fxx_generate_powernow(). This function should be called in acpi_fill_ssdt_generator() callback. Up to revE, all P state info must be hardcoded in tables (not supported).

=== C States ===

C states are processor power states. C1 is mandantory and reached on IA32 compatible processors using the HLT instruction, C2 and C3 are optional and must be configured.

C states can be configured in ACPI using two methods:
# by defining the P_BLK base address in the Processor() Definition, and P_LVLx_LAT values in the FADT
# using the _CST object

P_BLK is easier to configure, if the hardware supports that method. ACPI defines that there must be two registers at P_BLK+4 and P_BLK+5 that initiate a transition to C2 or C3 when the register is read. After sleep, the read returns 0. P_LVLx_LAT define the worst case latency of the state transition.

_CST is necessary if you want to support more than 3 C states, or if the transition procedure doesn't follow the ACPI requirement.

=== PCI root bus _CRS method ===

Windows needs to know the actual decode ranges for PCI root bus (and any other). Windows needs to know platform independent way, how is I/O routed on PCI0 bus (and other busses).
* For K8 this means to read the I/O and MMIO routing registers (same as '''k8resdump''' provides) and use them to create ACPI objects. The actual PCI regs are read in acpi-k8 in modelf and stored as SSDT table. The k8-util.asl code will construct the resources from that SSDT table. One can use the k8-util.asl code which will construct the resource objects. Check the ASUS M2V-MX mainboard ACPI code.
* For i945 the required registers are read in the ASL code in northbridge/intel/i945/acpi/i945_hostbridge.asl.

=== DSDT debugging ===

There are two ways. You can store values in "debug" object, which will print it in dmesg. Check http://www.linuxhq.com/kernel/v2.6/28-rc6/Documentation/acpi/debug.txt how to turn that on. In DSDT use store method to write to Debug object. You can write buffers, ints etc:

* Store ("The answer to the question of live universe and everything is:", Debug)
* Store (42, Debug)

Second method is userspace interpretation of DSDT table. This can be achieved with ACPI CA Unix package. It is located in '''acpica-unix-20081204/tools/acpiexec'''. You can eval the objects and run the methods, like _CRS for example.

If you receive a BSOD with '''STOP code 0xa5''', check this: http://support.microsoft.com/kb/314830.

== Other tables ==

Rest of the ACPI tables is located at acpi_tables.c. I will describe briefly all methods:

=== acpi_fill_mcfg ===

If your platform supports MMCONFIG (memory mapped PCI configuration registers, aka extended PCIe configuration) just modify the function with correct base address.

=== acpi_fill_madt ===

[[Image:ApicSystem.svg|thumb|right|A system with 8259s and APICs]]

This table describes the ACPI IRQ information, as well as IRQ override. For code example check the M2V-MX SE acpi_tables. You will need to create the sub-table for LAPIC (the APIC counterpart in CPU) and describe the APICs and also deal with so called IRQ overrides.

Let’s look at the figure below which explains how the interrupts are routed.

The interrupt sources are on the right side. The legacy IRQs and the PCI IRQs are connected to both APIC and 8259.

In the legacy case, the APIC is programmed in virtual wire mode. It will just interconnect pin0 of APIC with its output, bypassing APIC completely. OS uses 8259s, and ignores APICs at all.

The APIC should be in this mode in BIOS, to do that for your SB, check the setup_ioapic in vt8237r_lpc.c. Please note that there is some bit which also says if APIC is delivering through wires, or through FSB messages.

But back to the table. You need to provide some kind of description of the APICs. Each APIC is identified with its own ID and with the offset where its IRQ starts. It is called GSI base – Global System Interrupt base. This is just the value which is used in the _PRT entries as offset for IRQ nr. Typically the first SB APIC has offset 0, second APIC starts where the first has finished, so at IRQ 24 if the first has 24 interrupt sources.

Last thing in this table are IRQ overrides. Usually there are two IRQ overrides. IRQ0 override means that IRQ0 is not connected to pin 0 on APIC but to another, most likely pin 2. Check the figure above why. Second IRQ override is for ACPI IRQ. This overrides the 'level' of the interrupt to 'active low'. The rest of the table is filled with NMI entries for the processor.

 

=== write_acpi_tables ===

This is the main function which constructs the tables. Functions described above are callbacks from the "construct" functions called here. You may omit the HPET and MCFG tables.

=== FACS table ===

This table must be aligned to 64B boundary (Windows checks this).

= Suspend to RAM =

There are patches on the mailing list which add support for suspend to RAM in coreboot. The resume start of the computer does not differ until OS waking vector is executed instead of payload.

Checklist of things which needs to be setup correctly:

* Supend clocks, SUSA/B/C plane pins
* Often the Super I/O has some pin to toggle the power for RAM
* SLP_TYPE with S3 definition to your DSDT
* Support for exit-self-refresh in your RAM controller
* An NVRAM which stores the memory configuration, which is known runtime (DQS)
* Chipset tweaks for S3 (like various signal delays)
* CPU tweaks (for AMD the PM1 and PM2 registers and SMAF codes)
* _RAMBASE of coreboot setup to 31MB and set LB_MEM_TOPK to 32MB
* Make sure new code does not corrupt any memory
* Make sure that you reserve _RAMBASE - LB_MEM_TOPK
* SMP might need some fixes

= ACPI bytecode generator =

Some ACPI stuff is generated runtime. To achieve this goal we have a AML code generator which generates binary ACPI bytecode. Such code then resides typically in SSDT table. There is a helper function which creates such a table - acpi_create_ssdt_generator(). The content of the table is created through the callback function acpi_fill_ssdt_generator(). So far we have two big users of the generator k8acpi_write_vars() and amd_model_fxx_generate_powernow(). The first function will generate some runtime configuration of HT bus and PCI decode ranges. Second function generates the P-States.

The available functions are in acpigen.h. Mostly there are functions generating some primitive named data structures. However sometimes it's necessary to put more data to a package. ACPI AML code needs to know the block lengths. The len is unknown until we have filled the payload of such package. Therefore when we are done, we need
to call function acpigen_patch_len(int len) which will patch last object (package) which need patching. It uses stack internally so more structures can be nested. Look to acpigen.c and learn what functions call acpigen_write_len_f() - those needs patching.

= Debugging ACPI =

When CONFIG_ACPI_DEBUG is compiled into the kernel, the ACPI debug level can be specified on the kernel command line:

acpi.debug_level=0x2003
(warn, error und tables debug enabled)

The values can be checked at runtime:
# cat /sys/module/acpi/parameters/debug_level
Description Hex SET
ACPI_LV_ERROR 0x00000001 [*]
ACPI_LV_WARN 0x00000002 [*]
ACPI_LV_INIT 0x00000004 [*]
ACPI_LV_DEBUG_OBJECT 0x00000008 [ ]
ACPI_LV_INFO 0x00000010 [ ]
ACPI_LV_INIT_NAMES 0x00000020 [ ]
ACPI_LV_PARSE 0x00000040 [ ]
ACPI_LV_LOAD 0x00000080 [ ]
ACPI_LV_DISPATCH 0x00000100 [ ]
ACPI_LV_EXEC 0x00000200 [ ]
ACPI_LV_NAMES 0x00000400 [ ]
ACPI_LV_OPREGION 0x00000800 [ ]
ACPI_LV_BFIELD 0x00001000 [ ]
ACPI_LV_TABLES 0x00002000 [ ]
ACPI_LV_VALUES 0x00004000 [ ]
ACPI_LV_OBJECTS 0x00008000 [ ]
ACPI_LV_RESOURCES 0x00010000 [ ]
ACPI_LV_USER_REQUESTS 0x00020000 [ ]
ACPI_LV_PACKAGE 0x00040000 [ ]
ACPI_LV_ALLOCATIONS 0x00100000 [ ]
ACPI_LV_FUNCTIONS 0x00200000 [ ]
ACPI_LV_OPTIMIZATIONS 0x00400000 [ ]
ACPI_LV_MUTEX 0x01000000 [ ]
ACPI_LV_THREADS 0x02000000 [ ]
ACPI_LV_IO 0x04000000 [ ]
ACPI_LV_INTERRUPTS 0x08000000 [ ]
ACPI_LV_AML_DISASSEMBLE 0x10000000 [ ]
ACPI_LV_VERBOSE_INFO 0x20000000 [ ]
ACPI_LV_FULL_TABLES 0x40000000 [ ]
ACPI_LV_EVENTS 0x80000000 [ ]
--
debug_level = 0x00000007 (* = enabled)

= Potential Issues =
== Windows Errors ==
At first, not an error, but something to take note: Windows might cache system information and only detect ACPI changes if you modify the table versions. So tweak them liberally when debugging ACPI issues with Windows.

=== STOP 0xa5 ===
A Blue Screen Of Death with STOP code 0x000000A5 is ACPI related, and it seems that Microsoft is very strict when it comes to ACPI compliance. http://support.microsoft.com/kb/314830/en explains some of the error codes, but not all of them.
* Parameter1 == 0x00001000 means that some memory resource is claimed by ACPI that, according to memory tables, belongs to the OS. Parameter3 is the start address, Parameter4 is the length of the range. They can probably be found somewhere in the ASL code.

* Parameter1 == 0x0000000D means that some _ADR or _HID Symbol is missing in the dsdt.asl.
* Parameter1 == 0x00000011 is "something in the ACPI init". This can be (among other things)
** improper object names, like an object "\._PR_foo" inside the "\._PR" scope (it should be just "foo" instead, or the surrounding scope killed)
** the use of qwords, which XP doesn't like (known error code tuple in this case: (0x11, 0x8, address of SSDT, unknown value))
** improper aml code, acpica as used by Linux is very lenient. (Wrong length field encoding in new acpigen code led to (0x11, 0x8, address of SSDT, unknown value))

The documentation of windbg has more detailed information about STOP 0xa5 than the MSDN article.
STOP 0xa5 can be debugged by using checked builds of ntoskrnl and hal.dll and a second machine connected with a null-modem cable and windbg as kernel debugger.

=== "unexpected error" in Windows XP / Server 2003 setup ===
(from http://www.coreboot.org/pipermail/coreboot/2011-May/065179.html)

Windows XP or Server 2003 setup might fail with an error message such as:

"An unexpected error (805262864) occurred at line 1768 of d:\xpclient\base\boot\setup\arcdisp.c"

The value 805262864 varies, and is the physical address, in decimal, of one of the ACPI tables.

The error message is displayed when a 1024 dword page table array used by setupldr runs out of space.

This table is used for mapping various physical addresses, such as those of ACPI tables (a separate table identity maps the lower 16MB used by setupldr code and data). Setupldr only looks at ACPI tables (FACP) to determine make and model of the system. The make and model of the system is needed when setupldr scans the good/bad bios lists contained in txtsetup.sif. The good/bad bios lists are used to bypass installation of the ACPI enabled kernel on certain systems known to have ACPI problems. The code loop that scans the lists creates a new mapping each time it reads an ACPI table, and never frees mappings. The code uses FACP OEM ID to determine the system model. The code sequentially reads tables listed in the RSDT array until the FACP is found. Each read consumes one page table entry. If more that 4 tables precede the FACP in the RSDT array, the 1024 entry page table array will run out of space before the good/bad bios list processing completes.

BIOS can work around this Windows XP/Server 2003 limitation by placing the FACP early in the RSDT array.

=== Other errors ===
* Quoting [http://support.microsoft.com/?scid=kb%3Ben-us%3B935806&x=14&y=18 MSDN]: A "Stop: 0x0000007E" error message or a "Stop: 0x0000008E" error message typically means that a kernel mode component, such as a driver, encountered an error that could not be handled by the built-in Windows error handler.

=== Using checked builds ===
There's a faulty assert in acpi.sys that trips only on checked builds. Get rid of "else" statements in ASL code that the compiler can't optimize away (ie. "if () { Return Foo } else { Return Bar }" is changed to "if () { Return Foo } Return Bar" and thus won't trigger this assert). We primarily had that with acpigen generated ElseOps (since those see no optimizer pass).

== Linux Errors ==
=== ACPI 2.0/3.0 without XSDT ===
Linux 2.6.12.x requires an XSDT if the RSDP revision is larger than 0 as it's hardcoded to use that instead of the RSDT then. Fixed in later Linux versions.
=== PCI Hotplug _BBN fail ===

If you are seeing the following error you are on a (most likely old) system with PCI(e) hotplug.

pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5

Add the following under PCI0 device to get rid of the error:
Name(_ADR, 0)
Name(_BBN, 0)
== Random Notes ==
=== Don't nest scopes improperly ===
Windows ACPI doesn't like
Scope(\foo) {
Name(\foo.bar) { ... }
}

Either make that
Scope(\foo) {
Name (bar) { .. }
}
or eliminate the scope:
Name(\foo.bar) { ... }
=== Shutdown sequences differ between systems ===
Success with shutting down a system from Windows doesn't mean that Linux properly shuts down the system (and this probably applies the other way around, too)

= Further Resources =

* A good FAQ: http://www.acpi.info/acpi_faq.htm
* [ftp://ftp.suse.com/pub/people/trenn/ACPI_BIOS_on_Linux_guide/acpi_guideline_for_vendors.pdf ACPI BIOS Guideline for Linux] by Thomas Renninger
* [http://lwn.net/Articles/237085/ How to debug ACPI Problems] by Thomas Renninger
* [http://www.coreboot.org/pipermail/coreboot/2009-January/044210.html ACPI table dump script]
* [http://en.opensuse.org/S2ram Suspend to RAM utility]
* [http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/CPA002_WH06.ppt Windows Vista ACPI information, incl. advice on common problems in ACPI implementations]
* [http://smackerelofopinion.blogspot.com/2010/03/debugging-acpi-using-acpiexec.html Debugging ACPI using acpiexec]

Fallback mechanism

2013-02-21T11:56:12Z

PatrickGeorgi: PatrickGeorgi moved page Fallback mecanism to Fallback mechanism: typo in page name

== Introduction ==
The fallback mecanism permits to have 2 different romstage,ramstage,payload in the same images under a different prefix.
The switch between both can be governed by an nvram configuration parameter.

== Howto ==
* build the coreboot image as usual, it will produce an image in build/coreboot.rom
* After the first build run:
make menuconfig
* Optionally change the payload.
* Go in
General setup --->
* Change:
(fallback) CBFS prefix to use
To:
(normal) CBFS prefix to use
* Go back to the main menu and select:
Architecture (x86) --->
select the following option:
[*] Update existing coreboot.rom image
Exit and save and rebuild...

The image will then have fallback and normal:
Name Offset Type Size
cmos_layout.bin 0x0 cmos_layout 1776
pci1002,9710.rom 0x740 optionrom 60928
fallback/romstage 0xf580 stage 92823
fallback/coreboot_ram 0x26080 stage 66639
fallback/payload 0x36540 payload 54976
config 0x43c40 raw 4455
normal/romstage 0x44e00 stage 92823
normal/coreboot_ram 0x5b8c0 stage 68820
normal/payload 0x6c600 payload 159949
(empty) 0x93700 null 442136

Fallback mecanism

2013-02-21T11:56:12Z

PatrickGeorgi: PatrickGeorgi moved page Fallback mecanism to Fallback mechanism: typo in page name

#REDIRECT [[Fallback mechanism]]

OpenVSA

2013-02-07T10:32:51Z

PatrickGeorgi:

'''VSA''', or '''Virtual System Architecture''' is a low-level software library included in the bootloader/BIOS for system using AMD Geode-series CPUs and companion chips.

AMD released VSA sources under the name '''geode-vsa''' in 2006 (licensed under the terms of the GNU LGPL). The original sources were hosted by the OLPC project, and can be pulled with git from <code>git://dev.laptop.org/geode-vsa</code>. Updated sources are hosted by coreboot.org located in the [http://review.coreboot.org/gitweb?p=blobs.git;a=tree;f=cpu/amd/geode_lx;hb=HEAD blobs repository]. The '''OpenVSA''' sources include modified '''geode-vsa''' sources, as well as some new components also released under the GNU LGPL.

The VSA code runs under x86 SMM (System Management Mode) which is like "real mode" with some extra opcodes, priviledges, and side-effects.

As originally published, the VSA code compiled and assembled with older, commercially unavailable versions of Microsoft tools. The OpenVSA code has been modified in order to build under a GNU toolchain so that it may be maintained and enhanced by a wider group of users. It still requires MASM or a compatible assembler, such as [http://www.japheth.de/JWasm.html JWasm]. Because of this, it wasn't integrated in the coreboot build process yet.

== Status ==

The current status of the OpenVSA is: '''''experimental'''''. Please do not use OpenVSA in your system unless you have access to a low-level re-flashing tools.

== Download ==

Please refer to the [[AMD_Geode_Porting_Guide#Manual_build|AMD_Geode_Porting_Guide]].

== Differences Between VSA and OpenVSA ==

=== Summary ===

{|
|- bgcolor="#6699ff"
!Category
!VSA
!OpenVSA

|- bgcolor="#dddddd"
|Assembler
|MASM 6.11c or greater
|GNU gas (part of binutils)

|- bgcolor="#cccccc"
|Make
|NMAKE.EXE Version 1.40 or greater
|GNU make

|- bgcolor="#dddddd"
|C-compiler
|MSVC Version 1.52
|GNU gcc

|- bgcolor="#cccccc"
|Final binary output
|exe2bin.exe
|GNU objcopy (part of binutils)

|- bgcolor="#dddddd"
|Assembly syntax
|Microsoft/Intel
|GNU gas/AT&T

|- bgcolor="#cccccc"
|Code Generation
|16-bit, inherent to the toolchain commands used during build
|16-bit assembly, generated by using <code>.code16</code> in assembly files; 32-bit from C, prefixes generated by using <code>.code16gcc</code> in C files

|- bgcolor="#dddddd"
|Memory Model
|"tiny": merges CS and DS, inherent to the toolchain commands used during build
|"tiny" model accomplished with specific section names and linker script statements

|- bgcolor="#cccccc"
|SMM-only opcode assembly
|MASM macros
|Perl script <code>smimac.pl</code> pre-processes to constant-sequences

|- bgcolor="#dddddd"
|Internal assembly functions: calling convention
|custom/random, no apparent fixed pattern
|unchanged

|- bgcolor="#cccccc"
|Assembly functions called from C: calling convention
|Microsoft <code>pascal</code>
|GNU <code>__attribute__((fastcall))</code>

|- bgcolor="#dddddd"
|C header file translation to assembly include
|h2inc.exe
|manual/static translation
|}

=== Calling Conventions And Stack ===

==== VSA: MASM and Microsoft C ====

The original VSA sources used 16-bit <code>MS PASCAL</code> calling convention (<code>__pascal</code>):
* stack parameter order: left-to-right
* called function cleans up the stack
* all parameters are pushed onto the stack
* return values to 16 bits returned in <code>AX</code>
* return values 17 to 32 bits returned in <code>DX:AX</code>
* scratch registers <code>AX, BX, CX, DX, ES</code>

<pre>
^ |<- 16 bits ->|
| higher
| address
| (pop)

-------------
| first param |
-------------
...
-------------
| last param | 4(BP)
-------------
| return IP | 2(BP)
-------------
| old BP | <-- BP
-------------
(locals) -2(BP)
-------------
(saved regs)
-------------
| (saved reg) | <-- SP
-------------

| lower
| address
| (push)
v

</pre>

==== OpenVSA: GNU ====

With GNU on the Intel 386, the fastcall attribute (<code>__attribute__(fastcall)</code>) calling convention:
* stack parameter order: right-to-left
* called function cleans up the stack
* if the first one or two arguments are integers/pointers (<=32bit), they are passed via <code>ECX</code> and <code>EDX</code>
* all other parameters are pushed onto the stack
* return values to 32 bits are returned in <code>EAX</code>
* scratch registers <code>EAX, ECX, EDX</code>

<pre>
^ |<- 32 bits ->|
| higher
| address
| (pop) (uses (no
frame) frame)

-------------
| last param |
-------------
...
-------------
| 3rd param | 8(EBP) 4(ESP)
-------------
| return EIP | <-- ESP
-------------
| saved EBP | <-- EBP
-------------
(locals) -4(EBP)
-------------
(saved regs)
-------------
(saved reg) <-- ESP
| lower
| address
| (push)
v
</pre>

=== Notable C-Code Differences ===

Microsoft C appears to accept a statement like:

ULONG Data;
...
(UCHAR)Data = 0;

This is not a portable construction, GCC rejects is, so has been changed to:

*((UCHAR *) &Data) = 0;

== Feature Wish List ==

TODO.

== Hacking Notes ==

TODO.

{{PD-self}}

TianoCore

2013-02-06T18:04:27Z

PatrickGeorgi:

'''[http://tianocore.org TianoCore]''' is an open source implementation of '''UEFI''', the '''Unified Extensible Firmware Interface'''. UEFI (formerly EFI) is intended to replace the traditional PC BIOS. TianoCore as in implementation cannot do that, as it lacks the code to do hardware initalization. Since hardware initialization is exactly what coreboot does, the combination of coreboot + TianoCore is the most straightforward option to provide a complete, opensource UEFI environment.

There are various approaches for loading TianoCore. One is to use SeaBIOS' floppy mechanism to load DUET, a TianoCore-on-BIOS. The other is to make TianoCore a true coreboot payload.
== DUET ==
=== Howto DuetPkg ===
* Setup edk2 for compilation:
* First compile DuetPkg:
cd BaseTools
export EDK_TOOLS_PATH=$(pwd)
cd ../
. ./edksetup.sh BaseTools
build -p DuetPkg/DuetPkgIa32.dsc

* Then package it in a floppy file:
Go in the edk2 directory, then run the following commands:
cd BaseTools
export EDK_TOOLS_PATH=$(pwd)
cd ../
. ./edksetup.sh BaseTools
./DuetPkg/PostBuild.sh IA32 GCC44
./DuetPkg/CreateBootDisk.sh file ./floppy.img ./floppy.img FAT12 IA32 GCC44
lzma -zc floppy.img > myfloppy.img.lzma
* Then add it to cbfs:
Go into the coreboot directory and do:
./build/cbfstool coreboot.rom add -f /path/to/myfloppy.img.lzma -n floppyimg/MyFloppy.lzma -t raw
./build/cbfstool coreboot.rom print
* reflash coreboot and reboot.
* Then while booting press F12 and choose it:
Press F12 for boot menu.

Select boot device:

1. Ramdisk [MyFloppy]
2. ata1-0: Hitachi HDP725050GLA360 ATA-8 Hard-Disk (465 GiByte

=== Result ===
M4A785T-M => fails with an interrupt issue

Qemu => way too slow

x60 => seem to work,no media to test

== TianoCore as coreboot payload ==
http://www.phisch.org/website/efiboot/ reports on a first implementation, but for various reasons there is no source code.

https://github.com/pgeorgi/edk2/tree/coreboot-pkg hosts an attempt to do an published open source implementation of such a payload. It boots, but still lacks many features, most notably a driver for the Graphic Output Protocol (but many more, really), so for now the only path for user interaction is the serial port.

Welcome to coreboot

2013-02-04T12:54:18Z

PatrickGeorgi: pipermail url changed

<table width="100%" valign="top"><tr valign="top"><td width="80%">

<div style="margin-top:0.5em; margin-bottom:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;">
'''coreboot''' is a Free Software project aimed at replacing the proprietary [http://wikipedia.org/wiki/BIOS BIOS] (firmware) found in most computers. coreboot performs a little bit of hardware initialization and then executes additional boot logic, called a [[Payloads|payload]].

With the separation of hardware initialization and later boot logic, coreboot can scale from specialized applications that run directly from firmware, run operating systems in flash, load custom bootloaders, or implement firmware standards, like [[SeaBIOS | PC BIOS services]] or [[TianoCore | UEFI]]. This allows for systems to only include the features necessary in the target application, reducing the amount of code and flash space required.

coreboot currently supports over '''[[Supported Motherboards|230]]''' different mainboards. Check the [[Support]] page to see if your system is supported.


coreboot was formerly known as [http://www.coreboot.org/pipermail/coreboot/2008-January/029135.html LinuxBIOS].

</div>

<div style="margin-top:0.5em; margin-bottom:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;">
coreboot recently switched to [[git]] and [http://review.coreboot.org gerrit] is now used as patch review tool.
</div>

{| cellspacing=0 cellpadding=8 border=0 margin=0 padding=0 align="top" width=100%
|-
|style="vertical-align:top"|

{{Box|
BORDER = #8898bf|
BACKGROUND = yellow|
WIDTH = 100%|
ICON = [[Benefits|More...]]|
HEADING = [[Benefits]]|
CONTENT =

* 100% Free Software (GPL), no royalties, no license fees!
* Fast boot times (500 milliseconds to verified Linux kernel)



* Supports many [[Supported Motherboards|mainboards]], [[Supported Chipsets and Devices|chipsets]], and [[payloads]]


}}

|style="vertical-align:top"|

{{Box|
BORDER = #8898bf|
BACKGROUND = #d1adf6|
WIDTH = 100%|
ICON = [[Use Cases|More...]]|
HEADING = [[Use Cases]]|
CONTENT =

* Desktop PCs, servers, [[Laptop|laptops]]
* [[Clusters]]

* Embedded solutions




}}

|style="vertical-align:top"|

{{Box|
BORDER = #8898bf|
BACKGROUND = lime|
WIDTH = 100%|
ICON = [[Payloads|More...]]|
HEADING = [[Payloads]]|
CONTENT =

* [[SeaBIOS]] / [[FILO]] / [[GRUB2]] / [[Payloads|...]] 
* [[Linux]] / [[Windows]] / [[FreeBSD]] / [[NetBSD]] / [[Payloads|...]] 
* [[Etherboot]] / [[GPXE]] / [[iPXE]] / [[Payloads|...]]


}}

|}

{| cellspacing=5 cellpadding=15 border=0 valign="top" width=100%
| width=50% style="vertical-align:top"|

{|
|style="vertical-align:top"|
[[Image:chip_cb.png]]
|style="vertical-align:top"|
'''About''' Find out more about coreboot.<hr />[[Press]] | [[Logo]] | [[History]] | [[Screenshots|Screenshots/Videos]] | [[Contributors]] | [[Sponsors]] | [[Products]] | [[Vendors]]
|}

|style="vertical-align:top"|

{|
|style="vertical-align:top"|
[[Image:chip_devel.png]]
|style="vertical-align:top"|
'''Developers''' Get involved! Help us make coreboot better.<hr />[[Development Guidelines]] | [[Developer Manual]] | [http://qa.coreboot.org/docs/doxygen.php Doxygen] | [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree Browse Source] | [[GSoC]] | [[Flag Days]] | [[Distributed and Automated Testsystem|Testsystem]]
|}

|-
| width=50% style="vertical-align:top"|

{|
|style="vertical-align:top"|
[[Image:chip_status.png]]
|style="vertical-align:top"|
'''Status''' Find out whether your hardware is already supported.<hr />[[Supported Motherboards|Supported Boards]] | [[Supported Chipsets and Devices|Supported Chipsets]] | [[:Category:Tutorials|Board Status Pages]] | [http://qa.coreboot.org Build Status]
|}

|style="vertical-align:top"|

{|
|style="vertical-align:top"|
[[Image:chip_tools.png]]
|style="vertical-align:top"|
'''Related Tools''' Tools and libraries related to coreboot.<hr />[[Flashrom]] | [[Superiotool]] | [[Nvramtool]] | [[Buildrom]] | [[Mkelfimage]] | [[Inteltool]] | [[Msrtool]] | [[Ectool]] | [[Developer_Manual/Tools|Hardware tools]] | [[Abuild]] | [[SerialICE]]
|}

|-
| width=50% style="vertical-align:top"|

{|
|style="vertical-align:top"|
[[Image:chip_101.png]]
|style="vertical-align:top"|
'''Getting Started''' Download coreboot and get started.<hr />[[Build HOWTO]] | [[Download coreboot|Downloads]] | [[Documentation]] | [[QEMU]] | [[AMD SimNow]] | [[Build from Windows]]
|}

|style="vertical-align:top"|

{|
|style="vertical-align:top"|
[[Image:chip_support.png]]
|style="vertical-align:top"|
'''Support''' Learn how to contact us and find help and support.<hr />[[FAQ]] | [[Mailinglist]] | [[IRC]] | [http://tracker.coreboot.org/trac/coreboot/ Issue Tracker] | [[Glossary]] | [[coreboot Options|coreboot Options]]
|}

|}
</td><td width="20%">

[[File:Coreboot menuconfig.png|center|thumb|[[Build HOWTO|make menuconfig]] in coreboot]]

 

'''[http://blogs.coreboot.org News (blog)]'''<hr />

<rss max=5>http://blogs.coreboot.org/feed/</rss>


'''[[Current events|Upcoming Events]]'''<hr />





 
{{#widget:Ohloh Project|id=coreboot|type=partner_badge}}
{{#widget:Ohloh Project|id=coreboot|type=cocomo}}

</td></tr></table>

__NOTOC__
__NOEDITSECTION__

Supported Chipsets and Devices

2013-02-01T16:59:40Z

PatrickGeorgi: move v1 and v3 information to separate pages

'''coreboot v4''' is the current stable coreboot tree recommended for productive use and for porting new boards.
* If a device is not supported by coreboot v4, try [[Supported_Chipsets_and_Devices/v1|checking coreboot v1]] or [[Supported_Chipsets_and_Devices/v3|coreboot v3]] for support.
* In general it is '''not''' recommended to use coreboot v3 — this was an experimental development tree which is gradually being merged into v4.
* 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.

See also [[Supported Motherboards]].

== Devices supported in coreboot v4 ==

{| border="0" valign="top"
| valign="top"|

'''Northbridges'''

{| border="0" style="font-size: smaller" valign="top"
|- bgcolor="#6699dd"
! align="left" | Vendor
! align="left" | Northbridge
! align="left" | Status

|- bgcolor="#eeeeee" valign="top"
| AMD
| Fam14h - G-Series
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| Fam12h - Llano
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| Fam10h
| style="background:lime" | OK16
|- bgcolor="#eeeeee" valign="top"
| AMD
| K8
| style="background: lime " | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| GX1
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| GX (GX2)
| style="background: lime" | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| LX
| style="background: lime" | OK

|- bgcolor="#dddddd" valign="top"
| Intel®
| E7501
| style="background:#eeeeee" | ?
|- bgcolor="#dddddd" valign="top"
| Intel®
| E7520
| style="background:#eeeeee" | ?
|- bgcolor="#dddddd" valign="top"
| Intel®
| E7525
| style="background:#eeeeee" | ?
|- bgcolor="#dddddd" valign="top"
| Intel®
| 3100
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Intel®
| 5000P
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Intel®
| 82443BX (440BX)
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Intel®
| 82810
| style="background:yellow" | WIP9
|- bgcolor="#dddddd" valign="top"
| Intel®
| 82830
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Intel®
| 82855
| style="background:yellow" | WIP
|- bgcolor="#dddddd" valign="top"
| Intel®
| EP80579 (Tolapai)
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Intel®
| 945
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Intel®
| SCH US15W (Poulsbo)
| style="background:lime" | OK

|- bgcolor="#eeeeee" valign="top"
| SiS
| SiS761GX
| style="background:lime" | OK

|- bgcolor="#dddddd" valign="top"
| VIA
| VT8601 (PLE133)
| style="background:yellow" | WIP
|- bgcolor="#dddddd" valign="top"
| VIA
| VT8623 (CLE266)
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| VIA
| K8T890
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| VIA
| K8M890
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| VIA
| CN400
| ?
|- bgcolor="#dddddd" valign="top"
| VIA
| CN700
| style="background:lime" | OK14
|- bgcolor="#dddddd" valign="top"
| VIA
| CX700
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| VIA
| VX800
| style="background:yellow" | WIP

|}

| valign="top"|

'''Southbridges'''

{| border="0" style="font-size: smaller" valign="top"
|- bgcolor="#6699dd"
! align="left" | Vendor
! align="left" | Southbridge
! align="left" | Status

|- bgcolor="#eeeeee" valign="top"
| AMD
| AMD8111
| style="background: lime" | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| AMD8131
| style="background: lime" | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| AMD8132
| style="background: lime" | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| AMD8151
| style="background: lime" | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| CS5530/CS5530A
| style="background:yellow" | WIP
|- bgcolor="#eeeeee" valign="top"
| AMD
| CS5535
| style="background:#eeeeee" | ?
|- bgcolor="#eeeeee" valign="top"
| AMD
| CS5536
| style="background: lime " | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| RS690
| style="background: lime " | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| SB600
| style="background: lime " | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| RS780/RS785
| style="background: lime " | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| SB700/SB7x0
| style="background: lime " | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| SR56x0
| style="background: lime " | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| SB5100
| style="background: lime " | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| SB800
| style="background: lime " | OK
|- bgcolor="#dddddd" valign="top"
| Broadcom
| BCM21000
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Broadcom
| BCM5780
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Broadcom
| BCM5785
| style="background:lime" | OK

|- bgcolor="#eeeeee" valign="top"
| Intel®
| 6300ESB (ESB6300)
| style="background:#eeeeee" | ?
|- bgcolor="#eeeeee" valign="top"
| Intel®
| 3100
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| Intel®
| 82371EB (PIIX4E)
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| Intel®
| 82801AA/AB (ICH/ICH0)
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| Intel®
| 82801BA/BAM (ICH2/ICH2-M)
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| Intel®
| 82801CA/CAM (ICH3-S/ICH3-M)
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| Intel®
| 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| Intel®
| 82801EB/ER (ICH5/ICH5R)
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| Intel®
| 82801GX (ICH7)
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| Intel®
| 82870
| style="background:#eeeeee" | ?
|- bgcolor="#eeeeee" valign="top"
| Intel®
| PXHD
| style="background:#eeeeee" | ?
|- bgcolor="#eeeeee" valign="top"
| Intel®
| EP80579 (Tolapai)
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| Intel®
| SCH US15W (Poulsbo)
| style="background:lime" | OK

|- bgcolor="#dddddd" valign="top"
| NVIDIA
| CK804
| style="background:lime" | OK17
|- bgcolor="#dddddd" valign="top"
| NVIDIA
| MCP55
| style="background:lime" | OK17

|- bgcolor="#eeeeee" valign="top"
| Ricoh
| RL5C476
| style="background:#eeeeee" | ?

|- bgcolor="#dddddd" valign="top"
| SiS
| SiS966(L)
| style="background:lime" | OK

|- bgcolor="#eeeeee" valign="top"
| VIA
| VT8231
| style="background:#eeeeee" | ?
|- bgcolor="#eeeeee" valign="top"
| VIA
| VT8235
| style="background:#eeeeee" | ?
|- bgcolor="#eeeeee" valign="top"
| VIA
| VT8237R
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| VIA
| VT8237A
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| VIA
| VT8237S
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| VIA
| VT82C686
| style="background:yellow" | WIP

|}

| valign="top"|

'''Super I/Os'''

{| border="0" style="font-size: smaller" valign="top"
|- bgcolor="#6699dd"
! align="left" | Vendor
! align="left" | Super I/O
! align="left" | Status

|- bgcolor="#eeeeee" valign="top"
| ASUS
| A8000
| style="background:lime" | OK12, 13

|- bgcolor="#dddddd" valign="top"
| Fintek
| F71805F/FG
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Fintek
| F71859
| style="background:yellow" | OK19
|- bgcolor="#dddddd" valign="top"
| Fintek
| F71863F/FG
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Fintek
| F71872F/FG
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Fintek
| F71889
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Fintek
| F81865F
| style="background:yellow" | WIP

|- bgcolor="#eeeeee" valign="top"
| ITE
| IT8661F
| style="background:yellow" | OK5
|- bgcolor="#eeeeee" valign="top"
| ITE
| IT8671F
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| ITE
| IT8673F
| style="background:yellow" | OK5
|- bgcolor="#eeeeee" valign="top"
| ITE
| IT8705F
| style="background:yellow" | OK5
|- bgcolor="#eeeeee" valign="top"
| ITE
| IT8712F
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| ITE
| IT8716F
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| ITE
| IT8718F
| style="background:yellow" | OK5

|- bgcolor="#dddddd" valign="top"
| Intel®
| 3100
| style="background:lime" | OK15
|- bgcolor="#dddddd" valign="top"
| Intel®
| EP80579 (Tolapai)
| style="background:lime" | OK15

|- bgcolor="#eeeeee" valign="top"
| NSC
| PC8374
| style="background:#eeeeee" | ?
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC87309
| style="background:yellow" | OK5
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC87351
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC87360
| style="background:#eeeeee" | ?
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC87366
| style="background:#eeeeee" | ?
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC87382
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC87384
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC87392
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC87417
| style="background:#eeeeee" | ?
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC87427
| style="background:#eeeeee" | ?
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC97307
| style="background:#eeeeee" | ?
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC97317
| style="background:#eeeeee" | ?

|- bgcolor="#dddddd" valign="top"
| ServerEngines
| PILOT
| style="background:yellow" | OK18

|- bgcolor="#dddddd" valign="top"
| SMSC®
| FDC37M70x
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| FDC37B80x
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| FDC37B78x
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| FDC37B72x
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| FDC37B81x
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| FDC37M60x
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| LPC47B27x
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| LPC47M10x
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| LPC47M112
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| LPC47M13x
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| LPC47M15x
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| LPC47M192
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| LPC47B397
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| DME1737
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| SCH5307
| style="background:lime" | OK12
|- bgcolor="#dddddd" valign="top"
| SMSC®
| LPC47N217
| style="background:#dddddd" | ?

|- bgcolor="#eeeeee" valign="top"
| VIA
| VT1211
| style="background:#eeeeee" | ?
|- bgcolor="#eeeeee" valign="top"
| VIA
| VT82C686(A/B)
| style="background:yellow" | OK5

|- bgcolor="#dddddd" valign="top"
| Winbond™
| W83627DHG
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Winbond™
| W83627UHG
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Winbond™
| W83627EHG/HF/EHF/THF
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Winbond™
| W83697HF/HG
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Winbond™
| W83627THF/THG
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Winbond™
| W83977F
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Winbond™
| W83977TF
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Winbond™
| W83977EF
| style="background:lime" | OK4
|}

| valign="top"|

'''CPUs'''

{| border="0" style="font-size: smaller"
|- bgcolor="#6699dd"
! align="left" | Type
! align="left" | CPU
! align="left" | Status

|- bgcolor="#eeeeee" valign="top"
| x86
| AMD
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| x86
| Intel®
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| x86
| VIA
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| Emulated
| QEMU
| style="background:lime" | OK
|}

'''SOCs'''

{| border="0" style="font-size: smaller" valign="top"
|- bgcolor="#6699dd"
! align="left" | Vendor
! align="left" | SOC
! align="left" | Status

|- bgcolor="#eeeeee" valign="top"
| AMD
| Elan SC520
| style="background: lime" | OK
|- bgcolor="#dddddd" valign="top"
| Intel®
| EP80579 (Tolapai)
| style="background: yellow" | OK20
|}

|}


4 The W83977EF works fine with the W83977TF code (the pre-RAM serial part at least). 
5 Pre-RAM serial output works fine, but nothing else, yet. 
9 Works mostly, but currently there are some limitations as to which RAM DIMMs can be used. 
12 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. 
13 The ASUS A8000 Super I/O seems to be a rebranded SMSC DME1737. 
14 Working, but not widely tested, yet. Works with single DIMM DDR2. 
15 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. 
16 Two implementations: Rev B-C supported in coreboot, Rev D-E support via AGESA 
17 MCP55 and CK804 are supported, but no open documents are available from NVIDIA. 
18 Partially supported, but not all features implemented. 
19 Only support for serial port 1 implemented, everything else is unsupported so far due to lack of datasheet. 
20 Working, but not widely tested, yet. Works with single DIMM DDR2. 


__FORCETOC__

Supported Chipsets and Devices/v3

2013-02-01T16:59:01Z

PatrickGeorgi: copy coreboot v3 information to separate page

= Devices supported in coreboot v3 =

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

{| border="0" valign="top"
| valign="top"|

'''Northbridges'''

{| border="0" style="font-size: smaller" valign="top"
|- bgcolor="#6699dd"
! align="left" | Vendor
! align="left" | Northbridge
! align="left" | Status

|- bgcolor="#eeeeee" valign="top"
| AMD
| Geode LX
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| Geode K8
| style="background:orange" | WIP

|- bgcolor="#dddddd" valign="top"
| Intel®
| 82443BX (440BX)
| style="background:orange" | WIP
|- bgcolor="#dddddd" valign="top"
| Intel®
| 945
| style="background:orange" | WIP

|- bgcolor="#eeeeee" valign="top"
| VIA
| CN700
| style="background:orange" | WIP

|}

| valign="top"|

'''Southbridges'''

{| border="0" style="font-size: smaller" valign="top"
|- bgcolor="#6699dd"
! align="left" | Vendor
! align="left" | Southbridge
! align="left" | Status

|- bgcolor="#eeeeee" valign="top"
| AMD
| AMD-8111
| style="background:yellow" | ?
|- bgcolor="#eeeeee" valign="top"
| AMD
| AMD-8132
| style="background:yellow" | ?
|- bgcolor="#eeeeee" valign="top"
| AMD
| AMD-8151
| style="background:yellow" | ?
|- bgcolor="#eeeeee" valign="top"
| AMD
| CS5536
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| RS690
| style="background: lime " | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| SB600
| style="background: lime " | OK

|- bgcolor="#dddddd" valign="top"
| Intel®
| 82371EB (PIIX4E)
| style="background:orange" | WIP
|- bgcolor="#dddddd" valign="top"
| Intel®
| 82801GX (ICH7)
| style="background:orange" | WIP

|- bgcolor="#eeeeee" valign="top"
| NVIDIA
| MCP55
| style="background:orange" | WIP1

|- bgcolor="#dddddd" valign="top"
| VIA
| VT8237R
| style="background:orange" | WIP

|}

| valign="top"|

'''Super I/Os'''

{| border="0" style="font-size: smaller" valign="top"
|- bgcolor="#6699dd"
! align="left" | Vendor
! align="left" | Super I/O
! align="left" | Status

|- bgcolor="#eeeeee" valign="top"
| Fintek
| F71805F
| style="background:orange" | WIP

|- bgcolor="#dddddd" valign="top"
| ITE
| IT8712F
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| ITE
| IT8716F
| style="background:lime" | OK

|- bgcolor="#eeeeee" valign="top"
| VIA
| VT1211
| style="background:orange" | WIP

|- bgcolor="#dddddd" valign="top"
| Winbond™
| W83627HF
| style="background:lime" | OK
|- bgcolor="#dddddd" valign="top"
| Winbond™
| W83627THG
| style="background:lime" | OK

|}

| valign="top"|

'''CPUs'''

{| border="0" style="font-size: smaller"
|- bgcolor="#6699dd"
! align="left" | Type
! align="left" | CPU
! align="left" | Status

|- bgcolor="#eeeeee" valign="top"
| AMD
| Geode LX
| style="background:lime" | OK
|- bgcolor="#eeeeee" valign="top"
| AMD
| K8
| style="background:orange" | WIP

|- bgcolor="#dddddd" valign="top"
| Generic
| i586
| style="background:orange" | WIP

|- bgcolor="#eeeeee" valign="top"
| Intel
| Core Duo / Core 2 Duo
| style="background:orange" | WIP

|- bgcolor="#dddddd" valign="top"
| VIA
| C7
| style="background:orange" | WIP

|}

|}


1 MCP55 and CK804 are supported, but no open documents are available from NVIDIA.

Supported Chipsets and Devices/v1

2013-02-01T16:58:28Z

PatrickGeorgi: copy coreboot v1 information to separate page

= Devices supported in coreboot v1 =

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

{| border="0" valign="top"
| valign="top"|

'''Northbridges'''

{| border="0" style="font-size: smaller" valign="top"
|- bgcolor="#6699dd"
! align="left" | Vendor
! align="left" | Northbridge
! align="left" | Status
! align="left" | v4?

|- bgcolor="#eeeeee" valign="top"
| Acer
| M1631
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| Alpha
| Tsunami
| style="background:#dddddd" | ?
| style="background:#dddddd" | —3
|- bgcolor="#eeeeee" valign="top"
| AMD
| AMD76x
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| Intel®
| 430TX
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| Intel®
| 440BX
| style="background:#dddddd" | ?
| style="background:lime" | Yes
|- bgcolor="#dddddd" valign="top"
| Intel®
| 440GX
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| Intel®
| 82815EP
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| Intel®
| 82830
| style="background:#dddddd" | ?
| style="background:lime" | Yes
|- bgcolor="#dddddd" valign="top"
| Intel®
| 82860
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| Intel®
| E7500
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| Intel®
| E7501
| style="background:#dddddd" | ?
| style="background:lime" | Yes
|- bgcolor="#dddddd" valign="top"
| Intel®
| E7505
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#eeeeee" valign="top"
| Micron
| 21PAD
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| Motorola
| MPC107
| style="background:#dddddd" | ?
| style="background:#dddddd" | —3
|- bgcolor="#eeeeee" valign="top"
| NSC/AMD
| GX1
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#dddddd" valign="top"
| VIA
| VT694
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| VIA
| VT8601
| style="background:#dddddd" | ?
| style="background:lime" | Yes
|- bgcolor="#dddddd" valign="top"
| VIA
| VT8623
| style="background:#dddddd" | ?
| style="background:lime" | Yes
|}

| valign="top"|

'''Southbridges'''

{| border="0" style="font-size: smaller" valign="top"
|- bgcolor="#6699dd"
! align="left" | Vendor
! align="left" | Southbridge
! align="left" | Status
! align="left" | v4?

|- bgcolor="#eeeeee" valign="top"
| Acer
| M1535
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee" valign="top"
| Acer
| M1543
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| AMD
| AMD766
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| AMD
| AMD768
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#eeeeee" valign="top"
| Intel®
| 82801
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| Intel®
| 82801CA
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| Intel®
| 82801DB
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| Intel®
| 82870
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| Intel®
| PIIX4E
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#dddddd" valign="top"
| NSC/AMD
| CS5530
| style="background:#dddddd" | ?
| style="background:lime" | Yes
|- bgcolor="#dddddd" valign="top"
| NSC
| SCX200
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#eeeeee" valign="top"
| VIA
| VT8231
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| VIA
| VT8235
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| VIA
| VT82C686
| style="background:#eeeeee" | ?
| style="background:yellow" | WIP2
|- bgcolor="#dddddd" valign="top"
| Winbond™
| W83C553
| style="background:#dddddd" | ?
| style="background:#dddddd" | —3
|}

| valign="top"|

'''Super I/Os'''

{| border="0" style="font-size: smaller" valign="top"
|- bgcolor="#6699dd"
! align="left" | Vendor
! align="left" | Super I/O
! align="left" | Status
! align="left" | v4?

|- bgcolor="#eeeeee" valign="top"
| Acer
| M1535
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| ITE
| IT8671F
| style="background:#dddddd" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC87309
| style="background:lime" | OK
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC87351
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC97307
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| NSC
| PC97317
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#dddddd" valign="top"
| SiS
| 950
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#eeeeee" valign="top"
| SMC
| FDC37B72X
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| SMC
| FDC37B78X
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| SMC
| FDC37B807
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| SMC
| FDC37C669
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee" valign="top"
| SMC
| FDC37C67X
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee" valign="top"
| SMC
| FDC37N769
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| VIA
| VT1211
| style="background:#dddddd" | ?
| style="background:lime" | Yes
|- bgcolor="#dddddd" valign="top"
| VIA
| VT8231
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| VIA
| VT82C686
| style="background:#dddddd" | ?
| style="background:yellow" | WIP2
|- bgcolor="#eeeeee" valign="top"
| Winbond™
| W83627HF
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| Winbond™
| W83877TF
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee" valign="top"
| Winbond™
| W83977EF
| style="background:#eeeeee" | ?
| style="background:lime" | Yes1
|}

| valign="top"|

'''North-/Southbridges'''

{| border="0" style="font-size: smaller" valign="top"
|- bgcolor="#6699dd"
! align="left" | Vendor
! align="left" | North/South
! align="left" | Status
! align="left" | v4?

|- bgcolor="#eeeeee" valign="top"
| NSC
| SCX200
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| SiS
| 540
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| SiS
| 550
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| SiS
| 630
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| SiS
| 635
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| SiS
| 730
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd" valign="top"
| SiS
| 735
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#eeeeee" valign="top"
| ST
| STPC
| style="background:#eeeeee" | ?
| style="background:red" | No
|}

'''CPUs'''

{| border="0" style="font-size: smaller"
|- bgcolor="#6699dd"
! align="left" | Type
! align="left" | CPU
! align="left" | Status
! align="left" | v4?

|- bgcolor="#eeeeee" valign="top"
| Alpha
| EV6
| style="background:#eeeeee" | ?
| style="background:#eeeeee" | —3
|- bgcolor="#dddddd" valign="top"
| PowerPC
| ?
| style="background:#dddddd" | ?
| style="background:#dddddd" | —3
|- bgcolor="#eeeeee" valign="top"
| x86
| AMD
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| x86
| Intel®
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee" valign="top"
| x86
| VIA
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|}

|}


1 The W83977EF works fine with the W83977TF code in coreboot v4 (the pre-RAM serial part at least). 
2 Pre-RAM serial output works in coreboot v4, but the rest is not supported, yet. 
3 Will not be ported anytime soon, we focus on x86 in coreboot v4.

Current events

2013-02-01T13:07:42Z

PatrickGeorgi:

Please contact [[User:Stepan|Stefan Reinauer]], [[User:Rminnich|Ronald Minnich]] or [[User:Stuge|Peter Stuge]] for more information on the events.

== Upcoming Events ==

'''2013'''
* coreboot and flashrom share a booth at [[FOSDEM 2013]] in Brussels on February 2-3, 2013.

== Past Events ==

'''2012'''
* [[GSoC|2012 Google Summer of Code]]
* coreboot and flashrom share a booth at [[FOSDEM 2012]] in Brussels on February 4-5, 2012, and a presentation about coreboot on laptops will be held by [[User:Hailfinger|Carl-Daniel Hailfinger]].

'''2011'''

* coreboot and flashrom exhibit at [http://www.linuxtag.org/ LinuxTag] in Berlin on May 11-14, 2011.

* coreboot and flashrom shared a booth at [[FOSDEM 2011]] in Brussels on February 5-6, 2011, and several presentations were held by [[User:Ruik|Rudolf Marek]] and [[User:Hailfinger|Carl-Daniel Hailfinger]].

'''2010'''

* coreboot exhibited at [http://www.linuxtag.org/ LinuxTag 2010] in Berlin on June 9-12, 2010.
* coreboot had its [[FOSDEM 2010|very first DevRoom]] at [http://www.fosdem.org/ FOSDEM] in Brussels on February 6, 2010.

'''2009'''

* [[User:Stuge|Peter Stuge]] presented [http://events.ccc.de/congress/2009/Fahrplan/events/3661.en.html coreboot] at [http://events.ccc.de/congress/2009/ the 26th Chaos Communication Congress (26C3)] in Berlin on December 27, 2009.
* [[User:Stuge|Peter Stuge]] presented [http://www.databadge.net/ifsec2009/reg/lin/show_sessions.php coreboot] at [http://www.linux-world.nl/nl-NL/Bezoeker.aspx?sc_lang=en LinuxWorld Conference & Expo] in Utrecht on November 4, 2009.
* [[User:Stuge|Peter Stuge]] presented [https://har2009.org/program/events/210.en.html coreboot] at [https://wiki.har2009.org/page/Main_Page HAR2009] in Vierhouten on August 13, 2009.
* coreboot had a booth at [[LinuxTag 2009|LinuxTag]] in Berlin on June 24-27, 2009.
* [[User:Stuge|Peter Stuge]] presented coreboot at [http://freedomhectaipei.pbworks.com/ FreedomHEC Taipei] on June 11, 2009.
* [[User:Stuge|Peter Stuge]] presented coreboot at [http://goopen2009.friprog.no/ GoOpen 2009] in Oslo on April 16-17, 2009.
* [[User:Stepan|Stefan Reinauer]], [[User:Stuge|Peter Stuge]] and [[User:Ruik|Rudolf Marek]] made a visit at [http://www.embedded-world.de/ embedded world 2009] in Nürnberg on March 3-5.
* [[User:Rminnich|Ron Minnich]] had a [http://scale7x.socallinuxexpo.org/dotorg/coreboot coreboot booth] at the [http://scale7x.socallinuxexpo.org/ Southern California Linux Expo] (SCALE 7x) on February 20-22, 2009.

'''2008'''

* [[User:Stuge|Peter Stuge]] presented [http://events.ccc.de/congress/2008/Fahrplan/events/2970.en.html coreboot: Beyond The Final Frontier] and held a coreboot workshop at [http://events.ccc.de/congress/2008/ the 25th Chaos Communication Congress (25C3)] on December 27-30.
* [[User:Stuge|Peter Stuge]] presented coreboot at the [http://www.nluug.nl/events/nj08/ NLUUG Autumn Conference on Mobile Computing] and [http://www.embeddedlinuxconference.com/elc_europe08/ CE Linux Forum - Embedded Linux conference Europe 2008] on November 6-7.
* [[User:Rminnich|Ronald Minnich]], [[User:Stuge|Peter Stuge]] and [[User:Stepan|Stefan Reinauer]] presented coreboot in a [[Screenshots#Google_Tech_Talks_2008:_coreboot_.28aka_LinuxBIOS.29:_The_Free.2FOpen-Source_x86_Firmware|Google TechTalk]] on October 30.
* [[User:Stuge|Peter Stuge]] presented [http://fscons.org/events/?action=event&id=32 coreboot] at the [http://fscons.org/ Free Society Conference and Nordic Summit 2008] on October 24-26.
* [[User:Stuge|Peter Stuge]] presented coreboot at the [http://slackathon.se/2008/ Slackathon 2008] OpenBSD meeting in September.
* Coreboot was exhibiting at [[LinuxTag 2008]] in Berlin on May 28-31.
* The [[Coreboot Symposium 2008|coreboot symposium 2008]] was held in Denver, April 3 – 5, 2008 during the High Performance Computer Science Week [http://www.hpcsw.org HPCSW].

'''2007'''

* There was a [[News#2007.2F05.2F23_LinuxBIOS_booth_at_LinuxTag_in_Berlin.2C_29.2F5-2.2F6|LinuxBIOS booth at the LinuxTag in Berlin, May 29 - June 6, 2007]], as well as a hands-on workshop by Peter Stuge.
* Ron Minnich gave [http://www.fosdem.org/2007/schedule/events/linuxbios a talk about LinuxBIOS] on February 24, 2007 at [http://www.fosdem.org/2007/ FOSDEM 2007].

'''2006'''

* The [[LinuxBIOS Symposium 2006]] took place on October 1-3, 2006 in Hamburg, Germany.

'''2005'''

* The [[LinuxBIOS Summit 2005]] took place on October 11-13 in Santa Fe, NM.

Debugging

2013-01-24T22:04:36Z

PatrickGeorgi: Add Windows Debugger Instructions

= GDB Interface =
== GDB Wait ==
Coreboot has an easy to use interface to the GNU debugger gdb. To enable it, select the CONFIG_GDB_STUB and the CONFIG_GDB_WAIT options in the Debugging menu of coreboot's configuration:
[*] GDB debugging support
[*] Wait for a GDB connection
Then Coreboot will stop and wait for a GDB connection.

To connect to the remote coreboot instance over serial do:
$ gdb
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>.
(gdb) file ./build/cbfs/fallback/coreboot_ram.debug
Reading symbols from /home/gnutoo/Coreboot/coreboot/build/cbfs/fallback/coreboot_ram.debug...done.
(gdb) set remotebaud 115200
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
_text () at src/arch/x86/lib/c_start.S:85
85 call hardwaremain
(gdb)

== Exceptions with GDB ==
Else if you just enable CONFIG_GDB_STUB option in the Debugging menu of coreboot's configuration you will still get some benefit.
[*] GDB debugging support

For instance you will not get exceptions like this:

Unexpected Exception: 0 @ 10:0012724b - Halting
Code: 0 eflags: 00010046
eax: 00000001 ebx: 00000061 ecx: 00000004 edx: 00000000
edi: 00000000 esi: 00000061 ebp: 00163abc esp: 00163a98

But instead you will be able to connect to the machine using gdb over a serial line in case of an exception:

(gdb) file coreboot/build/cbfs/fallback/coreboot_ram.debug
Reading symbols from coreboot/build/cbfs/fallback/coreboot_ram.debug...done.
(gdb) set remotebaud 115200
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
0x0012824b in __udivdi3 (n=17082841390, d=0) at ...
...
(gdb) bt
#0 0x0012824b in __udivdi3 (n=17082841390, d=0)
at /usr/lib/gcc/gcc- 4.3.2/libgcc/../gcc/libgcc2.c:899
#1 0x0011efa2 in handle_port_61h ()
#2 0x0011fbc3 in my_inb ()
#3 0x001189f5 in x86emuOp_in_byte_AL_IMM ()
#4 0x001092f1 in X86EMU_exec ()
#5 0x0010a06f in biosemu ()
#6 0x0011fcfb in run_bios ()
#7 0x0010cbcb in pci_dev_init ()
#8 0x00103d9b in dev_initialize ()
#9 0x0010f8b5 in hardwaremain ()
#10 0x00100099 in _text ()

= Windows 7 USB =
This is documentation on how to setup Windows 7 on USB, so it can be used with a USB debug device and WinDbg to track down Windows errors that are otherwise hard to debug (eg. black screen, Stop codes, ACPI issues).

== Prepare Windows Media ==
=== Step 1: Get media ===
I used Windows 7 Ultimate 64bit English, ISO image has SHA1: 36AE90DEFBAD9D9539E649B193AE573B77A71C83

I also tried Windows 8 Consumer Preview 64bit English, ISO image has SHA1: 1288519C5035BCAC83CBFA23A33038CCF5522749

=== Step 2: Prepare disk ===
Use some sufficiently large USB media (4GB+), and format it as NTFS.

Windows 7 might work on FAT, but Windows 8 definitely won’t, as the main file archive is >4GB, which even FAT32 doesn't like.

For reference, I called the volume “WININST”, but I doubt that matters.

=== Step 3: Copy the entire disk content to disk ===
I started out from an ISO image (as obtained from digitalriver), and extracted it using 7-zip to the media.
After that I had a directory that looks like this:

E:\>dir
Datenträger in Laufwerk E: ist WININST
Volumeseriennummer: 86DF-6846

Verzeichnis von E:\

12.04.2011 11:38 122 autorun.inf
03.05.2012 18:54 <DIR> boot
12.04.2011 11:38 383.786 bootmgr
12.04.2011 11:38 669.568 bootmgr.efi
03.05.2012 18:54 <DIR> efi
12.04.2011 11:38 106.768 setup.exe
03.05.2012 18:56 <DIR> sources
03.05.2012 18:56 <DIR> support
03.05.2012 18:56 <DIR> upgrade
4 Datei(en), 1.160.244 Bytes
5 Verzeichnis(se), 4.976.803.840 Bytes frei

=== Step 4: Install boot sector ===
For this, you need to run a Windows Console prompt as Administrator. It’s not enough to run as the admin user, but you need to go through the “run as administrator” + UAC motions.

On Windows 7, the fastest way is to open the start menu, type “cmd” in the search field, wait for cmd to appear (with that black window + C:\ icon), right click it, and select “run as administrator”. On Windows 8, there's an Admin Command Line in the Win+X menu.

Move to the drive with the install data (E:\ in my case), enter boot\, and run bootsect like this:

C:\Windows\System32>e:

E:\>cd boot

E:\boot>bootsect /nt60 e: /force /mbr
Target volumes will be updated with BOOTMGR compatible bootcode.

E: (\\?\Volume{39f55ea8-3ea1-11e1-afe7-005056c00008})

Forced dismount complete, open handles to this volume are now invalid.

Successfully updated NTFS filesystem bootcode.

\??\PhysicalDrive2

Successfully updated disk bootcode.

Bootcode was successfully updated on all targeted volumes.

=== Step 5: Prepare installer for USB debug device ===
In the same Console prompt (and same directory), run:

bcdedit /store bcd /dbgsettings usb targetname:TargetSystem
bcdedit /store bcd /set {default} debug yes

If you have access to the legacy serial port, you can use that to run a kernel debugger session without usb debug device (and its setup, which can be complicated in the presence of Rate Matching Hubs).

In such a setup, instead of the first command use
bcdedit /store bcd /dbgsettings serial debugport:1 baudrate:115200

=== Step 6: Install ===
Start your coreboot + seabios system, and make it boot from your USB device.
If everything is well, dance and jump with joy! If not, you have a chance to improve coreboot!

=== Step 7: Boot Windows ===
Once installation is done, boot the new system. That’s another source of trouble, since this is a slightly different Windows than the one driving the installer.
And there was no chance to setup debug mode for it yet! (TBD)

== Setup Debugging Environment ==
=== Configuring WinDbg ===
First, install WinDbg. You can find in the Debugging Utilities for Windows. Set up the symbol file path, so it can resolve the addresses it gets from the target:

* Create a directory somewhere (C:\Symbols is the default).
* Create an empty "index2.txt" in there.
* Start Windbg
* File, Symbol File Path
* Enter <code>"SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols"</code> (fill in your path instead of <code>C:\Symbols</code>)

With this configuration, WinDbg will fetch symbol files from the Microsoft server.

=== Start debug operation ===
Select the communication channel in File, Kernel Debug (USB 2.0 or serial).

For USB, fill in the name (TargetSystem in the example above), for serial, configure the port. Press OK.

WinDbg will wait for the target to break into the kernel debugger now. It might take a while on the first runs as it has to download the symbol files. Eventually it will print the error and location.

Lenovo x60x

2013-01-19T06:56:46Z

PatrickGeorgi: /* Recovery */ raket on IRC reported another method to reset BUC

== Flashing on the laptop instructions. ==
'''Lenovo X60''', '''X60s''', '''T60''' and '''T60p''' flashing instructions.

These Lenovo laptops have a register that must be flipped before coreboot can be flashed.

For those/some models with SPI flash chips you have also to modify flashrom. Because the chipset locks down the available commands that flashrom can send to the flash chip, you also need to change the flashrom source in a way that is not suitable to upstream. Flash chips can be identified by various commands (REMS*, RDID etc.). Some of them reply with an ID for the vendor and the exact chip model; others just reply with a single byte which is fine if there is only a small number of chips to distinguish, but won't work for the huge number of flash chips known to flashrom. The problem with the vendor BIOS is that it forbids the higher quality identification commands, so you need to force flashrom to use the lower quality opcode for the chip in your Thinkpad. You have to know the chip model beforehand (e.g. by inspection).

You will need: the flashrom source, a small patch for it, and [http://git.stuge.se/?p=bucts.git the bucts utility].

# Patch flashrom to use RES1 SPI identification and spi_chip_write_1 for your flash chip, as well as change the flash chip model id to fit the RES1 command.
#: Alternatively, you can copy the existing definition first as it is done in [http://patchwork.coreboot.org/patch/3621/ this patch]. Choose either method: apply the patch in the link, or do the patch yourself, as per instruction below.
#* Find the definition of your flash chip in flashrom's flashchips.c
#* Change the .probe field to probe_spi_res1
#* Change the .model_id field to the RES1 ID given in the datasheet of the flash chip
#* Change the .write field to spi_chip_write_1
# Run <code>flashrom -p internal:laptop=force_I_want_a_brick -r factory.bin</code>
#: This step is IMPORTANT since the factory BIOS in your machine is tied to your particular system board (or "planar" in IBM FRU terms) with a unique ID not present in factory BIOS updates.
# Run <code>dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k</code>
# Run <code>dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump</code>
#: Verify that the complete range is filled with ff bytes before proceeding! The above command must output:
#: <code>0000000 ffff ffff ffff ffff ffff ffff ffff ffff</code>
#: <code>*</code>
#: <code>0010000</code>
#: If this is not the case, the coreboot image needs to be rebuilt with the second-to-last 64kbyte block unused.
# Run <code>dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc</code>
# Run <code>bucts 1</code>
# Run <code>flashrom -p internal:laptop=force_I_want_a_brick -w coreboot.rom</code>
#: This will be slow, it will output errors for addresses 0x0 and 0x1f0000 when working with a 2 Mbyte flash chip, and it will say "FAILED!" at the end, see [http://www.flashrom.org/pipermail/flashrom/2012-April/009121.html Peter's mail] before you panic.
# Power cycle the machine (i.e. a cold boot, not just a reboot), now starting with coreboot
# Run <code>flashrom -p internal:laptop=force_I_want_a_brick -w coreboot.rom</code>.
#: This will successfully overwrite the entire flash chip, including the last 64k that were write protected with the factory BIOS.
# Run <code>bucts 0</code>

See also http://thread.gmane.org/gmane.linux.bios/69354 http://thread.gmane.org/gmane.linux.bios.flashrom/575

== Recovery ==
If you had a bad flash you will need a recovery method.

If you only set bucts, then rebooted without doing any flash writes, things might be easier:
bucts sets a register that lives on the RTC well, ie. it is powered by the same source that keeps the clock alive. Usually that's a battery on the mainboard, and often there's some way to cut the source (by removing the battery, a jumper, or pads that can be shorted).
After doing that (for a few seconds, there might be some capacitors in the way that keep power stable), the register should be reset and the system should boot as normal.

On the x60x, bucts issues might also be solved by "discarging RTC", which is done by pressing the power button 5 times for 10 seconds.
=== Required/advised hardware and informations ===
* [http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/42x3550_04.pdf X60 Hardware Maintenance Manual] (for disassembling the laptop)
* An SO-8 IC clip, like the [http://www.tme.eu/en/details/pom-5250/test-clips/pomona/5250/ Pomona 5250] for instance.
* An external flashrom programmer

=== Howto ===
0. wire the pomona clip to a programmer that way:

From the #coreboot IRC Channel on FreeNode servers:
Oct 01 15:35:48 <CareBear\> one important thing is that when you connect the clip to the X60 you should not connect all pins
[...]
Oct 01 15:36:22 <CareBear\> only connect these pins: 1, 2, 4, 5, 6
[...]
Oct 01 15:37:21 <CareBear\> also important: first connect charger to laptop, then connect the clip
[...]
Oct 01 17:49:41 <CareBear\> GNUtoo-desktop : the mainboard must be powered off, but with the charger connected
[...]
Oct 01 17:50:39 <CareBear\> um, that way there is no way anything will break
[...]
Oct 01 17:51:00 <CareBear\> it is important not to connect 3v3 from the outside
Oct 01 17:51:39 <CareBear\> because the correct power sequencing is not known, and if any other rail must come on before the standby 3v3 then the machine may well break when 3v3 is applied from the outside
[...]
Oct 01 17:52:48 <CareBear\> it may also be fine - but it is unknown what happens
[...]
Oct 01 17:53:47 <CareBear\> not supplying 3v3 from the outside is safer
Oct 01 17:54:25 <CareBear\> and because the machine is powered off, there is no risk of the chipset accessing the flash chip
In another hand I didn't follow that and wired it without powering the mainboard(mainboard disconnected from power plug, no battery in) and with all pins and it worked...
# Disassemble carefully the laptop, the SO-8 chip is on the bottom of the mainboard...
# connect the pomona clip to the BIOS chip
# flash coreboot or the BIOS
# remount the laptop

== Coreboot configuration ==
* It's advised to make SeaBios(instead of coreboot) run the VGA option rom by disabling CONFIG_VGA_ROM_RUN:
[ ] Run VGA Option ROMs
in make menuconfig.
Note that you still need to include the option rom in coreboot:
[*] Add a VGA BIOS image
See [[VGA_support]] for details on how to include the VGA BIOS image.
* Also disable CONFIG_S3_VGA_ROM_RUN which is for really old linux kernels(2.4) (which is disabled automatically if you don't select CONFIG_VGA_ROM_RUN).

From the #coreboot IRC Channel on FreeNode servers:
Oct 04 13:47:09 <patrickg> that's about running vga init on s3 wakeup - required for some older linux kernels
[...]
Oct 04 13:47:25 <patrickg> BIOSes call it "POST on wakeup" or sth like that
Oct 04 13:47:30 <patrickg> older ~ 2.4 class ;)

== Status ==
* [[Thinkpad_X60s|Thinkpad X60s Status]]

Lenovo x60x

2013-01-18T22:47:06Z

PatrickGeorgi: explain that recovery from bucts is possible (if flash content is still okay)

== Flashing on the laptop instructions. ==
'''Lenovo X60''', '''X60s''', '''T60''' and '''T60p''' flashing instructions.

These Lenovo laptops have a register that must be flipped before coreboot can be flashed.

For those/some models with SPI flash chips you have also to modify flashrom. Because the chipset locks down the available commands that flashrom can send to the flash chip, you also need to change the flashrom source in a way that is not suitable to upstream. Flash chips can be identified by various commands (REMS*, RDID etc.). Some of them reply with an ID for the vendor and the exact chip model; others just reply with a single byte which is fine if there is only a small number of chips to distinguish, but won't work for the huge number of flash chips known to flashrom. The problem with the vendor BIOS is that it forbids the higher quality identification commands, so you need to force flashrom to use the lower quality opcode for the chip in your Thinkpad. You have to know the chip model beforehand (e.g. by inspection).

You will need: the flashrom source, a small patch for it, and [http://git.stuge.se/?p=bucts.git the bucts utility].

# Patch flashrom to use RES1 SPI identification and spi_chip_write_1 for your flash chip, as well as change the flash chip model id to fit the RES1 command.
#: Alternatively, you can copy the existing definition first as it is done in [http://patchwork.coreboot.org/patch/3621/ this patch]. Choose either method: apply the patch in the link, or do the patch yourself, as per instruction below.
#* Find the definition of your flash chip in flashrom's flashchips.c
#* Change the .probe field to probe_spi_res1
#* Change the .model_id field to the RES1 ID given in the datasheet of the flash chip
#* Change the .write field to spi_chip_write_1
# Run <code>flashrom -p internal:laptop=force_I_want_a_brick -r factory.bin</code>
#: This step is IMPORTANT since the factory BIOS in your machine is tied to your particular system board (or "planar" in IBM FRU terms) with a unique ID not present in factory BIOS updates.
# Run <code>dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k</code>
# Run <code>dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump</code>
#: Verify that the complete range is filled with ff bytes before proceeding! The above command must output:
#: <code>0000000 ffff ffff ffff ffff ffff ffff ffff ffff</code>
#: <code>*</code>
#: <code>0010000</code>
#: If this is not the case, the coreboot image needs to be rebuilt with the second-to-last 64kbyte block unused.
# Run <code>dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc</code>
# Run <code>bucts 1</code>
# Run <code>flashrom -p internal:laptop=force_I_want_a_brick -w coreboot.rom</code>
#: This will be slow, it will output errors for addresses 0x0 and 0x1f0000 when working with a 2 Mbyte flash chip, and it will say "FAILED!" at the end, see [http://www.flashrom.org/pipermail/flashrom/2012-April/009121.html Peter's mail] before you panic.
# Power cycle the machine (i.e. a cold boot, not just a reboot), now starting with coreboot
# Run <code>flashrom -p internal:laptop=force_I_want_a_brick -w coreboot.rom</code>.
#: This will successfully overwrite the entire flash chip, including the last 64k that were write protected with the factory BIOS.
# Run <code>bucts 0</code>

See also http://thread.gmane.org/gmane.linux.bios/69354 http://thread.gmane.org/gmane.linux.bios.flashrom/575

== Recovery ==
If you had a bad flash you will need a recovery method.

If you only set bucts, then rebooted without doing any flash writes, things might be easier:
bucts sets a register that lives on the RTC well, ie. it is powered by the same source that keeps the clock alive. Usually that's a battery on the mainboard, and often there's some way to cut the source (by removing the battery, a jumper, or pads that can be shorted).
After doing that (for a few seconds, there might be some capacitors in the way that keep power stable), the register should be reset and the system should boot as normal.
=== Required/advised hardware and informations ===
* [http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/42x3550_04.pdf X60 Hardware Maintenance Manual] (for disassembling the laptop)
* An SO-8 IC clip, like the [http://www.tme.eu/en/details/pom-5250/test-clips/pomona/5250/ Pomona 5250] for instance.
* An external flashrom programmer

=== Howto ===
0. wire the pomona clip to a programmer that way:

From the #coreboot IRC Channel on FreeNode servers:
Oct 01 15:35:48 <CareBear\> one important thing is that when you connect the clip to the X60 you should not connect all pins
[...]
Oct 01 15:36:22 <CareBear\> only connect these pins: 1, 2, 4, 5, 6
[...]
Oct 01 15:37:21 <CareBear\> also important: first connect charger to laptop, then connect the clip
[...]
Oct 01 17:49:41 <CareBear\> GNUtoo-desktop : the mainboard must be powered off, but with the charger connected
[...]
Oct 01 17:50:39 <CareBear\> um, that way there is no way anything will break
[...]
Oct 01 17:51:00 <CareBear\> it is important not to connect 3v3 from the outside
Oct 01 17:51:39 <CareBear\> because the correct power sequencing is not known, and if any other rail must come on before the standby 3v3 then the machine may well break when 3v3 is applied from the outside
[...]
Oct 01 17:52:48 <CareBear\> it may also be fine - but it is unknown what happens
[...]
Oct 01 17:53:47 <CareBear\> not supplying 3v3 from the outside is safer
Oct 01 17:54:25 <CareBear\> and because the machine is powered off, there is no risk of the chipset accessing the flash chip
In another hand I didn't follow that and wired it without powering the mainboard(mainboard disconnected from power plug, no battery in) and with all pins and it worked...
# Disassemble carefully the laptop, the SO-8 chip is on the bottom of the mainboard...
# connect the pomona clip to the BIOS chip
# flash coreboot or the BIOS
# remount the laptop

== Coreboot configuration ==
* It's advised to make SeaBios(instead of coreboot) run the VGA option rom by disabling CONFIG_VGA_ROM_RUN:
[ ] Run VGA Option ROMs
in make menuconfig.
Note that you still need to include the option rom in coreboot:
[*] Add a VGA BIOS image
See [[VGA_support]] for details on how to include the VGA BIOS image.
* Also disable CONFIG_S3_VGA_ROM_RUN which is for really old linux kernels(2.4) (which is disabled automatically if you don't select CONFIG_VGA_ROM_RUN).

From the #coreboot IRC Channel on FreeNode servers:
Oct 04 13:47:09 <patrickg> that's about running vga init on s3 wakeup - required for some older linux kernels
[...]
Oct 04 13:47:25 <patrickg> BIOSes call it "POST on wakeup" or sth like that
Oct 04 13:47:30 <patrickg> older ~ 2.4 class ;)

== Status ==
* [[Thinkpad_X60s|Thinkpad X60s Status]]

Infrastructure Projects

2013-01-10T08:18:13Z

PatrickGeorgi: coreboot is always CBFS and tinybootblock now

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

{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
! align="left" | Vendor/chipset
! align="left" | Tested
! align="left" | Comments

|- bgcolor="#eeeeee"
| amd/amdfam10
| ?
| —
|- bgcolor="#eeeeee"
| amd/amdht
| ?
| —
|- bgcolor="#eeeeee"
| amd/amdk8
| ?
| —
|- bgcolor="#eeeeee"
| amd/amdmct
| ?
| —
|- bgcolor="#eeeeee"
| amd/gx1
| ?
| —
|- bgcolor="#eeeeee"
| amd/gx2
| ?
| —
|- bgcolor="#eeeeee"
| amd/lx
| ?
| —
|- bgcolor="#eeeeee"
| intel/e7501
| ?
| —
|- bgcolor="#eeeeee"
| intel/e7520
| ?
| —
|- bgcolor="#eeeeee"
| intel/e7525
| ?
| —
|- bgcolor="#eeeeee"
| intel/i3100
| ?
| —
|- bgcolor="#eeeeee"
| intel/i440bx
| ?
| —
|- bgcolor="#eeeeee"
| intel/i82810
| ?
| —
|- bgcolor="#eeeeee"
| intel/i82830
| ?
| —
|- bgcolor="#eeeeee"
| intel/i855
| ?
| —
|- bgcolor="#eeeeee"
| intel/i945
| style="background:lime" | Y
| Tested on Kontron 986LCD-M and Roda RK886EX
|- bgcolor="#eeeeee"
| via/cn400
| ?
| —
|- bgcolor="#eeeeee"
| via/cn700
| style="background:lime" | Y
| Tested on VIA pc2500e.
|- bgcolor="#eeeeee"
| via/cx700
| ?
| —
|- bgcolor="#eeeeee"
| via/vt8601
| ?
| —
|- bgcolor="#eeeeee"
| via/vt8623
| ?
| —
|- bgcolor="#eeeeee"
| 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 <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.

'''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 ==
* Figure out generic ACPI code and deduplicate it.
* Fix issues like http://www.coreboot.org/pipermail/coreboot/2011-May/065179.html

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.

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

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

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

408/512 some_string string

984/16 checksum checksum 392 983
</code>

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

=== CMOS defaults ===
Allow (somehow) to define defaults for all CMOS fields, and create a static table from that. Use that at runtime if the CMOS checksum fails.
In the above format, it could simply be a suffix <code>default=VALUE</code>
Also drop the "default" argument in get_options. As components have their own cmos.layout snippets, we can always take those definitions' defaults, even if mainboards don't make use of CMOS themselves.

=== Value overrides ===
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 ===
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)

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

=== Checksums ===

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.

== Global variables ==

* Make use of global variables where appropriate.

Done:
* Provide v3 style global variables framework

= More ideas =

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

== Add a config for selecting a SeaBIOS git revision ==
Currently there is only the choice between coreboot master and the lastest stable revision.

= Finished =

== Port v3 Resource Allocator ==

The v3 resource allocator should be ported to v4.

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

'''Developers:''' Myles

== Config & Build System ==

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

'''Status:''' Upstream, boards are converted. Old system is gone. All boards build. HOWEVER, not all boards have been boot-tested yet, please report any issues you encounter!

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

== Unify text printing functions ==

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

'''Status:''' Finished.

'''Developers:''' Patrick, Stefan

== Common payload location ==

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

'''Status:''' Finished.

== Fix ALL build warnings ==

* Someone has to do the deed.

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

== Post codes ==

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

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

== Use central oprom init ==

* Get rid of all vgabios.c, make all chipsets with own vgabios.c use devices/oprom/x86.c.
* Use the realmode code for vsmsetup too.

== Use nvramtool for static option table creation ==

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.

'''Status:''' Finished, upstream.

'''Developers:''' Vikram

== Local APIC addresses ==

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

* LAPIC_ADDR
* LOCAL_APIC_ADDR (even twice)
* LAPIC_DEFAULT_BASE

This should be unified.

'''Developers:''' Patrick

== printk into buffer ==

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

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

'''Developers:''' ChromiumOS Team

== USB Debug Console ==

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

'''Developers:''' SvenS

== CBFS ==

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

'''Status:'''

Upstream, pre-CBFS infrastructure removed.

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

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

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

{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
! align="left" | Vendor/chipset
! align="left" | ROM enabled
! align="left" | Tiny bootblock
! align="left" | Status / Comments

|- bgcolor="#eeeeee"
| amd/amd8111
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.
|- bgcolor="#eeeeee"
| amd/cs5530
| style="background:lime" | Y
| style="background:red" | N
| Not tested on hardware, yet.
|- bgcolor="#eeeeee"
| amd/cs5535
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| amd/cs5536
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| amd/sb600
| style="background:lime" | Y
| style="background:lime" | Y
| Build- and runtime-tested on siemens/sitemp_g1p1 by [[User:PatrickGeorgi|PatrickGeorgi]].
|- bgcolor="#eeeeee"
| amd/sb700
| style="background:yellow" | Y
| style="background:yellow" | Y
| —

|- bgcolor="#dddddd"
| broadcom/bcm5785
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#eeeeee"
| intel/esb6300
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i3100
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82371eb
| style="background:lime" | Y
| style="background:yellow" | Y
| Build- and runtime-tested on ASUS P2B by [[User:Uwe|Uwe Hermann]].
|- bgcolor="#eeeeee"
| intel/i82801ax
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801bx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801cx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801dx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801ex
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801gx
| style="background:lime" | Y
| style="background:lime" | Y
| Build- and runtime-tested on Kontron 986LCD-m by PatrickGeorgi

|- bgcolor="#dddddd"
| nvidia/ck804
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.
|- bgcolor="#dddddd"
| nvidia/mcp55
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#dddddd"
| sis/sis966
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#eeeeee"
| via/vt8231
| style="background:yellow" | Y
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| via/vt8235
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| via/vt8237r
| style="background:yellow" | Y
| style="background:yellow" | Y
| —
|- bgcolor="#eeeeee"
| via/vt82c686
| style="background:red" | N
| style="background:red" | N
| —

|}

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

== Tiny Bootblock ==

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

'''Status:''' Available in Kconfig, works on a couple of boards. Requires per southbridge changes (and northbridge in some cases) on many boards (related to ROM enable, see CBFS section).

'''Developers:''' Patrick

Infrastructure Projects

2012-11-29T12:31:18Z

PatrickGeorgi: Move projects to "in progress" and "done" as appropriate

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

{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
! align="left" | Vendor/chipset
! align="left" | Tested
! align="left" | Comments

|- bgcolor="#eeeeee"
| amd/amdfam10
| ?
| —
|- bgcolor="#eeeeee"
| amd/amdht
| ?
| —
|- bgcolor="#eeeeee"
| amd/amdk8
| ?
| —
|- bgcolor="#eeeeee"
| amd/amdmct
| ?
| —
|- bgcolor="#eeeeee"
| amd/gx1
| ?
| —
|- bgcolor="#eeeeee"
| amd/gx2
| ?
| —
|- bgcolor="#eeeeee"
| amd/lx
| ?
| —
|- bgcolor="#eeeeee"
| intel/e7501
| ?
| —
|- bgcolor="#eeeeee"
| intel/e7520
| ?
| —
|- bgcolor="#eeeeee"
| intel/e7525
| ?
| —
|- bgcolor="#eeeeee"
| intel/i3100
| ?
| —
|- bgcolor="#eeeeee"
| intel/i440bx
| ?
| —
|- bgcolor="#eeeeee"
| intel/i82810
| ?
| —
|- bgcolor="#eeeeee"
| intel/i82830
| ?
| —
|- bgcolor="#eeeeee"
| intel/i855
| ?
| —
|- bgcolor="#eeeeee"
| intel/i945
| style="background:lime" | Y
| Tested on Kontron 986LCD-M and Roda RK886EX
|- bgcolor="#eeeeee"
| via/cn400
| ?
| —
|- bgcolor="#eeeeee"
| via/cn700
| style="background:lime" | Y
| Tested on VIA pc2500e.
|- bgcolor="#eeeeee"
| via/cx700
| ?
| —
|- bgcolor="#eeeeee"
| via/vt8601
| ?
| —
|- bgcolor="#eeeeee"
| via/vt8623
| ?
| —
|- bgcolor="#eeeeee"
| via/vx800
| ?
| —

|}

'''Developers:''' Stefan

== CBFS ==

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

'''Status:'''

Upstream, pre-CBFS infrastructure removed.

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

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

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

{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
! align="left" | Vendor/chipset
! align="left" | ROM enabled
! align="left" | Tiny bootblock
! align="left" | Status / Comments

|- bgcolor="#eeeeee"
| amd/amd8111
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.
|- bgcolor="#eeeeee"
| amd/cs5530
| style="background:lime" | Y
| style="background:red" | N
| Not tested on hardware, yet.
|- bgcolor="#eeeeee"
| amd/cs5535
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| amd/cs5536
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| amd/sb600
| style="background:lime" | Y
| style="background:lime" | Y
| Build- and runtime-tested on siemens/sitemp_g1p1 by [[User:PatrickGeorgi|PatrickGeorgi]].
|- bgcolor="#eeeeee"
| amd/sb700
| style="background:yellow" | Y
| style="background:yellow" | Y
| —

|- bgcolor="#dddddd"
| broadcom/bcm5785
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#eeeeee"
| intel/esb6300
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i3100
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82371eb
| style="background:lime" | Y
| style="background:yellow" | Y
| Build- and runtime-tested on ASUS P2B by [[User:Uwe|Uwe Hermann]].
|- bgcolor="#eeeeee"
| intel/i82801ax
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801bx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801cx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801dx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801ex
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801gx
| style="background:lime" | Y
| style="background:lime" | Y
| Build- and runtime-tested on Kontron 986LCD-m by PatrickGeorgi

|- bgcolor="#dddddd"
| nvidia/ck804
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.
|- bgcolor="#dddddd"
| nvidia/mcp55
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#dddddd"
| sis/sis966
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#eeeeee"
| via/vt8231
| style="background:yellow" | Y
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| via/vt8235
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| via/vt8237r
| style="background:yellow" | Y
| style="background:yellow" | Y
| —
|- bgcolor="#eeeeee"
| via/vt82c686
| style="background:red" | N
| style="background:red" | N
| —

|}

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

== Tiny Bootblock ==

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

'''Status:''' Available in Kconfig, works on a couple of boards. Requires per southbridge changes (and northbridge in some cases) on many boards (related to ROM enable, see CBFS section).

'''Developers:''' Patrick

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

'''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 ==
* Figure out generic ACPI code and deduplicate it.
* Fix issues like http://www.coreboot.org/pipermail/coreboot/2011-May/065179.html

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.

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

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

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

408/512 some_string string

984/16 checksum checksum 392 983
</code>

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

=== CMOS defaults ===
Allow (somehow) to define defaults for all CMOS fields, and create a static table from that. Use that at runtime if the CMOS checksum fails.
In the above format, it could simply be a suffix <code>default=VALUE</code>
Also drop the "default" argument in get_options. As components have their own cmos.layout snippets, we can always take those definitions' defaults, even if mainboards don't make use of CMOS themselves.

=== Value overrides ===
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 ===
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)

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

=== Checksums ===

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.

== Global variables ==

* Make use of global variables where appropriate.

Done:
* Provide v3 style global variables framework

= More ideas =

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

== Add a config for selecting a SeaBIOS git revision ==
Currently there is only the choice between coreboot master and the lastest stable revision.

= Finished =

== Port v3 Resource Allocator ==

The v3 resource allocator should be ported to v4.

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

'''Developers:''' Myles

== Config & Build System ==

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

'''Status:''' Upstream, boards are converted. Old system is gone. All boards build. HOWEVER, not all boards have been boot-tested yet, please report any issues you encounter!

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

== Unify text printing functions ==

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

'''Status:''' Finished.

'''Developers:''' Patrick, Stefan

== Common payload location ==

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

'''Status:''' Finished.

== Fix ALL build warnings ==

* Someone has to do the deed.

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

== Post codes ==

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

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

== Use central oprom init ==

* Get rid of all vgabios.c, make all chipsets with own vgabios.c use devices/oprom/x86.c.
* Use the realmode code for vsmsetup too.

== Use nvramtool for static option table creation ==

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.

'''Status:''' Finished, upstream.

'''Developers:''' Vikram

== Local APIC addresses ==

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

* LAPIC_ADDR
* LOCAL_APIC_ADDR (even twice)
* LAPIC_DEFAULT_BASE

This should be unified.

'''Developers:''' Patrick

== printk into buffer ==

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

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

'''Developers:''' ChromiumOS Team

== USB Debug Console ==

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

'''Developers:''' SvenS

Supported Motherboards

2012-10-13T09:12:55Z

PatrickGeorgi: /* Motherboards supported in coreboot v4 */ Filled in EPIA MII data

{| border="0" valign="top" width="100%"
| valign="top"|
See the page [[Confirmed working svn revisions]] for a table of which revision to start testing with on your particular mainboard. Click on the Status column bellow to learn more info about the board.

'''coreboot v4''' is the current stable coreboot tree recommended for productive use and for porting new boards. For AMD Geode LX targets, '''coreboot v3''' might be better than coreboot v4 in some minor aspects, but most features should be ported to v4 by now.
* If a mainboard is not supported by coreboot v4, try [[Supported_Motherboards#Motherboards_supported_in_coreboot_v1|checking coreboot v1]] or [[Supported_Motherboards#Motherboards_supported_in_coreboot_v3|coreboot v3]] for support.
* However, in general it is '''not''' recommended to use coreboot v3 — this was an experimental development tree which is gradually being merged into v4.
* Also, coreboot v1 should be avoided (if v4 can be used instead for your board), as it has been unmaintained for a long time. It is definately desirable to port boards from v1 to v4 whereever possible.

See also [[Supported Chipsets and Devices|Supported Chipsets & Devices]].

<blockquote>
'''Warning''': here, "supported" means someone got it to work. It is not a guarantee that coreboot will successfully boot on any particular device. You should only compile and flash coreboot if you are prepared to deal with your device being bricked. That means having an [[Developer Manual/Tools|external programmer]] and possibly a soldering iron.
</blockquote>

| valign="top" align="right"|

'''Color Legend'''
{| border="1" style="font-size: smaller"
|- bgcolor="#eeeeee"
| style="background:red" | Motherboard is work in progress, unfinished, or on hold.
|-
| style="background:yellow" | Motherboard mostly works, but some issues remain.
|-
| style="background:lime" | Motherboard is fully supported.
|}

|}

== Motherboards supported in coreboot v4 ==

{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
! align="left" | Vendor
! align="left" | Mainboard
! align="left" | Status
! align="left" | Northbridge
! align="left" | Southbridge
! align="left" | Super I/O
! align="left" | CPU
! align="left" | Socket
! align="left" | ROM 35
! align="left" | P 36
! align="left" | S 37
! align="left" | F 38
! align="left" | VCS4

|- bgcolor="#6699ff"
| colspan="13" | <h4>Desktops / Workstations</h4>

|- bgcolor="#dddddd"
| Abit
| [http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODEL_NAME=BE6-II+V2.0&fMTYPE=Slot+1 Abit BE6-II V2.0]
| style="background:lime" | OK
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977EF
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| ?
| —
| —

|- bgcolor="#eeeeee"
| Arima
| [http://www.advantech.com.tw/epc/newsletter/v27-07-01_00/PCM-5820.htm PCM 5820]
| style="background:lime" | [[Advantech_PCM-5820|OK...]]
| AMD GX1
| AMD® CS5530
| Winbond™ W83977F
| AMD Geode™ GX1
| -
| DIP8
| SPI
| ?
| Y
| —

|- bgcolor="#eeeeee"
| ASRock
| [http://www.asrock.com/mb/overview.asp?Model=939A785GMH/128M&s=939 939A785GMH/128M]
| style="background:lime" | [[ASRock 939A785GMH-128M|OK...]]
| AMD K8
| AMD® RS785/SB710
| Winbond™ W83627DHG
| AMD Athlon™ 64 / FX / X2
| Socket 939
| DIP8
| SPI
| ?
| ?
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com.tw/products.aspx?l1=3&l2=15&l3=171&l4=0&model=455&modelmenu=2 A8N-E]
| style="background:lime" | [[ASUS A8N-E|OK...]]25
| AMD K8
| NVIDIA CK8046
| ITE IT8712F
| AMD Athlon™ 64 / FX / X2
| Socket 939
| PLCC
| ?
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com/product.aspx?P_ID=J9FKa8z2xVId3pDK A8N-SLI]
| style="background:lime" | [[ASUS_A8N-SLI|OK...]]25
| AMD K8
| NVIDIA CK8046
| ITE IT8712F
| AMD Athlon™ 64 / FX / X2
| Socket 939
| PLCC
| ?
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com/products.aspx?modelmenu=1&model=596&l1=3&l2=15&l3=207 A8N5X]
| style="background:lime" | [[ASUS A8N5X|OK...]]25
| AMD K8
| NVIDIA CK8046
| ITE IT8712F
| AMD Athlon™ 64 / FX / X2
| Socket 939
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com.tw/products.aspx?l1=3&l2=15&l3=143&l4=0&model=576&modelmenu=1 A8V-E SE]
| style="background:lime" | [[ASUS A8V-E SE|OK...]]
| AMD K8
| VIA K8T890 / VT8237R
| Winbond™ W83627EHG
| AMD Athlon™ 64 / FX / X2
| Socket 939
| PLCC
| LPC
| style="background:lime" | Y
| style="background:lime" | Y
| —
|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com.tw/products.aspx?l1=3&l2=15&l3=143&l4=0&model=376&modelmenu=1 A8V-E Deluxe]
| style="background:lime" | [[ASUS A8V-E Deluxe|OK...]]
| AMD K8
| VIA K8T890 / VT8237R
| Winbond™ W83627EHG
| AMD Athlon™ 64 / FX / X2
| Socket 939
| PLCC
| ?
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com/products.aspx?l1=3&l2=101&l3=496&l4=0&model=1568&modelmenu=1 M2A-VM]
| style="background:lime" | [[ASUS M2A-VM|OK...]]
| AMD 690G
| ATI SB600
| ITE™ IT8716F
| AMD Sempron™ / Athlon™ 64 / FX / X2
| Socket AM2(+)
| PLCC
| LPC
| style="background:red" | N
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com/product.aspx?P_ID=NFlvt10av3F7ayQ9 M2N-E]
| style="background:lime" | [[ASUS M2N-E|OK...]]
| AMD K8
| NVIDIA MCP55
| ITE™ IT8716F
| AMD Athlon™ 64 / FX / X2 / Phenom
| Socket AM2
| PLCC
| LPC
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com/product.aspx?P_ID=OqYlEDFfF6ZqZGvp M2V]
| style="background:lime" | [[ASUS M2V|OK...]]
| AMD K8
| VIA K8T890CF / VT8237A
| ITE™ IT8712F
| AMD Athlon™ 64 / FX / X2
| Socket AM2
| PLCC
| LPC
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com/products.aspx?l1=3&l2=101&l3=324&l4=0&model=1807&modelmenu=1 M2V-MX SE]
| style="background:lime" | [[ASUS M2V-MX SE|OK...]]
| AMD K8
| VIA K8M890 / VT8237S
| ITE™ IT8712F
| AMD Athlon™ 64 / FX / X2
| Socket AM2
| DIP8
| SPI
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com/product.aspx?P_ID=ef0qgvMIwOUagAVl M4A785-M]
| style="background:yellow" | [[ASUS M4A785-M|WIP...]]
| AMD Fam10h
| AMD RS780/SB700
| ITE™ IT8712F
| AMD Athlon™ 64 / FX / X2
| Socket AM3/AM2(+)
| DIP8
| SPI
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com/Motherboards/AMD_AM3/M4A785TM/ M4A785T-M]
| style="background:lime" | [[ASUS M4A785T-M|OK...]]
| AMD Fam10h
| AMD RS780/SB700
| ITE™ IT8712F
| AMD Athlon™ 64 / FX / X2
| Socket AM3
| DIP8
| SPI
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com/Motherboards/AMD_AM3/M4A78LTM/ M4A78LT-M]
| style="background:red" | [[ASUS M4A78LT-M|WIP...]]
| AMD Fam10h
| AMD RS780/SB700
| ITE™ IT8712F
| AMD Athlon™ 64 / FX / X2
| Socket AM3
| DIP8
| SPI
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com/product.aspx?P_ID=0KyowHKUFAQqH2DO M4A78-EM]
| style="background:lime" | [[ASUS M4A78-EM|OK...]]
| AMD Fam10h
| AMD RS780/SB700
| ITE™ IT8712F
| AMD Athlon™ 64 / FX / X2
| Socket AM3/AM2(+)
| DIP8
| SPI
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.asus.com/Motherboards/AMD_AM3Plus/M5A88V_EVO/ M5A88-V]
| style="background:lime" | [[ASUS M5A88V|OK...]]
| AMD Fam10h
| AMD 880G/850
| ITE™ IT8721F
| AMD Athlon™Phenom™Sempron™ 64 / FX / X2
| Socket AM3/AM3+
| DIP8
| SPI
| style="background:lime" | Y
| style="background:lime" | Y
| —


|- bgcolor="#dddddd"
| ASUS
| [ftp://ftp.asus.com.tw/pub/ASUS/mb/sock370/810/mew-am/ MEW-AM]
| style="background:lime" | [[ASUS MEW-AM|OK...]]
| Intel® 82810
| Intel® 82801AA (ICH)
| SMSC® LPC47B272
| Intel® Pentium® III / Celeron®
| Socket 370
| PLCC
| ?
| style="background:lime" | Y
| style="background:red" | N
| —

|- bgcolor="#dddddd"
| ASUS
| [http://www.elhvb.com/mboards/OEM/HP/manual/ASUS%20MEW-VM.htm MEW-VM]
| style="background:yellow" | WIP28
| Intel® 82810
| Intel® 82801AA (ICH)
| SMSC® LPC47B272
| Intel® Pentium® III / Celeron®
| Socket 370
| PLCC
| ?
| style="background:lime" | Y
| style="background:red" | N
| —

|- bgcolor="#dddddd"
| ASUS
| [ftp://ftp.asus.com.tw/pub/ASUS/mb/slot1/440bx/p2b/ P2B]
| style="background:lime" | [[ASUS P2B|OK...]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977TF
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [ftp://ftp.asus.com.tw/pub/ASUS/mb/slot1/440bx/p2b-f/ P2B-F]
| style="background:lime" | [[ASUS P2B-F|OK...]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977EF
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [ftp://ftp.asus.com.tw/pub/ASUS/mb/slot1/440bx/p2b-d/ P2B-D]
| style="background:lime" | [[ASUS P2B-D|OK...]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977TF
| Intel® Pentium® II/III, Celeron®
| 2x Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [ftp://ftp.asus.com.tw/pub/ASUS/mb/slot1/440bx/p2b-ds/ P2B-DS]
| style="background:lime" | [[ASUS P2B-DS|OK...]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977TF
| Intel® Pentium® II/III, Celeron®
| 2x Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [ftp://ftp.asus.com.tw/pub/ASUS/mb/slot1/440bx/p2b-ls/ P2B-LS]
| style="background:lime" | [[ASUS P2B-LS|OK...]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977EF
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASUS
| [ftp://ftp.asus.com.tw/pub/ASUS/mb/slot1/440bx/p3b-f/ P3B-F]
| style="background:lime" | [[ASUS P3B-F|OK...]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977EF
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#eeeeee"
| A-Trend
| [http://www.motherboard.cz/mb/atrend/atc6220.htm ATC-6220]
| style="background:lime" | [[A-Trend ATC-6220|OK...]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977TF
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#eeeeee"
| A-Trend
| [http://active-hardware.com/english/reviews/mainboard/atc6240.htm ATC-6240]
| style="background:lime" | OK
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83627HF
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Avalue
| [http://www.avalue.com.tw/products/EAX-785E.cfm EAX-785E]
| style="background:lime" | [[Avalue_EAX_785E|OK...]]
| AMD Family 10h
| AMD® RS785E(RS880M)/SB850M
| Nuvoton™ W83627DHG-P FINTEK™ F81216AD
| AMD Phenom II™ 
| AM3
| SOIC-8
| SPI
| N
| ?
| —

|- bgcolor="#dddddd"
| AZZA
| [http://web.tiscali.it/acorp/?http://web.archive.org/web/20050426181911/http://web.tiscali.it/acorp/mobo_spec/azza/pt-6ibd/pt-6ibd.htm PT-6IBD]
| style="background:lime" | [[AZZA PT-6IBD|OK...]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977EF
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Biostar
| [http://www.motherboard.cz/mb/biostar/M6TBA.htm M6TBA]
| style="background:lime" | [[Biostar M6TBA|OK...]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| SMSC FDC37M60x
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| style="background:red" | N
| —

|- bgcolor="#dddddd"
| Compaq
| Deskpro EN SFF P600
| style="background:lime" | OK
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| NSC PC97307
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| ?
| ?
| —


|- bgcolor="#eeeeee"
| ECS
| [http://www.ecs.com.tw/ECSWebSite/Product/Product_Detail.aspx?CategoryID=1&DetailID=95&DetailName=Feature&MenuID=24&LanID=4 P6IWP-Fe]
| style="background:lime" | [[ECS P6IWP-Fe|OK]]
| Intel® 82810
| Intel® 82801AA (ICH)
| ITE IT8712F
| Intel® Pentium® III / Celeron®
| Socket 370
| PLCC
| FWH
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| GIGABYTE
| [http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=1445 GA-6BXC]
| style="background:lime" | [[GIGABYTE GA-6BXC|OK...]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| ITE IT8671F
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| —| GIGABYTE
| [http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=1430 GA-6BXE]
| style="background:lime" | [[GIGABYTE GA-6BXE|OK...]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| ITE IT8671F
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| GIGABYTE
| [http://www.computerbase.de/news/hardware/mainboards/amd-systeme/2007/mai/gigabyte_dtx-mainboard/ GA-2761GXDK] (Churchill)
| style="background:lime" | [[GIGABYTE GA-2761GXDK|OK...]]
| AMD K8
| SiS761GX/SiS966
| ITE IT8716F
| AMD Sempron™ / Athlon™ 64 / FX / X2 (?)
| Socket AM2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| GIGABYTE
| [http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2287&ModelName=GA-M57SLI-S4 GA-M57SLI-S4]
| style="background:lime" | [[GIGABYTE GA-M57SLI-S4|OK...]]
| AMD K8
| NVIDIA MCP55
| ITE IT8716F
| AMD Sempron™ / Athlon™ 64 / FX / X2
| Socket AM2
| ?
| ?
| style="background:red" | N
| style="background:lime" | Y
| style="background:yellow; text-align:center" | [[Gigabyte m57sli Vendor Cooperation Score|3]]

|- bgcolor="#dddddd"
| GIGABYTE
| [http://www.gigabyte.com/products/product-page.aspx?pid=3274 GA-MA785GMT-UD2H]
| style="background:lime" | [[GIGABYTE GA-MA785GMT-UD2H|OK...]]
| AMD Fam10h
| AMD 785G / SB710
| ITE IT8718F
| AMD Phenom™ II / Athlon™ II
| Socket AM3
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| GIGABYTE
| [http://www.gigabyte.com/products/product-page.aspx?pid=2995 GA-MA78GM-US2H]
| style="background:lime" | OK
| AMD Fam10h
| AMD 780G / SB700
| ITE IT8718F
| AMD Phenom™ / Athlon™ / Sempron™
| Socket AM2+
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| HP
| e-Vectra P2706T
| style="background:lime" | OK
| Intel 82810E
| Intel 82801AA (ICH)
| NSC PC87364
| Intel® Pentium® III / Celeron®
| PGA370
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Intel
| [http://support.gateway.com/s/MOTHERBD/INTEL/2514906/2514906nv.shtml D810E2CB]
| style="background:lime" | [[Intel D810E2CB|OK...]]
| Intel® 82810E
| Intel® 82801BA (ICH2)
| SMSC LPC47M102
| Intel® Pentium® III / Celeron®
| Socket 370
| PLCC
| FWH
| N
| ?
| —

|- bgcolor="#dddddd"
| Intel
| [http://www.intel.com/Products/Desktop/Motherboards/D945GCLF/D945GCLF-overview.htm D945GCLF]
| style="background:red" | WIP44
| Intel® 945GC
| Intel® 82801GB (ICH7)
| SMSC LPC47M15x
| Intel® Atom™ 230
| Socket 441
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Jetway
| [http://www.jetway.com.tw/jw/motherboard_view.asp?productid=567&proname=PA78VM5 PA78VM5]
| style="background:lime" | [[Jetway PA78VM5|OK...]]
| AMD® Fam10h
| AMD® RS780/SB700
| Fintek F71863FG
| ?
| Socket AM2(+)
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Lanner
| em8510
| style="background:lime" | [[Lanner em8510|OK...]]
| Intel® I855
| Intel® I82801DX
| Winbond W83627THG
| ?
| Socket 479
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Mitac
| [http://web.archive.org/web/20050313054828/http://www.mitac.com/micweb/products/tyan/6513wu/6513wu.htm 6513WU]
| style="background:lime" | [[Mitac 6513WU|OK...]]
| Intel® 82810E
| Intel® 82801AB (ICH0)
| SMSC LPC47U332
| Intel® Pentium® III / Celeron®
| Socket 370
| PLCC
| ?
| ?
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| MSI
| [http://global.msi.com.tw/index.php?func=proddesc&prod_no=332&maincat_no=1 MS-6119]
| style="background:lime" | OK
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977TF
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| ?
| ?
| —

|- bgcolor="#dddddd"
| MSI
| [http://global.msi.com.tw/index.php?func=proddesc&maincat_no=1&prod_no=335 MS-6147]
| style="background:lime" | OK
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977TF
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| ?
| —

|- bgcolor="#dddddd"
| MSI
| [http://uk.ts.fujitsu.com/rl/servicesupport/techsupport/Boards/Motherboards/MicroStar/Ms6156/MS6156.htm MS-6156]
| style="background:lime" | OK
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977TF
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| MSI
| [http://www.msi-technology.de/index.php?func=proddesc&prod_no=343&maincat_no=1 MS-6178]
| style="background:lime" | [[MSI MS-6178|OK...]]
| Intel® 82810
| Intel® 82801AB (ICH0)
| Winbond™ W83627HF
| Intel® Pentium® III / Celeron®
| Socket 370
| PLCC
| ?
| style="background:lime" | Y
| ?
| —

|- bgcolor="#dddddd"
| MSI
| [http://global.msi.com.tw/index.php?func=proddesc&prod_no=170&maincat_no=1 MS-7135 (K8N Neo3)]
| style="background:lime" | [[MSI MS-7135|OK...]]
| AMD K8
| NVIDIA CK8046
| Winbond® W83627THF
| AMD Sempron™ / Athlon™ 64 / Turion™ 64
| Socket 754
| PLCC
| LPC
| style="background:yellow" | ...29
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| MSI
| [http://global.msi.com.tw/index.php?func=proddesc&prod_no=255&maincat_no=1&cat2_no=171 MS-7260 (K9N Neo)]
| style="background:lime" | [[MSI MS-7260|OK...]]
| AMD K8
| NVIDIA MCP55
| Winbond™ W83627EHG
| AMD Sempron™ / Athlon™ 64 / X2
| Socket AM2
| PLCC
| ?
| style="background:lime" | Y
| style="background:yellow" | ...39
| —

|- bgcolor="#eeeeee"
| NEC
| [http://support.necam.com/mobilesolutions/hardware/Desktops/pm2000/celeron/ PowerMate 2000]
| style="background:lime" | [[NEC PowerMate 2000|OK...]]
| Intel® 82810
| Intel® 82801AB (ICH0)
| SMSC® LPC47B27x
| Intel® Pentium® III / Celeron®
| Socket 370
| ?
| ?
| style="background:red" | N
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| Shuttle
| [http://global.shuttle.com/product_detail.jsp?PI=89 SN25P]
| style="background:red" | [[Shuttle SN25P|WIP...]]
| AMD K8
| NVIDIA CK8046
| ITE IT8712F
| AMD Sempron™ / Athlon™ 64 / X2 / Opteron™ 1XX
| Socket 939
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Soyo
| Soyo SY-6BA+ III
| style="background:lime" | [[Soyo SY-6BA Plus III|OK]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| ITE IT8671F
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| Sun
| [http://www.sun.com/desktop/workstation/ultra40/index.xml Ultra 40]
| style="background:lime" | OK
| AMD K8
| NVIDIA CK8045
| SMSC® LPC47B397
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Tyan
| [http://www.tyan.com/archive/products/html/tsunamiatx.html Tsunami ATX (S1846)]
| style="background:lime" | OK
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| NSC PC87309
| Intel® Pentium® II/III, Celeron®
| Slot 1
| DIP32
| Parallel
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#eeeeee"
| Tyan
| [http://www.tyan.com/archive/products/html/tigerk8w.html Tiger K8W (S2875)]
| style="background:lime" | OK
| AMD K8
| AMD-8111™, 8151™
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Tyan
| [http://www.tyan.com/archive/products/html/thunderk8w.html Thunder K8W (S2885)]
| style="background:lime" | OK
| AMD K8
| AMD-8111™, 8131™, 8151™
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Tyan
| [http://www.tyan.com/archive/products/html/thunderk8we.html Thunder K8WE (S2895)]
| style="background:lime" | OK
| AMD K8
| AMD-8131™, NVIDIA CK8045
| SMSC® LPC47B397
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Winent
| [http://www.win-ent.com/network-computing/network-systems/desktop-platforms/440-pl-60640.html PL60640]
| style="background:lime" | OK
| AMD LX
| AMD CS5536
| Winbond W83627HF
| AMD Geode™
| ?
| ?
| ?
| ?
| ?
| —

|- bgcolor="#6699ff"
| colspan="13" | <h4>Servers</h4>

|- bgcolor="#dddddd"
| AMD
| Serengeti Cheetah
| style="background:lime" | OK
| AMD K8
| AMD-8111™, 8151™, 8132™
| Winbond™ W83627HF
| AMD Opteron™
| Socket F
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| AMD
| Serengeti Cheetah
| style="background:lime" | OK
| AMD Fam10h
| AMD-8111™, 8151™, 8132™
| Winbond™ W83627HF
| AMD Opteron™
| Socket F
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Arima
| [http://web.archive.org/web/20080127024444/http://www.arima.com.tw/server/Product/ViewProduct.asp?View=HDAMA HDAMA]
| style="background:lime" | OK
| AMD K8
| AMD-8111™, 8131™
| NSC PC87360
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Dell
| [http://support.dell.com/support/edocs/systems/pe1850/en/index.htm PowerEdge 1850]
| style="background:yellow" | WIP2
| Intel® E7520
| Intel® 82801ER (ICH5R)
| Winbond™ W83627HF
| Intel® Xeon®
| Socket 604
| ?
| ?
| ?
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| HP
| [http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c00346784&prodTypeId=15351&prodSeriesId=3219755 ProLiant DL145 G1]
| style="background:lime" | [[HP DL145 G3|OK]]
| AMD K8
| AMD-8111™, 8131™
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| PLCC
| LPC
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| HP
| [http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c00816835&lang=en&cc=us&taskId=101&prodSeriesId=3219755&prodTypeId=15351 ProLiant DL145 G3]
| style="background:lime" | [[HP DL145 G3|OK]]
| AMD K8
| Broadcom BCM5785/5780
| NSC PC87417
| AMD Opteron™
| Socket F
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| HP
| [http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c01765799 ProLiant DL165 G6]
| style="background:lime" | [[HP DL165 G6|OK]]
| AMD Fam10h
| Broadcom BCM5785
| NSC PC87417
| AMD Opteron™
| Socket F 1207
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| IBM
| [http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=ibm&lndocid=MIGR-53255 eServer 325]
| style="background:lime" | OK
| AMD K8
| AMD-8111™, 8131™
| NSC PC87366
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| IBM
| [http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=ibm&lndocid=MIGR-58655 eServer 326]
| style="background:lime" | OK
| AMD K8
| AMD-8111™, 8131™
| NSC PC87366
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Intel
| [http://www.intel.com/support/motherboards/server/se7520jr2/ Jarrell (SE7520JR2)]
| style="background:#dddddd" | ?
| Intel® E7520
| Intel® 82801ER (ICH5R)
| NSC PC87427
| Intel® Xeon®
| ?
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| IWILL
| [http://web.archive.org/web/20060507170150/http://www.iwill.net/product_2.asp?p_id=98 DK8-HTX]
| style="background:lime" | [[IWILL DK8-HTX|OK...]]
| AMD K8
| AMD-8111™, 8131™
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| style="background:lime" | Y
| —

|- bgcolor="#eeeeee"
| IWILL
| [http://web.archive.org/web/20060509143427/http://www.iwill.net/product_2.asp?p_id=42&sp=Y DK8S2]
| style="background:#eeeeee" | ?
| AMD K8
| AMD-8111™, 8131™
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| IWILL
| [http://web.archive.org/web/20060213163325/http://www.iwill.net/product_2.asp?p_id=28 DK8X]
| style="background:#eeeeee" | ?
| AMD K8
| AMD-8111™, 8131™
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| MSI
| [http://www.msiserver.de/de/Produkte/Server_Mainboards/K9SD_Master_S2R_MS_9185.aspx K9SD Master-S2R (MS-9185)]
| style="background:lime" | OK12
| AMD K8
| Broadcom BCM5785/5780
| NSC PC87417
| AMD Opteron™
| Socket F
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| MSI
| [http://cweb.msi.com.tw/program/products/server/svr/pro_svr_detail.php?UID=632 K9SD Master (MS-9282)]
| style="background:lime" | OK15
| AMD K8
| NVIDIA MCP55
| Winbond™ W83627EHG
| AMD Opteron™
| Socket F
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Newisys
| [http://web.archive.org/web/20070922231423/http://www.newisys.com/core/2100e.html 2100 Server] (SUN Fire v20z)
| style="background:lime" | OK7
| AMD K8
| AMD-8111™, 8131™
| NSC PC87360
| AMD Opteron™
| Socket F
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Nokia
| [[Nokia IP530|IP530]]
| style="background:yellow" | [[Nokia IP530|WIP2]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| SMSC® FDC37B787
| Intel® Pentium® III-800, Celeron®
| Socket 370
| TSOP48
| Parallel
| style="background:lime" | N
| style="background:lime" | Y
| —

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/Aplus/motherboard/Opteron2000/MCP55/H8DMR-i2.cfm H8DMR-i2]
| style="background:lime" | OK
| AMD K8
| NVIDIA MCP55
| Winbond™ W83627EHG
| AMD Opteron™
| Socket F
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/Aplus/motherboard/Opteron8000/MCP55/H8QME-2.cfm H8QME-2+]
| style="background:lime" | OK
| AMD Fam10h
| AMD 8132™
| Winbond™ W83627HF
| AMD Opteron™
| Socket F
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/Aplus/motherboard/Opteron2000/MCP55/H8DMR-i2.cfm H8DMR-i2]
| style="background:lime" | OK
| AMD Fam10h
| NVIDIA MCP55
| Winbond™ W83627EHG
| AMD Opteron™
| Socket F
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/Aplus/motherboard/Opteron2000/MCP55/H8DME-2.cfm H8DME-2]
| style="background:lime" | OK41
| AMD K8
| NVIDIA MCP55
| Winbond™ W83627EHG
| AMD Opteron™
| Socket F
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/aplus/motherboard/opteron4000/sr56x0/h8scm.cfm H8SCM]
| style="background:lime" | [[Supermicro_H8SCM|OK...]]
| AMD Fam15h&Fam10h
| AMD® SR5690/SP5100
| Winbond™ W83527DHG
| AMD Opteron™ Magny-Cours/Interlagos
| Socket C32
| SOIC-8
| SPI
| style="background:red" |N
| ?
| —

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi_-F.cfm H8QGI+-F]
| style="background:lime" | [[Supermicro_H8QGI|OK...]]
| AMD Fam15h&Fam10h
| AMD® SR5690/SP5100
| Winbond™ W83527DHG
| AMD Opteron™ Magny-Cours/Interlagos
| Socket G34
| SOIC-8
| SPI
| style="background:red" |N
| ?
| —

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/products/motherboard/xeon1333/5000p/x7db8_.cfm X7DB8+]
| style="background:lime" | [[Supermicro_X7DB8+|OK...]]
| Intel 5000
| Intel® ESB2
| Winbond™ W83627HF
| Intel Xeon™ 5000 series
| Dual Socket LGA771
| PLCC32
| FWH
| style="background:lime" |Y
| ?
| —

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/products/motherboard/Xeon800/E7525/X6DAi-G.cfm X6DAi-G]
| style="background:#eeeeee" | ?
| Intel® E7525
| Intel® E7525, ESB6300
| Winbond™ W83627HF
| Intel® Xeon®
| Socket 604
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/products/motherboard/Xeon800/E7525/X6DAi-G.cfm X6DHE-G]
| style="background:#eeeeee" | ?
| Intel® E7520
| Intel® E7520, ESB6300
| Winbond™ W83627HF
| Intel® Xeon®
| Socket 604
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/products/motherboard/Xeon800/E7520/X6DHE-G2.cfm X6DHE-G2]
| style="background:#eeeeee" | ?
| Intel® E7520
| Intel® 82801ER (ICH5R), ESB6300
| NSC PC87427
| Intel® Xeon®
| Socket 604
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/products/motherboard/Xeon800/E7520/X6DHR-iG.cfm X6DHR-iG]
| style="background:#eeeeee" | ?
| Intel® E7520
| Intel® 82801ER (ICH5R)
| Winbond™ W83627HF
| Intel® Xeon®
| Socket 604
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/products/motherboard/Xeon800/E7520/X6DHR-iG2.cfm X6DHR-iG2]
| style="background:#eeeeee" | ?
| Intel® E7520
| Intel® 82801ER (ICH5R)
| Winbond™ W83627HF
| Intel® Xeon®
| Socket 604
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/tigeri7501r.html Tiger i7501R (S2735)]
| style="background:lime" | OK
| Intel® E7501
| Intel® 82801ER (ICH5R)
| Winbond™ W83627HF
| Intel® Xeon®
| Socket 604
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/tomcatk8s.html Tomcat K8S (S2850)]
| style="background:lime" | OK
| AMD K8
| AMD-8111™
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/thunderk8s.html Thunder K8S (S2880)]
| style="background:lime" | OK
| AMD K8
| AMD-8111™, 8131™
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/thunderk8sr.html Thunder K8SR (S2881)]
| style="background:lime" | [[Tyan S2881|OK...]]
| AMD K8
| AMD-8111™, 8131™
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/thunderk8spro.html Thunder K8S Pro (S2882)]
| style="background:lime" | [[Tyan S2882|OK...]]20
| AMD K8
| AMD-8111™, 8131™
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/thunderk8sre.html Thunder K8SRE (S2891)]
| style="background:lime" | [[Tyan S2891|OK...]]
| AMD K8
| AMD-8131™, NVIDIA CK8041
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/thunderk8se.html Thunder K8SE (S2892)]
| style="background:lime" | [[Tyan S2892|OK...]]
| AMD K8
| AMD-8131™, NVIDIA CK8041
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/product_board_detail.aspx?pid=157 Thunder n3600R (S2912)]
| style="background:lime" | [[Tyan S2912|OK...]]
| AMD K8
| NVIDIA MCP55
| Winbond™ W83627HF
| AMD Opteron™
| Socket F
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/product_board_detail.aspx?pid=157 Thunder n3600R (S2912)]
| style="background:lime" | [[Tyan S2912|OK...]]
| AMD Fam10h
| NVIDIA MCP55
| Winbond™ W83627HF
| AMD Opteron™
| Socket F
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/thunderk8qs.html Thunder K8QS (S4880)]
| style="background:lime" | OK
| AMD K8
| AMD-8111™, 8131™
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/thunderk8qspro.html Thunder K8QS Pro (S4882)]
| style="background:lime" | OK
| AMD K8
| AMD-8111™, 8131™
| Winbond™ W83627HF
| AMD Opteron™
| Socket 940
| ?
| ?
| ?
| ?
| —

|- bgcolor="#6699ff"
| colspan="13" | <h4>Laptops</h4>

|- bgcolor="#dddddd"
| Getac
| [http://en.getac.com/products/P470/P470_overview.html P470]
| style="background:lime" | OK
| Intel® 945
| Intel® ICH7
| SMSC® FDC37N972 + SIO10N268
| Intel® Core 2 Duo T7200
| ?
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Roda
| [http://www.roda-computer.com/en/products/notebooks/rocky-iii-rk886ex.html RK886EX (Rocky III+)]
| style="background:lime" | OK
| Intel® 945
| Intel® ICH7
| SMSC® LPC47N227
| Intel® Core 2 Duo Mobile T5500
| ?
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Lenovo
| X60/X60s
| style="background:yellow" | [[Lenovo x60x|OK...]]45
| Intel® 945
| Intel® ICH7
| NSC® PC87382/PC87392
| Intel® Core 2 Duo Mobile L7400
| ?
| SOIC-8
| SPI
| style="background:red" | N
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| Lenovo
| T60/T60p
| style="background:yellow" | [[Lenovo x60x|OK...]]45
| Intel® 945
| Intel® ICH7
| NSC® PC87382/PC87384
| Intel® Core 2 Duo T7200
| ?
| SOIC-8
| SPI
| style="background:red" | N
| style="background:lime" | Y
| —

|- bgcolor="#6699ff"
| colspan="13" | <h4>Embedded / SBC / PC/104 / Half-size boards</h4>

|- bgcolor="#eeeeee"
| Advantech
| [http://taiwan.advantech.com.tw/products/Model_Detail.asp?model_id=1-1TGZL8 PCM-5820]
| style="background:lime" | [[Advantech PCM-5820|OK...]]
| AMD GX1
| AMD CS5530A
| Winbond® W83977AF
| AMD Geode™ GX1
| —
| PLCC32
| ?
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| AMD
| Rumba
| style="background:lime" | OK
| AMD GX9
| AMD CS5536
| Winbond™ W83627HF
| AMD Geode™GX9
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| DIGITAL-LOGIC
| [http://www.digitallogic.com/english/products/datasheets/ecm855.asp smartModule855]
| style="background:red" | WIP13
| Intel® 855PM
| Intel® 82801DBM (ICH4-M)
| Winbond™ W83627HF
| ?
| ?
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| DIGITAL-LOGIC
| [http://www.digitallogic.ch/english/products/datasheets/ms_pc104_detail.asp?id=MSM586SEG MSM586SEG]
| style="background:yellow" | OK
| integrated
| integrated
| integrated
| AMD Élan™SC520
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| DIGITAL-LOGIC
| [http://www.digitallogic.ch/english/products/datasheets/ms_pc104_detail.asp?id=MSM800SEV MSM800SEV]
| style="background:lime" | OK22
| AMD Geode™ LX
| AMD Geode™ CS5536
| —
| AMD Geode™ LX
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| EagleLion
| 5BCM
| style="background:#dddddd" | ?
| AMD GX1
| AMD  CS5530
| NSC PC97317
| ?
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| IEI
| [http://www.icpamerica.com/products/single_board_computers/5_25_NOVA/NOVA-4899.html NOVA-4899R]
| style="background:yellow" | WIP17
| AMD GX1
| AMD Geode™ CS5530A
| Winbond™ W83977TF
| AMD Geode™ GX1
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| IEI
| [http://www.ieiworld.com/en/news_content.asp?id=erbium/projectOBJ00150613 JUKI-511P]
| style="background:lime" | [[IEI JUKI 511P|OK...]]27
| AMD GX1
| AMD Geode™ CS5530A
| Winbond™ W83977F
| AMD Geode™ GX1
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| IEI
| [http://www.google.com/url?sa=t&source=web&cd=1&sqi=2&ved=0CBkQFjAA&url=http%3A%2F%2Fwww.ieiworld.com%2Fproduct_groups%2Findustrial%2Fcontent.aspx%3Fgid%3D00001000010000000001%26cid%3D09050652111816087425%26id%3D09069696333360342284&ei=EG6XTYTrDJO8sQP82cHUBQ&usg=AFQjCNE0MTdh1PdU68MhsfFeVMTV7qYTPw Kino-780AM2]
| style="background:lime" | OK
| AMD Fam10h
| AMD 780G / SB700
| Fintek F71859
| AMD Phenom™ / Athlon™ / Sempron™
| Socket AM2+
| ?
| SPI
| ?
| ?
| —

|- bgcolor="#dddddd"
| IEI
| [http://www.ieiworld.com/en/product_IPC.asp?model=PCISA-LX IEI PCISA-LX-800-R10]
| style="background:lime" | [[IEI LX 800|OK...]]
| AMD LX
| AMD Geode™ CS5536
| Winbond™ W83627EHG
| AMD Geode™ LX
| —
| ?
| ?
| ?
| ?
| —
|- bgcolor="#dddddd"
| IEI
| [http://www.ieiworld.com/en/product_IPC.asp?model=ROCKY-512 ROCKY-512]
| style="background:lime" | [[IEI ROCKY 512|OK...]]27
| AMD GX1
| AMD Geode™ CS5530A
| Winbond™ W83977F
| AMD Geode™ GX1
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| IEI
| [http://www.ieiworld.com/product_groups/industrial/content.aspx?gid=00001000010000000001&cid=09050665574743104681&id=08142307826854456110#.UCLx8cLlgao PM-LX-800-R11]
| style="background:lime" | OK
| AMD LX
| AMD Geode™ CS5536
| Winbond™ W83627EHG
| AMD Geode™ LX
| —
| PLCC
| LPC
| Y
| Y
| —

|- bgcolor="#dddddd"
| iWave
| [http://www.iwavesystems.com/iW-RainbowG6.htm iW-RainboW-G6]
| style="background:lime" | OK
| Intel Poulsbo US15W
| Intel Poulsbo US15W
| —
| Intel Atom Z530/Z510
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| LiPPERT
| [http://www.lippertembedded.de/en/productoverview/products-in-detail/85-lipperts-cool-frontrunner.html Cool FrontRunner]
| style="background:red" | WIP2
| AMD GX9
| AMD CS5535
| Winbond™ W83627HF
| AMD Geode™ GX
| —
| PLCC
| FWH
| style="background:lime" | Y
| ?
| —

|- bgcolor="#eeeeee"
| LiPPERT
| [http://www.lippertembedded.de/en/lipperts-hurricane-lx800.html Hurricane-LX]
| style="background:lime" | OK
| AMD Geode™ LX
| AMD Geode™ CS5536
| ITE IT8712F
| AMD Geode™ LX
| —
| SOIC8
| SPI
| style="background:red" | N
| style="background:red" | N
| —

|- bgcolor="#eeeeee"
| LiPPERT
| [http://www.lippertembedded.de/en/lipperts-cool-literunner-lx800.html Cool LiteRunner-LX]
| style="background:lime" | OK
| AMD Geode™ LX
| AMD Geode™ CS5536
| ITE IT8712F
| AMD Geode™ LX
| —
| SOIC8
| SPI
| style="background:red" | N
| style="background:red" | N
| —

|- bgcolor="#eeeeee"
| LiPPERT
| [http://www.lippertembedded.de/en/lipperts-cool-roadrunner-lx800.html Cool RoadRunner-LX]
| style="background:lime" | OK
| AMD Geode™ LX
| AMD Geode™ CS5536
| ITE IT8712F
| AMD Geode™ LX
| —
| PLCC
| FWH
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#eeeeee"
| LiPPERT
| [http://www.lippertembedded.de/en/lipperts-cool-spacerunner-lx800.html Cool SpaceRunner-LX]
| style="background:lime" | OK
| AMD Geode™ LX
| AMD Geode™ CS5536
| ITE IT8712F
| AMD Geode™ LX
| —
| SOIC8
| SPI
| style="background:red" | N
| style="background:red" | N
| —

|- bgcolor="#dddddd"
| PC Engines
| [http://pcengines.ch/alix1c.htm ALIX.1C]
| style="background:lime" | [[PC Engines ALIX.1C|OK...]]
| AMD Geode™ LX
| AMD Geode™ CS5536
| Winbond® W83627HF
| AMD Geode™ LX
| —
| ?
| ?
| ?
| style="background:lime" | Y
| style="background:lime; text-align:center" | [[PC Engines ALIX.1C Vendor Cooperation Score|4]]

|- bgcolor="#dddddd"
| PC Engines
| [http://pcengines.ch/alix2d0.htm ALIX.2D]
| style="background:lime" | [[PC Engines ALIX.2D|OK...]]
| AMD Geode™ LX
| AMD Geode™ CS5536
| ?
| AMD Geode™ LX
| —
| ?
| ?
| ?
| style="background:lime" | Y
| ?

|- bgcolor="#eeeeee"
| TechNexion
| [http://www.technexion.com/index.php/embedded-mainboards/amd/tim-5690 TIM-5690]
| style="background:lime" | OK
| AMD M690E
| ATI SB600
| ITE IT8712F
| AMD Sempron
| Socket AM2(+)
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| TechNexion
| [http://www.technexion.com/index.php/tim-8690 TIM-8690]
| style="background:lime" | OK
| AMD M690E
| ATI SB600
| ITE IT8712F
| AMD Sempron™ / Athlon™ 64 / X2
| Socket AM2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Traverse Technologies
| [http://www.traverse.com.au/productview.php?product_id=117 Geos]
| style="background:lime" | OK
| AMD LX
| AMD Geode™ CS5536
| —
| AMD Geode™ LX
| —
| PLCC
| ?
| style="background:lime" | Y
| ?
| —

|- bgcolor="#eeeeee"
| TS31
| [http://www.embeddedarm.com/epc/ts5300-spec-h.html TS-5300]
| style="background:lime" | OK
| integrated
| integrated
| integrated
| AMD Élan™SC520
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#6699ff"
| colspan="13" | <h4>Mini-ITX / Micro-ITX / Nano-ITX</h4>

|- bgcolor="#eeeeee"
| Advansus
| [http://www.advansus.com.tw/products/247/A785E-I A785E-I]
| style="background:lime" | [[Advansus_A785E_I|OK...]]
| AMD Family 10h
| AMD® RS785E(RS880M)/SB820M
| Winbond™ W83627HF FINTEK™ F81216AD
| AMD Turion/Athlon II Neo  
| BGA-ASB2
| SOIC-8
| SPI
| N
| ?
| —

|- bgcolor="#eeeeee"
| ASRock
| [http://www.asrock.com/mb/overview.asp?Model=E350M1 E350M1]
| style="background:lime" | [[ASRock E350M1|OK...]]
| AMD Fam14h
| AMD® SB800
| Winbond™ W83627HF
| AMD Dual-Core Processor E-350
| BGA-413
| DIP8
| SPI
| ?
| ?
| —

|- bgcolor="#dddddd"
| ibase
| [http://www.ibase.com.tw/mb899.htm mb899]
| style="background:lime" | [[ibase mp899|OK...]]30
| Intel I945GM
| Intel I82801GX
| Winbond W83627EHG
| Intel® Core™
| ?
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Jetway
| [http://www.jetway.com.tw/jw/ipcboard_socket.asp?platid=16 J7F2]
| style="background:lime" | [[Jetway J7F2|OK...]]30
| VIA CN700
| VIA VT8237R(P)
| Fintek F71805F
| VIA C7™
| NanoBGA2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Jetway
| [http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=279&proname=J7F4K1G2E J7F4K1G2E]
| style="background:lime" | [[Jetway J7F4K1G2E|OK...]]30
| VIA CN700
| VIA VT8237R(P)
| Fintek F71805F
| VIA C7™
| NanoBGA2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Jetway
| [http://www.jetway.com.tw/jetway/system/productshow2.asp?id=389&proname=J7F4K1G5D J7F4K1G5D]
| style="background:lime" | [[Jetway J7F4K1G5D|OK...]]30
| VIA CN700
| VIA VT8237R(P)
| Fintek F71805F
| VIA C7™
| NanoBGA2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Kontron
| [http://de.kontron.com/products/boards+and+mezzanines/embedded+motherboards/miniitx+motherboards/986lcdmmitx.html 986LCD-M/mITX]
| style="background:lime" | [[Kontron 986LCD-M mITX|OK...]]
| Intel® 945
| Intel® ICH7
| 2x Winbond® W83627THG
| Intel® Core™ 2 Duo Mobile, Core™ Duo/Solo, Celeron® M
| mPGA478
| PLCC
| FWH
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| Kontron
| [http://us.kontron.com/products/boards+and+mezzanines/embedded+motherboards/miniitx+motherboards/kt690mitx.html KT690/mITX]
| style="background:lime" | OK
| AMD M690T
| ATI SB600
| Winbond™ W83627DHG
| AMD Turion64™ dual core / AMD Sempron
| Socket S1G1
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| MSI
| [http://global.msi.com.tw/index.php?func=proddesc&prod_no=1054&maincat_no=388# Fuzzy CN700]
| style="background:yellow" | [[MSI FUZZY CN700|WIP...]]30
| VIA CN700
| VIA VT8237R(P)
| Winbond™ W83627EHG
| VIA C7™
| NanoBGA2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| VIA
| [http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=21 EPIA]
| style="background:yellow" | [[EPIA|WIP...]]
| VIA VT8601
| VIA VT8231
| Winbond™ W83627HF
| VIA C3™, VIA EDEN™
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| VIA
| [http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=81 EPIA-M]
| style="background:lime" | [[VIA EPIA-M|OK...]]10
| VIA VT8623
| VIA VT8235
| VIA VT1211
| VIA C3™, VIA EDEN™
| Socket 370
| ?
| ?
| ?
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| VIA
| EPIA-M700
| style="background:red" | [[VIA EPIA-M700|WIP...]]
| VIA VX800
| VIA VX800
| Winbond W83697HF/F/HG
| ?
| ?
| SOIC8
| SPI
| style="background:red" | N
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| VIA
| [http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=202 EPIA-MII]
| style="background:lime" | [[VIA EPIA-MII|OK...]]8
| VIA VT8623
| VIA VT8235, Ricoh RL5C476
| VIA VT1211
| VIA C3™, VIA EDEN™
| Socket 370
| PLCC
| Parallel
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| VIA
| [http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=301 EPIA-ML]
| style="background:lime" | [[VIA EPIA-ML|OK...]]10
| VIA VT8623
| VIA VT8235
| VIA VT1211
| VIA C3™, VIA EDEN™
| Socket 370
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| VIA
| [http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=400 EPIA-CN10000EG]
| style="background:lime" | [[VIA EPIA-CN|OK...]]30
| VIA CN700
| VIA VT8237R
| VIA VT1211
| VIA C7™, VIA  Esther C5J™
| NanoBGA2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| VIA
| [http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=400 EPIA-CN13000G]
| style="background:lime" | [[VIA EPIA-CN|OK...]]30
| VIA CN700
| VIA VT8237R
| VIA VT1211
| VIA C7™, VIA  Esther C5J™
| NanoBGA2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| VIA
| [http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=399 EPIA-EN12000EG]
| style="background:yellow" | [[VIA EPIA-EN|WIP...]]30
| VIA CN700
| VIA VT8237R
| Winbond™ W83627EHG
| VIA C7™, VIA  Esther C5J™
| NanoBGA2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| VIA
| [http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=399 EPIA-EN15000G]
| style="background:yellow" | [[VIA EPIA-EN|WIP...]]30
| VIA CN700
| VIA VT8237R
| Winbond™ W83627EHG
| VIA C7™, VIA  Esther C5J™
| NanoBGA2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| VIA
| [http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=473 EPIA-LN10000EG/EAG]
| style="background:lime" | [[VIA EPIA-LN|OK...]]30
| VIA CN700
| VIA VT8237R
| VIA VT1211
| VIA C7™, VIA  Esther C5J™
| NanoBGA2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| VIA
| [http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=590 NAB7400]
| style="background:yellow" | [[VIA NAB7400|WIP...]]30
| VIA CN700
| VIA VT8237R
| VIA VT1211
| VIA C7™, VIA  Esther C5J™
| NanoBGA2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| VIA
| [http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=590 NAB7410]
| style="background:yellow" | [[VIA NAB7410|WIP...]]30
| VIA CN700
| VIA VT8237R
| VIA VT1211
| VIA C7™, VIA  Esther C5J™
| NanoBGA2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| VIA
| [http://www.idot.com.tw/en/products/mb-pc2500e/ pc2500e]
| style="background:lime" | [[VIA pc2500e|OK...]]
| VIA CN700
| VIA VT8237R
| ITE IT8716F
| VIA C7™, VIA Esther C5J™
| NanoBGA2
| PLCC
| ?
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| VIA
| [http://www.idotpc.com/TheStore/pc/viewCategories.asp?idCategory=56 EPIA-N]
| style="background:yellow" | ?
| VIA CN400
| VIA VT8237R
| Winbond W83697HF
| ?
| ?
| ?
| ?
| ?
| ?
| —

|- bgcolor="#6699ff"
| colspan="13" | <h4>Set-top-boxes / Thin clients</h4>

|- bgcolor="#eeeeee"
| Artec Group
| [http://www.artecgroup.com/thincan/index.php?option=com_content&task=blogcategory&id=15&Itemid=34 DBE61]
| style="background:red" | Broken40
| AMD LX
| AMD CS5536
| —
| AMD Geode™ LX
| —
| ?
| ?
| ?
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| ASI
| MB-5BLGP32
| style="background:lime" | [[ASI MB-5BLGP|OK...]]
| AMD GX1
| AMD CS5530
| NSC PC87351
| AMD Geode™ GX1
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| ASI
| [http://www.hojerteknik.com/winnet.htm MB-5BLMP]33
| style="background:lime" | [[ASI MB-5BLMP|OK...]]
| AMD GX1
| AMD CS5530
| NSC PC87351
| AMD Geode™ GX1
| —
| ?
| ?
| ?
| style="background:lime" | Y
| —

|- bgcolor="#eeeeee"
| AXUS
| [http://www.keyton.co.jp/products/UAXT/TC-320.html TC320]
| style="background:lime" | [[AXUS TC320|OK...]]
| AMD GX1
| AMD CS5530A
| NSC PC97317
| AMD Geode™ GX1
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| BCOM
| [http://web.archive.org/web/20031207003521/http://www.igel.co.za/igel_316_compact.htm WinNET100]34
| style="background:lime" | [[BCOM WINNET100|OK...]]
| AMD GX1
| AMD CS5530A
| NSC PC97317
| AMD Geode™ GX1
| —
| ?
| ?
| ?
| style="background:lime" | Y
| —

|- bgcolor="#dddddd"
| BCOM
| WinNET P680
| style = "background:yellow" | [[BCOM WinNET P680|WIP...]]
| VIA CN700
| VIA VT8237R Plus
| Winbond™ W83697HG
| Via C7™
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Linutop
| [http://linutop.com/ Linutop]
| style="background:lime" | OK19
| AMD LX
| AMD CS5536
| —
| AMD Geode™ LX
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| RCA
| [http://www.settoplinux.org/index.php?title=RCA_RM4100 RM4100]
| style="background:lime" | [[RCA RM4100|OK...]]
| Intel® 82830M
| Intel® 82801DB (ICH4)
| SMSC® LPC47M192
| Intel® Mobile Celeron
| Socket 479
| ?
| ?
| ?
| style="background:lime" | Y
| —

|- bgcolor="#eeeeee"
| TeleVideo
| [http://www.televideo.com/TeleVideo/TC7000_WinCE_Series.htm TC7020]
| style="background:lime" | [[TeleVideo TC7020|OK...]]
| AMD GX1
| AMD CS5530A
| NSC PC97317
| AMD Geode™ GX1
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| Thomson
| [http://www.settoplinux.org/index.php?title=Thomson_IP1000 IP1000]
| style="background:lime" | [[Thomson IP1000|OK...]]
| Intel® 82830M
| Intel® 82801DB (ICH4)
| SMSC® LPC47M192
| Low Voltage Intel® Pentium® III
| Socket 479
| ?
| ?
| ?
| style="background:lime" | Y
| —

|- bgcolor="#eeeeee"
| Wyse
| [http://www.wyse.de/products/hardware/thinclients/S50/index.asp S50]
| style="background:lime" | OK
| AMD GX2
| AMD CS5536
| —
| AMD Geode™ GX2
| —
| PLCC
| LPC
| style="background:lime" | Y
| style="background:lime" | Y
| —

|- bgcolor="#6699ff"
| colspan="13" | <h4>Devel/Eval Boards</h4>

|- bgcolor="#eeeeee"
| AMD
| Bimini
| style="background:lime" | OK
| AMD Fam10h
| AMD 785E/SB820M
| —
| AMD Turion™ II Neo/Athlon™ II Neo
| ASB2 (BGA812)
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| AMD
| [http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_13022%5E13060,00.html DB800] (Salsa)
| style="background:lime" | OK
| AMD LX
| AMD CS5536
| Winbond™ W83627HF
| AMD Geode™ LX
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| AMD
| Norwich
| style="background:lime" | OK21
| AMD LX
| AMD CS5536
| —
| AMD Geode™ LX
| —
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| AMD
| [http://www.amd.com/us-en/assets/content_type/DownloadableAssets/42655A_S1DBM680T_PB.pdf dbM690T] (Herring)
| style="background:lime" | [[AMD DBM690T|OK...]]
| AMD K8
| AMD RS690/SB600
| ITE IT8712F
| AMD Turion™ / X2  Sempron™
| Socket S1G1
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| AMD
| DB780E (Mahogany)
| style="background:lime" | [[AMD DB780E|OK...]]
| AMD K8
| AMD RS780E/SB700
| ITE IT8718F
| AMD Athlon™ 64 / X2 / FX, Sempron™
| Socket AM2+
| ?
| SPI
| ?
| ?
| —

|- bgcolor="#eeeeee"
| AMD
| DB780E (Mahogany)
| style="background:lime" | [[AMD DB780E|OK...]]
| AMD Fam10h
| AMD RS780E/SB700
| ITE IT8718F
| AMD Athlon™ 64 / X2 / FX, Sempron™
| Socket AM2+
| ?
| SPI
| ?
| ?
| —

|- bgcolor="#eeeeee"
| AMD/IBASE
| DBFT1-00-EVAL-KT (Persimmon)
| style="background:lime" | [[AMD PERSIMMON |OK...]]
| AMD Fam14h
| AMD SB800
| FINTEK F81865
| AMD G-series™
| Socket FT1
| ?
| SPI
| No
| Yes
| —

|- bgcolor="#eeeeee"
| AMD
| Pistachio
| style="background:lime" | OK
| AMD K8
| AMD RS690/SB600
| —
| ?
| Socket AM2
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| AMD
| South Station
| style="background:lime" | [[AMD SOUTH STATION |OK...]]
| AMD Fam14h
| AMD SB850
| — 
| AMD G-series™
| Socket FT1
| SOIC8
| SPI
| No
| Yes
| —

|- bgcolor="#eeeeee"
| AMD
| Tilapia
| style="background:lime" | OK
| AMD Fam10h
| AMD RS780/SB700
| ITE IT8718F
| ?
| Socket AM3
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| AMD
| Union Station
| style="background:lime" | [[AMD UNION STATION |OK...]]
| AMD Fam14h
| AMD SB800
| — 
| AMD G-series™
| Socket FT1
| SOIC8
| SPI
| No
| Yes
| —

|- bgcolor="#dddddd"
| Broadcom
| Blast
| style="background:lime" | OK
| AMD K8
| Broadcom BCM5785/5780
| NSC PC87417
| ?
| ?
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Intel
| 3100 devkit (Mt. Arvon)
| style="background:lime" | OK
| Intel® 3100
| Intel® 3100
| Intel® 3100
| Intel® Pentium® M
| Socket 479
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Intel
| EagleHeights
| style="background:lime" | OK
| Intel® 3100
| Intel® 3100
| Intel® 3100
| Intel® Pentium® M
| ?
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Intel
| EP80579 devkit (Truxton)
| style="background:lime" | OK
| Intel® EP80579
| Intel® EP80579
| Intel® EP80579
| Intel® EP80579
| Intel® EP80579
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| Intel
| XE7501devkit
| style="background:#eeeeee" | ?
| Intel® E7501
| Intel® 82801CA (ICH3-S)
| SMSC® LPC47B272
| ?
| ?
| ?
| ?
| ?
| ?
| —

|- bgcolor="#dddddd"
| NVIDIA
| l1_2pvv
| style="background:lime" | OK14
| AMD K8
| NVIDIA MCP55+IO55
| Winbond™ W83627EHG
| AMD Opteron™
| Socket F
| ?
| ?
| ?
| ?
| —

|- bgcolor="#eeeeee"
| VIA
| VT8454c
| style="background:lime" | OK
| VIA CX700
| integrated
| integrated
| VIA C7™
| ?
| ?
| ?
| ?
| ?
| —

|- bgcolor="#6699ff"
| colspan="13" | <h4>Miscellaneous</h4>

|- bgcolor="#eeeeee"
| Emulation
| [http://fabrice.bellard.free.fr/qemu/ QEMU x86]
| style="background:lime" | [[QEMU Build Tutorial|OK...]]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| —
| Intel® Pentium® II/III (?)
| —
| ?
| ?
| ?
| ?
| —
|}


1 NVIDIA nForce™ Professional 2200 (CK804). 
2 Work in progress. 
3 This was an AMD64 reference board. 
4 Vendor Cooperation Score. 
5 NVIDIA nForce™ Professional 2200 and 2050 (2 × CK804). 
6 NVIDIA nForce™ 4, nForce 4 SLI, or nForce 4 4x. 
7 LSI1030 SCSI controller can not be used to boot the machine. 
8 Use the ''epia-m'' code for now. The on-board PCMCIA and CF sockets work. coreboot can boot from CF (the stock BIOS can't). [http://www.linuxbios.org/pipermail/linuxbios/2006-October/016448.html Some problems] remain, though. 
9 The AMD GX (internally known as GX2 for some time) is actually the successor to the GX1. 
10 Use the ''epia-m'' code for now (plus [http://www.linuxbios.org/pipermail/linuxbios/2006-October/016423.html a few hacks], e.g. disable Firewire/CF slot,
because they're not present on the board). 
12 Except for some [http://www.linuxbios.org/pipermail/linuxbios/2006-October/016463.html possible problems with SATA2 ports], everything should work. 
13 See also http://www.linuxbios.org/pipermail/linuxbios/2006-November/017065.html. 
14 These boards ''should'' work fine, but we have no confirmed reports on the [[Mailinglist|mailing list]] so far, so we cannot tell for sure. 
15 See http://www.openbios.org/pipermail/linuxbios/2007-February/018299.html. 
17 Seems to be [http://www.linuxbios.org/pipermail/linuxbios/2006-November/016651.html partially working], specifically eth0, eth2, the PCI slot, the USB ports, and the serial console [http://www.linuxbios.org/pipermail/linuxbios/2007-May/021226.html are working]. Other parts are not yet finished. 
19 The Linutop does not ship with coreboot, but [http://linutop.com/wiki/index.php/Developers#Upgrading_to_LinuxBIOS the code should work]. 
20 Fan-control doesn't work yet. 
21 This is ''the'' AMD Geode LX reference board and coreboot reference implementation on the AMD Geode LX, contributed and maintained by AMD engineers. 
22 The board can boot a Linux kernel currently, but there's [http://www.linuxbios.org/pipermail/linuxbios/2007-May/020770.html no VGA support, yet]. 
25 [http://www.linuxbios.org/pipermail/linuxbios/2007-May/021280.html Works fine], only smaller issues remain to be fixed. A [http://www.linuxbios.org/pipermail/linuxbios/2007-May/021308.html list of known issues] is available. 
27 The JUKI-511P and ROCKY-512 both use the same code and target (targets/iei/juki-511p). Thus, both [http://www.linuxbios.org/pipermail/linuxbios/2007-June/021862.html support the same features and have the same limitations]: IDE, USB, ethernet, serial, keyboard and sound work, but there are problems booting from IDE1 ([http://www.linuxbios.org/pipermail/linuxbios/2007-June/021996.html this patch] may help), and VGA video doesn't work, yet. 
28 Partially supported, almost boots a Linux kernel. [http://www.linuxbios.org/pipermail/linuxbios/2007-June/022217.html Some issues] still remain to be fixed, though. 
29 Some boards have ROM sockets, others are soldered. 
30 The irq table in CN is from VIA. You may need to run getpir to generate your own irq table. 
31 Technologic Systems. 
32 Used in the Neoware Eon 4000s thin client. 
33 Used in the IGEL WinNET III thin client. 
34 Used in the IGEL-316 thin client. 
35 ROM chip package (PLCC, DIP32, DIP8, SOIC8). 
36 ROM chip protocol/type (parallel flash, LPC, FWH, SPI). 
37 ROM chip socketed (Y/N)? 
38 Board supported by [[Flashrom]] (Y/N)? 
39 Interestingly [[flashrom]] does not work when the vendor BIOS is booted, but it does work flawlessly when the machine is booted with coreboot. 
40 Broken v4 port, try the v3 port instead. The v4 version will be fixed at some point. 
41 RAM must be matched exactly in each bank. 
44 Boots MS-DOS fine using SeaBIOS, might boot Linux. 
45 works fine with Linux, some ACPI issues with Windows needs to be fixed.


== Motherboards supported in coreboot v3 ==

<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 have been integrated in what now became v4.</div>

{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
! align="left" | Vendor
! align="left" | Mainboard
! align="left" | Northbridge
! align="left" | Southbridge
! align="left" | Super I/O
! align="left" | CPU
! align="left" | Socket
! align="left" | Status
! align="left" | ROM 1
! align="left" | P 2
! align="left" | S 3
! align="left" | F 4
! align="left" | VCS5
! align="left" | v3 only 7

|- bgcolor="#eeeeee"
| Advanced Digital Logic
| [http://www.adlogic-pc104.com/products/cpu/datasheets/MSM800SEV_SEL.pdf MSM800SEV]
| AMD Geode™ LX
| AMD Geode™ CS5536
| —
| AMD Geode™ LX
| —
| style="background:orange" | WIP
| ?
| ?
| ?
| ?
| —
| style="background:lime" | N

|- bgcolor="#dddddd"
| AMD
| DB800
| AMD Geode™ LX
| AMD CS5536
| ?
| AMD Geode™ LX
| —
| style="background:lime" | OK
| ?
| ?
| ?
| ?
| —
| style="background:lime" | N
|- bgcolor="#dddddd"
| AMD
| [http://www.amd.com/us-en/assets/content_type/DownloadableAssets/42655A_S1DBM680T_PB.pdf dbM690T] (Herring)
| AMD K8
| AMD RS690/SB600
| ITE IT8712F
| AMD Turion™ / X2  Sempron™
| Socket S1G1
| style="background:orange" | WIP
| ?
| ?
| ?
| ?
| —
| style="background:lime" | N
|- bgcolor="#dddddd"
| AMD
| Norwich
| AMD Geode™ LX
| AMD CS5536
| —
| AMD Geode™ LX
| —
| style="background:lime" | OK
| ?
| ?
| ?
| ?
| —
| style="background:lime" | N
|- bgcolor="#dddddd"
| AMD
| Serengeti Cheetah
| AMD K8
| AMD-8111™, 8151™, 8132™
| Winbond™ W83627HF
| AMD Opteron™
| Socket F
| style="background:orange" | WIP
| ?
| ?
| ?
| ?
| —
| style="background:lime" | N

|- bgcolor="#eeeeee"
| AMP
| TinyGX
| AMD Geode™ LX
| AMD CS5536
| ITE IT8716F
| AMD Geode™ LX
| —
| style="background:orange" | WIP
| ?
| ?
| ?
| ?
| —
| style="background:red" | Y

|- bgcolor="#dddddd"
| Artec Group
| [http://www.artecgroup.com/thincan/index.php?option=com_content&task=blogcategory&id=15&Itemid=34 DBE61]
| AMD Geode™ LX
| AMD CS5536
| —
| AMD Geode™ LX
| —
| style="background:orange" | WIP
| TSOP32
| LPC
| style="background:red" | N
| style="background:lime" | Y
| —
| style="background:lime" | N
|- bgcolor="#dddddd"
| Artec Group
| [http://www.artecgroup.com/thincan/index.php?option=com_content&task=blogcategory&id=15&Itemid=34 DBE62]
| AMD Geode™ LX
| AMD CS5536
| —
| AMD Geode™ LX
| —
| style="background:lime" | [[Artec Group DBE62|OK...]]
| TSOP32
| FWH
| style="background:red" | N
| style="background:lime" | Y
| style="background:lime; text-align:center" | [[Artec Group DBE62 Vendor Cooperation Score|4]]
| style="background:red" | Y

|- bgcolor="#eeeeee"
| Emulation
| [http://fabrice.bellard.free.fr/qemu/ QEMU x86]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| —
| Intel® Pentium® II/III (?)
| —
| style="background:lime" | OK
| —
| ?
| —
| —
| —
| style="background:lime" | N

|- bgcolor="#dddddd"
| GIGABYTE
| [http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2287&ModelName=GA-M57SLI-S4 GA-M57SLI-S4]
| AMD K8
| NVIDIA MCP55
| ITE IT8716F
| AMD Sempron™ / Athlon™ 64 / FX / X2
| Socket AM2
| style="background:orange" | WIP
| ...6
| ?
| style="background:red" | N
| style="background:lime" | Y
| style="background:yellow; text-align:center" | [[Gigabyte m57sli Vendor Cooperation Score|3]]
| style="background:lime" | N

|- bgcolor="#eeeeee"
| Jetway
| [http://www.jetway.com.tw/jw/ipcboard_socket.asp?platid=16 J7F2]
| VIA CN700
| VIA VT8237R(P)
| Fintek F71805F
| VIA C7™
| NanoBGA2
| style="background:orange" | WIP
| ?
| ?
| ?
| ?
| —
| style="background:red" | Y

|- bgcolor="#dddddd"
| Kontron
| [http://de.kontron.com/products/boards+and+mezzanines/embedded+motherboards/miniitx+motherboards/986lcdmmitx.html 986LCD-M/mITX]
| Intel® 945
| Intel® ICH7
| 2x Winbond® W83627THG
| Intel® Core™ 2 Duo Mobile, Core™ Duo/Solo, Celeron® M
| mPGA478
| style="background:orange" | WIP
| PLCC
| ?
| ?
| ?
| —
| style="background:lime" | N

|- bgcolor="#eeeeee"
| PC Engines
| [http://pcengines.ch/alix1c.htm ALIX.1C]
| AMD Geode™ LX
| AMD Geode™ CS5536
| Winbond® W83627HF
| AMD Geode™ LX
| —
| style="background:lime" | [[PC Engines ALIX.1C|OK...]]
| ?
| ?
| ?
| ?
| style="background:lime; text-align:center" | [[PC Engines ALIX.1C Vendor Cooperation Score|4]]
| style="background:lime" | N
|- bgcolor="#eeeeee"
| PC Engines
| [http://pcengines.ch/alix2c3.htm ALIX.2C3]
| AMD Geode™ LX
| AMD Geode™ CS5536
| —
| AMD Geode™ LX
| —
| style="background:lime" | [[PC Engines ALIX.2CX|OK...]]
| ?
| ?
| ?
| ?
| —
| style="background:red" | Y
|- bgcolor="#eeeeee"
| PC Engines
| [http://pcengines.ch/alix2c2.htm ALIX.2C2]
| AMD Geode™ LX
| AMD Geode™ CS5536
| —
| AMD Geode™ LX
| —
| style="background:lime" | [[PC Engines ALIX.2CX|OK...]]
| ?
| ?
| ?
| ?
| —
| style="background:red" | Y

|- bgcolor="#dddddd"
| VIA
| EPIA-CN
| VIA CN700
| VIA VT8237R
| VIA VT1211
| VIA C7™, VIA  Esther C5J™
| NanoBGA2
| style="background:orange" | WIP
| ?
| ?
| ?
| ?
| —
| style="background:lime" | N

|}


1 ROM chip package (PLCC, DIP32, DIP8, SOIC8). 
2 ROM chip protocol/type (parallel flash, LPC, FWH, SPI). 
3 ROM chip socketed (Y/N)? 
4 Board supported by [[Flashrom]] (Y/N)? 
5 Vendor Cooperation Score. 
6 There are two versions of the [[GIGABYTE GA-M57SLI-S4]], one with a soldered PLCC chip, one with a soldered SOIC8 chip. 
7 Board is only available in v3, not yet in v4? 



== Motherboards supported in coreboot v1 ==

Not all motherboards have been ported from coreboot v1 to coreboot v4, yet (check the CBv4 field). If you want to work on such a port contact us on the [[Mailinglist|mailing list]].

{| border="0" style="font-size: smaller"
|- bgcolor="#6699dd"
! align="left" | Vendor
! align="left" | Mainboard
! align="left" | Northbridge
! align="left" | Southbridge
! align="left" | Super I/O
! align="left" | CPU
! align="left" | Socket
! align="left" | Status
! align="left" | CBv4?

|- bgcolor="#6699ff"
| colspan="9" | <h4>Desktops / Workstations</h4>

|- bgcolor="#eeeeee"
| ASUS
| A7M
| AMD AMD76x
| VIA VT82C686
| VIA VT82C686
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee"
| ASUS
| [http://www.ciao.co.uk/ASUS_ALi_Chipset_CUA__5410161 CUA]
| Acer M1631 (ALADDiN TNT2)
| Acer M1535
| Acer M1535
| Intel® Pentium® III
| Socket 370
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee"
| ASUS
| [http://www.dealtime.com/xPF-ASUS-ASUS-Intel-Socket7-PNP586-Motherboard TX97-LE]
| Intel® 430TX
| Intel® 82371EB (PIIX4E)
| SMC FDC37C67X
| Intel® Pentium®, Pentium® MMX, AMD K5
| Socket 7
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| Bitworks
| IMS
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| NSC PC87351
| ?
| Slot1 1
| style="background:#dddddd" | ?
| style="background:red" | No

|- bgcolor="#eeeeee"
| Chaintech
| [http://www.xbitlabs.com/articles/mainboards/display/chaintech-7kjd.html CT-7KJD]
| AMD-761™
| VIA VT8231
| VIA VT8231
| AMD Athlon™ / Duron™
| Socket 462
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| Elitegroup (ECS)
| [http://www.ecsusa.com/products/k7sem_v3.html K7SEM]
| SiS730S
| SiS730S
| SiS730S
| AMD Athlon™ / Athlon™ XP / Duron™
| Socket 462
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd"
| Elitegroup (ECS)
| [http://www.ecsusa.com/downloads/manual_p6s.html P6STP-FL]
| SiS630
| SiS630
| SiS950
| Intel® Pentium®III, Celeron®
| Socket 370
| style="background:#dddddd" | ?
| style="background:red" | No

|- bgcolor="#eeeeee"
| GIGABYTE
| [http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=1445 GA-6BXC]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| ITE IT8671F
| Intel® Pentium® II/III, Celeron®
| Slot1 1
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee"
| GIGABYTE
| GA-6OXE
| Intel® 815EP
| Intel® 82801
| ITE IT8712F
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| Leadtek
| [http://web.archive.org/web/20000616073856/http://www.leadtek.com.tw/e6300MAX.htm WinFast 6300MAX]
| SiS630
| SiS630
| SiS950
| Intel® Pentium®III, Celeron®
| Socket 370
| style="background:#dddddd" | ?
| style="background:red" | No

|- bgcolor="#eeeeee"
| Matsonic
| [http://web.archive.org/web/20000619011053/www.matsonic.com/index_2.htm MS7308E]
| SiS630
| SiS630
| SiS950
| Intel® Pentium®III, Celeron®
| Socket 370
| style="background:lime" | OK3
| style="background:red" | No

|- bgcolor="#dddddd"
| PCCHIPS
| [http://www.pcchipsusa.com/prod-m754lmr.asp M754LMR]
| Acer M1631
| Acer M1535
| Acer M1535
| Intel® Pentium®III, Celeron®
| Socket 370
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd"
| PCCHIPS
| [http://www.pcchipsusa.com/prod-m758mr.asp M758LMR(+)]
| SiS630
| SiS630
| SiS950
| Intel® Pentium®III, Celeron®
| Socket 370
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd"
| PCCHIPS
| [http://www.pcchipsusa.com/prod-m787cl%2B.asp M787CL+]
| SiS630
| SiS630
| SiS950
| VIA C3™
| Socket 370
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd"
| PCCHIPS
| [http://www.pcchipsusa.com/prod-m810lmr.asp M810LMR]
| SiS670
| SiS670
| SiS950
| AMD Athlon™ / Duron™
| Socket 462
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd"
| PCCHIPS
| M810LR
| SiS670
| SiS670
| SiS950
| AMD Athlon™ / Duron™
| Socket 462
| style="background:lime" | [[PCCHIPS M810LR|???]]
| style="background:red" | No
|- bgcolor="#dddddd"
| PCCHIPS
| [http://www.pcchipsusa.com/prod-m830lmr.asp M830L(M)R]
| SiS735
| SiS735
| SiS950
| AMD Athlon™ / Athlon™ XP / Duron™
| Socket 462
| style="background:#dddddd" | ?
| style="background:red" | No

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/products/motherboard/Xeon/860/P4DC6.cfm P4DC6]
| Intel® 82860
| Intel® 82801, 82806
| Winbond™ W83627HF
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee"
| Supermicro
| P4DC6P
| Intel® 82860
| Intel® 82801, 82806
| Winbond™ W83627HF
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| Tyan
| TigerMPX
| AMD-76x™
| AMD-768™
| Winbond™ W83627HF
| ?
| ?
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd"
| Tyan
| guiness
| AMD-76x™
| AMD-766™
| Winbond™ W83627HF
| ?
| ?
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/tiger133.html Tiger 133 (S1834)]
| VIA VT8601
| ?
| Winbond™ W83977EF
| Intel® Pentium® II/III
| Slot 1
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/tsunamiatx.html Tsunami ATX (S1846)]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| NSC PC87309
| Intel® Pentium® II/III, Celeron®
| Slot 1
| style="background:lime" | OK
| style="background:lime" | Yes
|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/tigermpx.html Tiger MPX (S2466)]
| AMD-762™
| AMD-768™
| Winbond™ W83627HF
| AMD Athlon® MP
| Socket 462
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/thunderk7xpro.html Thunder K7X Pro (S2469)]
| AMD-762™
| AMD-768™
| Winbond™ W83627HF
| AMD Athlon® MP
| Socket 462
| style="background:#dddddd" | ?
| style="background:red" | No

|- bgcolor="#6699ff"
| colspan="9" | <h4>Servers</h4>

|- bgcolor="#eeeeee"
| ASUS
| [http://www.asus.de/products.aspx?l1=9&l2=39&l3=103&model=113&modelmenu=1 PU-DLS]
| Intel® E7501
| Intel® 82801CA (ICH3-S)
| Winbond™ W83627HF
| Intel® Xeon®
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| Compaq
| DS10
| Alpha Tsunami
| Acer M1543
| ?
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#eeeeee"
| Intel
| clearwater
| Intel® E7500
| Intel® 82801CA (ICH3-S), 82870
| Winbond™ W83627HF
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee"
| Intel
| clearwater533
| Intel® E7501
| Intel® 82801CA (ICH3-S), 82870
| Winbond™ W83627HF
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| RLX
| [http://web.archive.org/web/20040413125915/rlxtechnologies.com/index.php?se=servers&id=3 ServerBlade 800i]
| Micron 21PAD
| Acer M1535
| Acer M1535
| ?
| ?
| style="background:lime" | OK2
| style="background:red" | No

|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/products/motherboard/Xeon/E7500/P4DPE.cfm P4DPE]
| Intel® E7500
| Intel® 82801CA (ICH3-S), 82870
| Winbond™ W83627HF
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/products/motherboard/Xeon/E7500/P4DPE-G2.cfm P4DPE-G2]
| Intel® E7500
| Intel® 82801CA (ICH3-S), 82870
| Winbond™ W83627HF
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee"
| Supermicro
| P4DPR
| Intel® E7500
| Intel® 82801CA (ICH3-S), 82870
| Winbond™ W83627HF
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/products/motherboard/Xeon/E7505/X5DAE.cfm X5DAE]
| Intel® E7505
| Intel® 82801CA (ICH3-S), 82801DB (ICH4), 82870
| Winbond™ W83627HF
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee"
| Supermicro
| [http://www.supermicro.com/products/motherboard/Xeon/E7501/X5DPE-G2.cfm X5DPE-G2]
| Intel® E7501
| Intel® 82801CA (ICH3-S), 82870
| Winbond™ W83627HF
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee"
| Supermicro
| X5DPR
| Intel® E7501
| Intel® 82801CA (ICH3-S), 82870
| Winbond™ W83627HF
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| Tyan
| [http://www.tyan.com/archive/products/html/tigeri7501.html Tiger i7501 (S2723)]
| Intel® E7501
| Intel® 82801CA (ICH3-S), 82870
| Winbond™ W83627HF
| Intel® Xeon®
| Socket 604
| style="background:#dddddd" | ?
| style="background:red" | No

|- bgcolor="#6699ff"
| colspan="9" | <h4>Laptops</h4>

|- bgcolor="#eeeeee"
| IBM
| [http://www.thinkwiki.org/wiki/Category:T23 ThinkPad T23]
| Intel® 82830
| Intel® 82801
| ?
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#6699ff"
| colspan="10" | <h4>Embedded / SBC / PC/104</h4>

|- bgcolor="#eeeeee"
| Advantech
| pcm-5823
| NSC GX1
| NSC CS5530
| SMC FDC37B72X
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee"
| Advantech
| pcm-9574
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977EF
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| Cocom
| voyager2
| NSC GX1
| NSC CS5530
| NSC PC97317
| ?
| ?
| style="background:#dddddd" | ?
| style="background:red" | No

|- bgcolor="#eeeeee"
| DigitalLogic
| smartcore-p3
|
|
|
|
|
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee"
| DigitalLogic
| smartcore-p5
|
|
|
|
|
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| Lanner
| [http://www.embedded-computing.com/products/search/fm/id/?10784 EM-370]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83977EF
| Intel® Pentium®III / Celeron®
| Slot 370
| style="background:#dddddd" | ?
| style="background:red" | No

|- bgcolor="#eeeeee"
| Lippert
| [http://web.archive.org/web/20031204180239/www.lippert-at.com/pc104plus.html Cool RoadRunner II]
| NSC GX1
| NSC CS5530
| SMC FDC37B72X
| NSC Geode GX1
| —
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| Nano
| nano
| NSC GX1
| NSC SCX200
| ?
| ?
| ?
| style="background:#dddddd" | ?
| style="background:red" | No

|- bgcolor="#eeeeee"
| STMicroelectronics
| [http://mcu.st.com/mcu/modules.php?name=mcu&file=familiesdocs&FAM=75 STPC® Consumer-II]
| integrated
| integrated
| SMC FDC37B78X
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee"
| STMicroelectronics
| [http://mcu.st.com/mcu/modules.php?name=mcu&file=familiesdocs&FAM=75 STPC® Elite]
| integrated
| integrated
| SMC FDC37B78X
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| Supertek
| ST3-WT
| NSC GX1
| NSC CS5535
| NSC PC97317
| Geode
| ?
| style="background:lime" | OK ([[User:Stepan|SR]])
| style="background:red" | No

|- bgcolor="#eeeeee"
| Technoland
| [http://web.archive.org/web/20040406003346/technoland.com/tl_embsbc710.htm TL-EmbSBC 710]
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| Winbond™ W83877EF
| Intel® Pentium® III / Celeron®
| Slot 1
| style="background:lime" | [[Technoland SBC 710|???]]
| style="background:red" | No

|- bgcolor="#6699ff"
| colspan="9" | <h4>Mini-ITX</h4>

|- bgcolor="#eeeeee"
| VIA
| [http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=21 EPIA]
| VIA VT8601
| VIA VT8231
| Winbond™ W83627HF
| VIA C3™ / EDEN™
| ?
| style="background:#eeeeee" | ?
| style="background:lime" | Yes
|- bgcolor="#eeeeee"
| VIA
| [http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=81 EPIA-M]
| VIA VT8623
| VIA VT8235
| VIA VT1211
| VIA C3™ / EDEN™
| ?
| style="background:#eeeeee" | ?
| style="background:lime" | Yes

|- bgcolor="#6699ff"
| colspan="9" | <h4>Set-top-boxes / Thin clients</h4>

|- bgcolor="#eeeeee"
| Lex
| [http://www.lex.com.tw:8080/product/CV860A.htm CV860A]
| VIA VT8601A
| VIA VT82C686B
| VIA VT82C686B
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| RCN
| Dc1100s
| VIA VT694
| VIA VT82C686
| VIA VT82C686
| ?
| ?
| style="background:#dddddd" | ?
| style="background:red" | No

|- bgcolor="#6699ff"
| colspan="10" | <h4>Devel/Eval Boards</h4>

|- bgcolor="#eeeeee"
| Motorola
| Sandpoint
| Motorola MPC107
| Winbond™ W83C553
| NSC PC97307
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:lime" | Yes

|- bgcolor="#6699ff"
| colspan="9" | <h4>Miscellaneous</h4>

|- bgcolor="#eeeeee"
| BCM
| e100
| SiS550
| SiS550
| ?
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| Dell
| 350
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| SMC FDC37B907
| ?
| Slot 1
| style="background:#dddddd" | ?
| style="background:red" | No

|- bgcolor="#eeeeee"
| irobot
| Proto1
| Intel® 440BX
| Intel® 82371EB (PIIX4E)
| SMS FDC37N769
| ?
| Slot 1
| style="background:#eeeeee" | ?
| style="background:red" | No

|- bgcolor="#dddddd"
| SiS
| 540 (?)
| SiS540
| SiS540
| SiS950
| ?
| ?
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd"
| SiS
| 550 (?)
| SiS550
| SiS550
| ?
| ?
| ?
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd"
| SiS
| 635 (?)
| ?
| SiS635
| SiS950
| ?
| ?
| style="background:#dddddd" | ?
| style="background:red" | No
|- bgcolor="#dddddd"
| SiS
| 735 (?)
| SiS735
| SiS735
| SiS950
| ?
| ?
| style="background:#dddddd" | ?
| style="background:red" | No

|- bgcolor="#eeeeee"
| VIA
| vt5292
| VIA VT8601
| VIA VT82C686
| VIA VT82C686
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No
|- bgcolor="#eeeeee"
| VIA
| vt5426
| VIA VT8601
| VIA VT82C686
| VIA VT82C686
| ?
| ?
| style="background:#eeeeee" | ?
| style="background:red" | No
|}


1 Work in progress. 
2 http://www.linuxbios.org/pipermail/linuxbios/2002-October/000743.html 
3 http://www.linuxbios.org/pipermail/linuxbios/2003-September/005385.html 


__FORCETOC__

Infrastructure Projects

2012-09-25T08:53:02Z

PatrickGeorgi: /* Geode issues */

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

{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
! align="left" | Vendor/chipset
! align="left" | Tested
! align="left" | Comments

|- bgcolor="#eeeeee"
| amd/amdfam10
| ?
| —
|- bgcolor="#eeeeee"
| amd/amdht
| ?
| —
|- bgcolor="#eeeeee"
| amd/amdk8
| ?
| —
|- bgcolor="#eeeeee"
| amd/amdmct
| ?
| —
|- bgcolor="#eeeeee"
| amd/gx1
| ?
| —
|- bgcolor="#eeeeee"
| amd/gx2
| ?
| —
|- bgcolor="#eeeeee"
| amd/lx
| ?
| —
|- bgcolor="#eeeeee"
| intel/e7501
| ?
| —
|- bgcolor="#eeeeee"
| intel/e7520
| ?
| —
|- bgcolor="#eeeeee"
| intel/e7525
| ?
| —
|- bgcolor="#eeeeee"
| intel/i3100
| ?
| —
|- bgcolor="#eeeeee"
| intel/i440bx
| ?
| —
|- bgcolor="#eeeeee"
| intel/i82810
| ?
| —
|- bgcolor="#eeeeee"
| intel/i82830
| ?
| —
|- bgcolor="#eeeeee"
| intel/i855
| ?
| —
|- bgcolor="#eeeeee"
| intel/i945
| style="background:lime" | Y
| Tested on Kontron 986LCD-M and Roda RK886EX
|- bgcolor="#eeeeee"
| via/cn400
| ?
| —
|- bgcolor="#eeeeee"
| via/cn700
| style="background:lime" | Y
| Tested on VIA pc2500e.
|- bgcolor="#eeeeee"
| via/cx700
| ?
| —
|- bgcolor="#eeeeee"
| via/vt8601
| ?
| —
|- bgcolor="#eeeeee"
| via/vt8623
| ?
| —
|- bgcolor="#eeeeee"
| via/vx800
| ?
| —

|}

'''Developers:''' Stefan

== CBFS ==

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

'''Status:'''

Upstream, pre-CBFS infrastructure removed.

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

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

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

{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
! align="left" | Vendor/chipset
! align="left" | ROM enabled
! align="left" | Tiny bootblock
! align="left" | Status / Comments

|- bgcolor="#eeeeee"
| amd/amd8111
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.
|- bgcolor="#eeeeee"
| amd/cs5530
| style="background:lime" | Y
| style="background:red" | N
| Not tested on hardware, yet.
|- bgcolor="#eeeeee"
| amd/cs5535
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| amd/cs5536
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| amd/sb600
| style="background:lime" | Y
| style="background:lime" | Y
| Build- and runtime-tested on siemens/sitemp_g1p1 by [[User:PatrickGeorgi|PatrickGeorgi]].
|- bgcolor="#eeeeee"
| amd/sb700
| style="background:yellow" | Y
| style="background:yellow" | Y
| —

|- bgcolor="#dddddd"
| broadcom/bcm5785
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#eeeeee"
| intel/esb6300
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i3100
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82371eb
| style="background:lime" | Y
| style="background:yellow" | Y
| Build- and runtime-tested on ASUS P2B by [[User:Uwe|Uwe Hermann]].
|- bgcolor="#eeeeee"
| intel/i82801ax
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801bx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801cx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801dx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801ex
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801gx
| style="background:lime" | Y
| style="background:lime" | Y
| Build- and runtime-tested on Kontron 986LCD-m by PatrickGeorgi

|- bgcolor="#dddddd"
| nvidia/ck804
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.
|- bgcolor="#dddddd"
| nvidia/mcp55
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#dddddd"
| sis/sis966
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#eeeeee"
| via/vt8231
| style="background:yellow" | Y
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| via/vt8235
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| via/vt8237r
| style="background:yellow" | Y
| style="background:yellow" | Y
| —
|- bgcolor="#eeeeee"
| via/vt82c686
| style="background:red" | N
| style="background:red" | N
| —

|}

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

== Tiny Bootblock ==

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

'''Status:''' Available in Kconfig, works on a couple of boards. Requires per southbridge changes (and northbridge in some cases) on many boards (related to ROM enable, see CBFS section).

'''Developers:''' Patrick

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

'''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 ==
* Figure out generic ACPI code and deduplicate it.
* Fix issues like http://www.coreboot.org/pipermail/coreboot/2011-May/065179.html

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

= More ideas =

== CMOS handling ==

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

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

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

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

408/512 some_string string

984/16 checksum checksum 392 983
</code>

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

=== CMOS defaults ===
Allow (somehow) to define defaults for all CMOS fields, and create a static table from that. Use that at runtime if the CMOS checksum fails.
In the above format, it could simply be a suffix <code>default=VALUE</code>
Also drop the "default" argument in get_options. As components have their own cmos.layout snippets, we can always take those definitions' defaults, even if mainboards don't make use of CMOS themselves.

=== Value overrides ===
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 ===
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)

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

=== Checksums ===

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.

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

== USB Debug Console ==

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

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

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

== printk into buffer ==

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

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

== Global variables ==

* Port the global variables framework from v3.
* Make use of it where appropriate.

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

== Port v3 Resource Allocator ==

The v3 resource allocator should be ported to v4.

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

'''Developers:''' Myles

== Config & Build System ==

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

'''Status:''' Upstream, boards are converted. Old system is gone. All boards build. HOWEVER, not all boards have been boot-tested yet, please report any issues you encounter!

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

== Unify text printing functions ==

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

'''Status:''' Finished.

'''Developers:''' Patrick, Stefan

== Common payload location ==

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

'''Status:''' Finished.

== Fix ALL build warnings ==

* Someone has to do the deed.

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

== Post codes ==

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

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

== Use central oprom init ==

* Get rid of all vgabios.c, make all chipsets with own vgabios.c use devices/oprom/x86.c.
* Use the realmode code for vsmsetup too.

== Use nvramtool for static option table creation ==

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.

'''Status:''' Finished, upstream.

'''Developers:''' Vikram

== Local APIC addresses ==

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

* LAPIC_ADDR
* LOCAL_APIC_ADDR (even twice)
* LAPIC_DEFAULT_BASE

This should be unified.

'''Developers:''' Patrick

Infrastructure Projects

2012-09-21T13:09:45Z

PatrickGeorgi: /* Provide update paths and avoid conflicts in addressing */

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

{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
! align="left" | Vendor/chipset
! align="left" | Tested
! align="left" | Comments

|- bgcolor="#eeeeee"
| amd/amdfam10
| ?
| —
|- bgcolor="#eeeeee"
| amd/amdht
| ?
| —
|- bgcolor="#eeeeee"
| amd/amdk8
| ?
| —
|- bgcolor="#eeeeee"
| amd/amdmct
| ?
| —
|- bgcolor="#eeeeee"
| amd/gx1
| ?
| —
|- bgcolor="#eeeeee"
| amd/gx2
| ?
| —
|- bgcolor="#eeeeee"
| amd/lx
| ?
| —
|- bgcolor="#eeeeee"
| intel/e7501
| ?
| —
|- bgcolor="#eeeeee"
| intel/e7520
| ?
| —
|- bgcolor="#eeeeee"
| intel/e7525
| ?
| —
|- bgcolor="#eeeeee"
| intel/i3100
| ?
| —
|- bgcolor="#eeeeee"
| intel/i440bx
| ?
| —
|- bgcolor="#eeeeee"
| intel/i82810
| ?
| —
|- bgcolor="#eeeeee"
| intel/i82830
| ?
| —
|- bgcolor="#eeeeee"
| intel/i855
| ?
| —
|- bgcolor="#eeeeee"
| intel/i945
| style="background:lime" | Y
| Tested on Kontron 986LCD-M and Roda RK886EX
|- bgcolor="#eeeeee"
| via/cn400
| ?
| —
|- bgcolor="#eeeeee"
| via/cn700
| style="background:lime" | Y
| Tested on VIA pc2500e.
|- bgcolor="#eeeeee"
| via/cx700
| ?
| —
|- bgcolor="#eeeeee"
| via/vt8601
| ?
| —
|- bgcolor="#eeeeee"
| via/vt8623
| ?
| —
|- bgcolor="#eeeeee"
| via/vx800
| ?
| —

|}

'''Developers:''' Stefan

== CBFS ==

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

'''Status:'''

Upstream, pre-CBFS infrastructure removed.

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

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

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

{| border="0" style="font-size: smaller"
|- bgcolor="#6699ff"
! align="left" | Vendor/chipset
! align="left" | ROM enabled
! align="left" | Tiny bootblock
! align="left" | Status / Comments

|- bgcolor="#eeeeee"
| amd/amd8111
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.
|- bgcolor="#eeeeee"
| amd/cs5530
| style="background:lime" | Y
| style="background:red" | N
| Not tested on hardware, yet.
|- bgcolor="#eeeeee"
| amd/cs5535
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| amd/cs5536
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| amd/sb600
| style="background:lime" | Y
| style="background:lime" | Y
| Build- and runtime-tested on siemens/sitemp_g1p1 by [[User:PatrickGeorgi|PatrickGeorgi]].
|- bgcolor="#eeeeee"
| amd/sb700
| style="background:yellow" | Y
| style="background:yellow" | Y
| —

|- bgcolor="#dddddd"
| broadcom/bcm5785
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#eeeeee"
| intel/esb6300
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i3100
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82371eb
| style="background:lime" | Y
| style="background:yellow" | Y
| Build- and runtime-tested on ASUS P2B by [[User:Uwe|Uwe Hermann]].
|- bgcolor="#eeeeee"
| intel/i82801ax
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801bx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801cx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801dx
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801ex
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| intel/i82801gx
| style="background:lime" | Y
| style="background:lime" | Y
| Build- and runtime-tested on Kontron 986LCD-m by PatrickGeorgi

|- bgcolor="#dddddd"
| nvidia/ck804
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.
|- bgcolor="#dddddd"
| nvidia/mcp55
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#dddddd"
| sis/sis966
| style="background:yellow" | Y
| style="background:yellow" | Y
| Not tested on hardware, yet.

|- bgcolor="#eeeeee"
| via/vt8231
| style="background:yellow" | Y
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| via/vt8235
| style="background:red" | N
| style="background:red" | N
| —
|- bgcolor="#eeeeee"
| via/vt8237r
| style="background:yellow" | Y
| style="background:yellow" | Y
| —
|- bgcolor="#eeeeee"
| via/vt82c686
| style="background:red" | N
| style="background:red" | N
| —

|}

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

== Tiny Bootblock ==

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

'''Status:''' Available in Kconfig, works on a couple of boards. Requires per southbridge changes (and northbridge in some cases) on many boards (related to ROM enable, see CBFS section).

'''Developers:''' Patrick

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

'''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 ==
* Figure out generic ACPI code and deduplicate it.
* Fix issues like http://www.coreboot.org/pipermail/coreboot/2011-May/065179.html

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

= More ideas =

== CMOS handling ==

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

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

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

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

408/512 some_string string

984/16 checksum checksum 392 983
</code>

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

=== CMOS defaults ===
Allow (somehow) to define defaults for all CMOS fields, and create a static table from that. Use that at runtime if the CMOS checksum fails.
In the above format, it could simply be a suffix <code>default=VALUE</code>
Also drop the "default" argument in get_options. As components have their own cmos.layout snippets, we can always take those definitions' defaults, even if mainboards don't make use of CMOS themselves.

=== Value overrides ===
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 ===
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)

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

=== Checksums ===

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.

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

== USB Debug Console ==

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

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

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

== printk into buffer ==

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

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

== Global variables ==

* Port the global variables framework from v3.
* Make use of it where appropriate.

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

== Port v3 Resource Allocator ==

The v3 resource allocator should be ported to v4.

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

'''Developers:''' Myles

== Config & Build System ==

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

'''Status:''' Upstream, boards are converted. Old system is gone. All boards build. HOWEVER, not all boards have been boot-tested yet, please report any issues you encounter!

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

== Unify text printing functions ==

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

'''Status:''' Finished.

'''Developers:''' Patrick, Stefan

== Common payload location ==

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

'''Status:''' Finished.

== Fix ALL build warnings ==

* Someone has to do the deed.

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

== Post codes ==

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

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

== Use central oprom init ==

* Get rid of all vgabios.c, make all chipsets with own vgabios.c use devices/oprom/x86.c.
* Use the realmode code for vsmsetup too.

== Use nvramtool for static option table creation ==

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.

'''Status:''' Finished, upstream.

'''Developers:''' Vikram

== Local APIC addresses ==

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

* LAPIC_ADDR
* LOCAL_APIC_ADDR (even twice)
* LAPIC_DEFAULT_BASE

This should be unified.

'''Developers:''' Patrick