coreboot - User contributions [en]

Easy projects

2013-04-15T21:25:03Z

Stepan: /* Use CBFS wherever possible */

You probably came here trying to find a small (minutes to hours) and easy task where you can get your hands dirty and get results immediately.

If you're a coreboot or flashrom newbie, this page is for you.

== coreboot ==

=== AMD 740G information gathering ===

(This project description is not finished yet)

If you have a board with AMD 740G chipset, please run (as root)

$ '''flashrom -V'''
$ '''lspci -nnvvvxxxx'''
$ '''superiotool -deV'''
$ '''dmidecode'''

and mail the output to the [[Mailinglist|coreboot mailing list]] together with the exact model number/name of your board.

This helps us evaluate which boards are good targets for coreboot.

Here are some boards:

* http://www.czechcomputer.cz/cat_tree.jsp?bpath=Z%C3%A1kladn%C3%AD+desky\Socket+AM2%2B\AMD+740G

=== Formatting and whitespace cleanup ===

We try to maintain the code in the [[Development_Guidelines#Coding_Style Linux style]], but occasionally white-space and other formatting issues find their way into the project. Formatting and white-space changes should be done in small groups as a separate patch from code changes. Be careful running indent/lindent. The results are not always the right thing to do and require review.

Ideally a check/test should be integrated into the build system pointing out these issues already when committing or testing the commit. Such tests probably already exist in other projects and just need to be copied.

== Payloads ==

coreboot can use a number of different [[Payloads|payloads]].

=== Add/test new supported payloads ===

* Test syslinux (probably requires [[SeaBIOS]] in addition, needs to be checked).
* Port [[GPXE]] to "native" coreboot (it works fine together with [[SeaBIOS]] though).

== flashrom ==

The [http://www.flashrom.org flashrom] tool can read/write coreboot/BIOS images from/to flash chips.

* See [http://flashrom.org/Easy_projects flashrom's Easy Projects] list for details.

== Other ==

* Add [http://tracker.coreboot.org/trac/coreboot/ticket/95 support for using coreboot in VirtualBox].

Project Ideas

2013-03-27T00:36:17Z

Stepan:

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: Minimal coreboot and firmware experience, 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.

'''Links'''
* https://wiki.ubuntu.com/Kernel/Reference/fwts
* http://biosbits.org/
* http://linuxfirmwarekit.org/
* [[Supported Motherboards]]

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

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

'''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]
* Semantic Tester: https://code.google.com/p/c-semantics/
* [http://frama-c.com/ Frama-C]

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

== Implement coreboot features for more boards ==
A lot of cool coreboot features are only available for a subset of the supported mainboards:
* global variables in romstage
* relocatable ramstage
* cbmem console
* timestamps

This project would analyze how to bring those features forward to more boards and work on doing so.

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

== 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'''
* [[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 mainboards ==
Identify potential mainboards to port based on the recently release cpu and chipset support. The goal would be to support publicly available platforms with a number of payloads and operating systems.

'''Mentors'''

* [[User:ruik|Rudolf Marek]]

== Tianocore as payload ==

What SeaBIOS is for PC-BIOS interfaces, Tianocore is for UEFI - in fact, it's the reference implementation that most commercial UEFIs are built on. While coreboot favors other design goals than UEFI, it's really useful to support this standard that's being pushed on the market, just like SeaBIOS really helped coreboot by providing a BIOS "frontend".

There's already some code, but there's still much room for improvement: A graphics driver that uses a preinitialized (by coreboot) framebuffer. A CBFS driver so Tiano can access coreboot flash storage. Based on that, a flash driver (maybe adapted from flashrom) to implement non-volatile variable storage by writing to flash.

Possible tasks depend a lot on existing knowledge of the candidate. Few of the tasks are large enough to fill the entire GSoC time frame with one of them. Feel free to discuss with us on IRC what a suitable target could be for you.

'''Links'''
* http://www.tianocore.org/
* https://github.com/pgeorgi/edk2/tree/coreboot-pkg

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

== coreboot ACPI 4.0 and S3 power management support ==
coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific and moslty based on ACPI 2.0. Create a generic solution for ACPI 4.0 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.

The basic idea is that the system flash image always contains executable for SerialICE. Instead of loading a coreboot romstage, firmware can boot to SerialICE based on some GPIO state, a keypress sequence or a logged failure on earlier boots. It is possible to integrate this into the coreboot build tree as a bootblock option, in the same spot as the fallback/normal switch and the simple loader.

Having this capability opens up new possibilities:

During the lifetime of a mainboard, new requirements for ACPI hacks and CPU microcodes introduce the need to update boot firmware at customer site. The firmware shall have recovery path against any failures during the firmware update process. The most straight-forward solution is to do intelligent allocation of files in the CBFS such that files critical to the recovery are located on write-protected pages. The recovery path shall require only an USB mass-storage with compatible filesystem (ext2, fat32).

The ability to dual-boot reduces the amount of tools required to reverse-engineer proprietary BIOS on ports for new mainboards. It is increasingly common that the flash chips are a) not socketed or b) physically hard to access (laptops). Even if chipset support existed already for a board, there are a lot of configuration registers for PCI-e links and GPIO signals that are difficult to get right by code disassembly only. With panic room implementation there would be no need to use external programmers or flashchip hot-swap method to alternate between SerialICE (for proprietary BIOS) and coreboot romstage boots.

SerialICE requires minimal hardware resources and does not require installed RAM or display hardware. It could be used as the first power-on environment after mainboard PCB verification and assembly to verify integrated components enumerate correctly. At the end of this first power-on, actual board firmware can be programmed without the need for external programmers and SOIC-8 clips, as the SPI controller embedded in the chipset can be used instead. As setting up EHCI debug port console is fairly simple across different chipsets, it can be used to print detailed diagnostics instead of POST codes on LPC bus.

GSoC 2011 project [http://blogs.coreboot.org/blog/2011/05/09/gsoc-project-coreboot-panic-room-diagnostics-also-remote-flashing/] was able to:
* Link flashrom with libpayload and flash from USB drive in a pre-OS environment.
* Optimise flashrom memory usage to flash in pre-ram/cache-as-ram environment.
* Build SerialICE boot ROM inside the coreboot tree and share some of the PnP/SuperIO source code.
* Demonstrate booting alternative payload on keypress.

There are remaining open tasks to:
* Bring the GSoC 2011 patches up-to-date with current flashrom and libpayload trees.
* Create generic solution to jump to recovery mode using input from GPIOs and/or use of power-button override.
* Use SMBus/SMLink to send POST failure codes over ethernet using integrated network controllers.
* After panic(), dump RAM contents before they are overwritten.

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

Alternatively, figure out a way how to build them in parallel and have coreboot select the right one on runtime.

'''Links'''
* ?

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

== AMD VSA ==

Get the source code of AMD's VSA compiled and working with an open source toolchain. Integrate the it into the current build system.

'''Links'''
* ?

'''Mentors'''
* ?

Project Ideas

2013-03-27T00:30:21Z

Stepan: /* 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: Minimal coreboot and firmware experience, 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.

'''Links'''
* https://wiki.ubuntu.com/Kernel/Reference/fwts
* http://biosbits.org/
* http://linuxfirmwarekit.org/
* [[Supported Motherboards]]

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

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

'''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]
* 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'''
* [[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 mainboards ==
Identify potential mainboards to port based on the recently release cpu and chipset support. The goal would be to support publicly available platforms with a number of payloads and operating systems.

'''Mentors'''

* [[User:ruik|Rudolf Marek]]

== Tianocore as payload ==

What SeaBIOS is for PC-BIOS interfaces, Tianocore is for UEFI - in fact, it's the reference implementation that most commercial UEFIs are built on. While coreboot favors other design goals than UEFI, it's really useful to support this standard that's being pushed on the market, just like SeaBIOS really helped coreboot by providing a BIOS "frontend".

There's already some code, but there's still much room for improvement: A graphics driver that uses a preinitialized (by coreboot) framebuffer. A CBFS driver so Tiano can access coreboot flash storage. Based on that, a flash driver (maybe adapted from flashrom) to implement non-volatile variable storage by writing to flash.

Possible tasks depend a lot on existing knowledge of the candidate. Few of the tasks are large enough to fill the entire GSoC time frame with one of them. Feel free to discuss with us on IRC what a suitable target could be for you.

'''Links'''
* http://www.tianocore.org/
* https://github.com/pgeorgi/edk2/tree/coreboot-pkg

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

== coreboot ACPI 4.0 and S3 power management support ==
coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific and moslty based on ACPI 2.0. Create a generic solution for ACPI 4.0 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.

The basic idea is that the system flash image always contains executable for SerialICE. Instead of loading a coreboot romstage, firmware can boot to SerialICE based on some GPIO state, a keypress sequence or a logged failure on earlier boots. It is possible to integrate this into the coreboot build tree as a bootblock option, in the same spot as the fallback/normal switch and the simple loader.

Having this capability opens up new possibilities:

During the lifetime of a mainboard, new requirements for ACPI hacks and CPU microcodes introduce the need to update boot firmware at customer site. The firmware shall have recovery path against any failures during the firmware update process. The most straight-forward solution is to do intelligent allocation of files in the CBFS such that files critical to the recovery are located on write-protected pages. The recovery path shall require only an USB mass-storage with compatible filesystem (ext2, fat32).

The ability to dual-boot reduces the amount of tools required to reverse-engineer proprietary BIOS on ports for new mainboards. It is increasingly common that the flash chips are a) not socketed or b) physically hard to access (laptops). Even if chipset support existed already for a board, there are a lot of configuration registers for PCI-e links and GPIO signals that are difficult to get right by code disassembly only. With panic room implementation there would be no need to use external programmers or flashchip hot-swap method to alternate between SerialICE (for proprietary BIOS) and coreboot romstage boots.

SerialICE requires minimal hardware resources and does not require installed RAM or display hardware. It could be used as the first power-on environment after mainboard PCB verification and assembly to verify integrated components enumerate correctly. At the end of this first power-on, actual board firmware can be programmed without the need for external programmers and SOIC-8 clips, as the SPI controller embedded in the chipset can be used instead. As setting up EHCI debug port console is fairly simple across different chipsets, it can be used to print detailed diagnostics instead of POST codes on LPC bus.

GSoC 2011 project [http://blogs.coreboot.org/blog/2011/05/09/gsoc-project-coreboot-panic-room-diagnostics-also-remote-flashing/] was able to:
* Link flashrom with libpayload and flash from USB drive in a pre-OS environment.
* Optimise flashrom memory usage to flash in pre-ram/cache-as-ram environment.
* Build SerialICE boot ROM inside the coreboot tree and share some of the PnP/SuperIO source code.
* Demonstrate booting alternative payload on keypress.

There are remaining open tasks to:
* Bring the GSoC 2011 patches up-to-date with current flashrom and libpayload trees.
* Create generic solution to jump to recovery mode using input from GPIOs and/or use of power-button override.
* Use SMBus/SMLink to send POST failure codes over ethernet using integrated network controllers.
* After panic(), dump RAM contents before they are overwritten.

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

Alternatively, figure out a way how to build them in parallel and have coreboot select the right one on runtime.

'''Links'''
* ?

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

== AMD VSA ==

Get the source code of AMD's VSA compiled and working with an open source toolchain. Integrate the it into the current build system.

'''Links'''
* ?

'''Mentors'''
* ?

Code Coverage

2013-01-09T01:14:45Z

Stepan:

= Prerequisites =

You need
* The code coverage patch for coreboot: http://review.coreboot.org/#/c/2052/
* The latest version of lcov: http://ltp.cvs.sourceforge.net/viewvc/ltp/utils/analysis/lcov/?view=tar

= Getting started =

* Install lcov. You will need to patch geninfo to make it work with the coreboot toolchain:
--- bin/geninfo 2012-11-13 01:58:53.000000000 -0800
+++ bin/geninfo 2013-01-08 16:44:48.041362229 -0800
@@ -1871,7 +1871,7 @@
close(GCOV_PIPE);

$result = 0;
- if ($version_string =~ /(\d+)\.(\d+)(\.(\d+))?/)
+ if ($version_string =~ /(\d+)\.(\d+)(\.(\d+))$/)
{
if (defined($4))
{

= Getting code coverage information =

* Compile coreboot with CONFIG_COVERAGE enabled
* Flash and run coreboot on the target system
* Run cbmem on the target system to extract coverage data (see coreboot/util/cbmem/)
$ sudo ./cbmem -CV
* Transfer the files back to your host system
* Run lcov and genhtml on the host system
$ lcov --capture --directory $( pwd ) --output-file coreboot.info --gcov-tool i386-elf-gcov
$ genhtml coreboot.info --output-directory coreboot-coverage
* Find your html files visualizing code coverage in coreboot-coverage

= Demo =

http://www.coreboot.org/~stepan/coreboot-coverage/

= See Also =
* http://ltp.sourceforge.net/coverage/lcov.php
* http://gcc.gnu.org/onlinedocs/gcc/Gcov.html

Code Coverage

2013-01-09T00:52:14Z

Stepan: Created page with "= Prerequisites = You need * The code coverage patch for coreboot: http://review.coreboot.org/#/c/2052/ * The latest version of lcov: http://ltp.cvs.sourceforge.net/viewvc/lt..."

2011-12-05T04:08:04Z

Stepan:

== Failure at scale ==

A BIOS gets confused in a very visible way:

[[File:Billboard_bios_fail.jpeg|640px]]

Photo courtesy Greg Kurtzer of LBL.

== What floor am I on? ==

An elevator in Spain:

[[File:Elevator_spain.jpeg|640px]]

Photo courtesy Gorka Guardiola

2011-04-06T18:40:19Z

Stepan:

<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''' (formerly known as LinuxBIOS) is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today's computers. It performs just a little bit of hardware initialization and then executes what is called a [[Payloads|payload]].


With this separation of hardware initialization and later boot logic, coreboot can scale from specialized applications run directly from firmware, operating systems in flash, and custom bootloaders to implementations of firmware standards like PCBIOS and EFI without having to carry features not necessary in the target application, reducing the amount of code and flash space required.


We currently support '''[[Supported Motherboards|230]]''' different mainboards.
</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;">
Is your PC / server / laptop / mainboard supported? Check out our [[Support]] page to find out.
</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 now has a [[git]] mirror.
</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 (3 seconds to Linux console)



* 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]] / [[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://tracker.coreboot.org/trac/coreboot/browser/trunk Browse Source] | [[GSoC]] | [[Flag Days]] [[Distributed and Automated 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]]

 

'''[[News]]'''<hr />


* '''2011/03/27:''' [[News#2011.2F3.2F27_AMD_releases_C32.2FRS56x0.2FSB5100_coreboot_support_on_H8SCM_platform|AMD releases C32/RS56x0/SB5100 coreboot support on H8SCM platform]]
* '''2011/02/28:''' [[News#2011.2F2.2F28_AMD_blogs_about_coreboot|AMD blogs about coreboot]]
* '''2011/02/22:''' [[News#2011.2F2.2F22_Thinkpad_X60s_now_supported|Thinkpad X60 now supported]]
* '''2011/02/14:''' [[News#2011.2F2.2F14_AMD_submits_coreboot_support_for_AMD_Embedded_G-Series_Platforms|AMD submits coreboot support for AMD Embedded G-Series Platforms]]
* '''2010/12/18:''' [[News#2010.2F12.2F18_Intel_Poulsbo.2FSCH.2FAtom_and_iWave_iW-RainboW-G6_now_supported|Intel Poulsbo/SCH/Atom & iWave iW-RainboW-G6 support]]
* '''2010/12/13:''' [[News#2010.2F12.2F13_ASUS_M2N-E_now_supported|ASUS M2N-E support]]
* '''2010/12/06:''' [[News#2010.2F12.2F06_ASUS_M4A78-EM_now_supported|ASUS M4A78-EM support]]


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



* [[GSoC|2011 Google Summer of Code]]


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

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

__NOTOC__
__NOEDITSECTION__

2011-03-14T01:59:01Z

Stepan: Created page with "DirectHW is a software compatibility layer for Mac OS X. It provides a kernel driver and framework that emulates the most commonly used hardware access functions on x86 machines,..."

DirectHW is a software compatibility layer for Mac OS X. It provides a kernel driver and framework that emulates the most commonly used hardware access functions on x86 machines, such as:

* iopl
* inb, inw, inl, outb, outw, outl
* rdmsr, wrmsr
* mmap() of physical address space

This package was originally intended to get coreboot utilities running on Mac OS X. You're encouraged to use it for many more opportunities.

Note: Intel Mac required.

DirectHW is free software and released under the license ISC-L.

Download DirectHW 1.0 (2008/11/16): [ [http://www.coresystems.de/mac/DirectHW.dmg DMG] | [http://www.coresystems.de/mac/DirectHW.tar.bz2 Source] ]