Difference between revisions of "Project Ideas"

From coreboot
Jump to: navigation, search
(coreboot mainboard test suite)
(28 intermediate revisions by 11 users not shown)
Line 1: Line 1:
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.
+
The following are ideas that have been proposed in the community. These are projects that we think can be managed in the short period of GSoC, and they cover areas where coreboot is trying to reach new users and new use cases. But of course these are not the only things that could be done. Maybe you have a great idea that we just didn't think of yet. Please let us know!
  
== 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.
+
Prospective  [[GSoC]] students' application should expand on the ideas and provide specific information in the application. If you have questions or comments, please please contact the coreboot [[Mailinglist|mailing list]] or visit our [[IRC]] channel <code>#coreboot</code> on [https://webchat.freenode.net irc.freenode.net]. Our [[GSoC#Mentors]] are here to help.
  
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
+
= coreboot Projects =
  
When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.
+
== coreboot mainboard test suite  ==
  
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.
+
Create a single tool (most likely a bootable CD/USB drive image) to be booted by coreboot (preferably seabios and FILO) that runs a suite of tests and gathers the results. The tool may also be run on vendor BIOS (for the Red Hat and Canonical developers that work on these) to verify is an issue created/fixed by coreboot or seabios?).
 +
 
 +
When applying for this task, please state in your proposal what you think the base image/kernel would be used, the method of generating the image, what test you are targeting, and how results are gathered.  
  
 
'''Links'''
 
'''Links'''
Line 17: Line 17:
 
* http://biosbits.org/  
 
* http://biosbits.org/  
 
* http://linuxfirmwarekit.org/
 
* http://linuxfirmwarekit.org/
 +
* http://article.gmane.org/gmane.comp.video.dri.devel/63948
 +
* https://help.ubuntu.com/community/LiveCDCustomization
 
* [[Supported Motherboards]]
 
* [[Supported Motherboards]]
 +
 +
'''Skill Level'''
 +
* coreboot and firmware: novice
 +
* Linux scripting and application development: competent
 +
 +
'''Requirements'''
 +
* A coreboot mainboard 
  
 
'''Mentors'''
 
'''Mentors'''
 
* [[User:MJones|Marc Jones]]
 
* [[User:MJones|Marc Jones]]
 +
* [[User:PatrickGeorgi|Patrick Georgi]]
 +
* [[User:MartinRoth|Martin Roth]]
 +
* [[User:Jason Wang| QingPei Wang]]
 +
<br/><br/>
 +
 +
== coreboot mainboard test result reporting ==
 +
 +
One of the biggest challenges in coreboot is that it supports many systems in the same codebase. As  coreboot develop and systems age, 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
 +
* http://www.flashrom.org/Supported_hardware
 +
 +
'''Skill Level'''
 +
* coreboot and firmware: novice
 +
* wiki and web application development: competent
 +
 +
'''Requirements'''
 +
* LAMP setup
 +
 +
'''Mentors'''
 +
* [[User:Stepan|Stefan Reinauer]]
 +
* [[User:MJones|Marc Jones]]
 +
<br/><br/>
  
 
== Infrastructure for automatic code checking ==
 
== 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:
+
 
 +
coreboot has a build bot that builds various configurations of coreboot on every gerrit commit. We would like to extend the current build infrastructure 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?)
 
* 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
 
* 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.
 
* 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'''
 
'''Links'''
 
* LLVM tools: [http://clang.llvm.org/StaticAnalysis.html Clang static analyser], [http://llvm.org/ProjectsWithLLVM/#Calysto SSA assertion checker], http://klee.llvm.org/
 
* 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]
 
* 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/
 
* Semantic Tester: https://code.google.com/p/c-semantics/
 
* [http://frama-c.com/ Frama-C]
 
* [http://frama-c.com/ Frama-C]
 +
 +
'''Skill Level'''
 +
* coreboot and firmware: novice
 +
* compiler build and makefile knowledge: competent
 +
* Jenkins and test automation: novice
 +
 +
'''Requirements'''
 +
* coreboot build environment 
 +
  
 
'''Mentors'''
 
'''Mentors'''
* [[User:Stepan|Stefan Reinauer]], [[User:PatrickGeorgi|Patrick Georgi]]
+
* [[User:Stepan|Stefan Reinauer]]
 +
* [[User:PatrickGeorgi|Patrick Georgi]]
 +
<br/><br/>
  
== coreboot test suite ==
+
== coreboot ports for mainboards ==  
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.
+
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.
  
'''Links'''
+
'''Skill Level'''
* [http://biosbits.org/ BITS]
+
* coreboot and firmware: novice to competent
* [[Supported Motherboards]]
+
 
 +
 
 +
'''Requirements'''
 +
* mainboard to port
 +
* flash recovery mechanism
  
 
'''Mentors'''
 
'''Mentors'''
* [[User:MJones|Marc Jones]], [[User:PatrickGeorgi|Patrick Georgi]]
+
* [[User:ruik|Rudolf Marek]]
 +
* [[User:MartinRoth|Martin Roth]]
 +
* [[User:MJones|Marc Jones]]
 +
* [[User:Jason Wang|QingPei Wang]]
 +
<br/><br/>
  
== coreboot cheap testing rig ==
+
== coreboot ARM SoC's mainboard port==
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.
+
While the links below are still relevant, there's now a coreboot port for ARM Exynos5. It was contributed by Google and the chip is used in a Chromebook. The port isn't quite done, but some of the heavy lifting is done, so ports to other SoCs should be easier.
 +
* [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]
  
'''Links'''
+
[[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.
* [[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.
+
 
 +
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/
 +
 
 +
 
 +
'''Skill Level'''
 +
* coreboot and firmware: competent to expert
 +
* ARM architecture: novice to competent
 +
 
 +
'''Requirements'''
 +
* ARM mainboard
 +
* flash recovery mechanism
  
 
'''Mentors'''
 
'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]
+
* [[User:Rminnich|Ron Minnich]]
 +
* [[User:Jason Wang|QingPei Wang]]
 +
<br/><br/>
  
== coreboot mainboard test result reporting ==
+
== Implement advanced coreboot features on existing mainboards ==
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.
+
 
 +
A lot of cool new coreboot features are only available on a small subset of the supported mainboards. Those features include:
 +
* global variables in romstage
 +
* relocatable ramstage
 +
* cbmem console
 +
* timestamps/performance data
 +
 
 +
This project would identify how to bring those features forward to more boards and complete porting of said mainboards.
 +
 
 +
'''Skill Level'''
 +
* coreboot and firmware: competent
 +
 
 +
'''Requirements'''
 +
* coreboot mainboard(s)
  
'''Links'''
 
* http://openbenchmarking.org/
 
* http://www.coreboot.org/Supported_Motherboards
 
  
 
'''Mentors'''
 
'''Mentors'''
 
* [[User:Stepan|Stefan Reinauer]]
 
* [[User:Stepan|Stefan Reinauer]]
 
* [[User:MJones|Marc Jones]]
 
* [[User:MJones|Marc Jones]]
 +
<br/><br/>
  
 +
== coreboot ACPI 4.0 and S3 power management  ==
  
== coreboot ports for mainboards ==
+
coreboot has support for ACPI tables and S3 support for some platforms, but the implementations are mainboard specific and mostly based on ACPI 2.0. Create a generic solution for ACPI 4.0 table generation and S3 support across all 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.
+
 
 +
'''Skill Level'''
 +
* coreboot and firmware: competent to expert
 +
* ACPI and power managment: novice to competent
 +
 
 +
'''Requirements'''
 +
* coreboot mainboard
 +
* flash recovery mechanism 
  
 
'''Mentors'''
 
'''Mentors'''
 +
* [[User:ruik|Rudolf Marek]]
 +
* Martin Roth
 +
* [[User:MJones|Marc Jones]]
 +
<br/><br/>
  
 
== Tianocore as payload ==
 
== 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".
+
What SeaBIOS is for PC-BIOS interfaces, Tianocore is for UEFI. Tianocore is the reference implementation that most commercial UEFIs are built on. While coreboot favors other design goals than UEFI, it is 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.
+
There's already some code, but there's still much room for improvement: A graphics driver that uses a pre-initialized (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.
 
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.
Line 94: Line 182:
 
* http://www.tianocore.org/
 
* http://www.tianocore.org/
 
* https://github.com/pgeorgi/edk2/tree/coreboot-pkg
 
* https://github.com/pgeorgi/edk2/tree/coreboot-pkg
 +
* https://trello.com/board/tiano-payload/510e8a0693c71c3256006e00 (possible TODOs for the project)
  
  
'''Mentors'''
+
'''Skill Level'''
* [[User:Stepan|Stefan Reinauer]]
+
* coreboot: competent to expert
* [[User:PatrickGeorgi|Patrick Georgi]]
+
* UEFI/BIOS firmare: novice to competent
  
 +
'''Requirements'''
 +
* coreboot mainboard
  
== 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'''
 
'''Mentors'''
*
+
* [[User:Stepan|Stefan Reinauer]]
 +
* [[User:PatrickGeorgi|Patrick Georgi]]
 +
<br/><br/>
  
 +
== coreboot cheap testing rig ==
  
==coreboot port to ARM SOC's with PCIe==
+
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]
  
[http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm Xilinx Zynq-7030]
+
The initial version of our testing rig used a remote power switch and was rather expensive. With cheaper technologies such as [http://en.wikipedia.org/wiki/X10_%28industry_standard%29 X10], it's possible to drop the testing costs per board significantly.
  
[http://www.altera.com/devices/fpga/cyclone-v-fpgas/hard-processor-system/cyv-soc-hps.html  Altera Cyclone V ]
+
'''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.
[http://www.st.com/internet/mcu/product/251211.jsp  ST spear1340]
+
  
 +
'''Skill Level'''
 +
* coreboot and firmware: novice
 +
* hardware automation: novice to competent
  
[[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.
+
'''Requirements'''
 +
* able to acquire and develop hardware to be used in automation 
  
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.
+
'''Mentors'''
We will need to find the right platform to do the work, but I (Ron) can provide a board and JTAG debugger if needed.
+
* [[User:Stepan|Stefan Reinauer]]
 +
<br/><br/>
  
There was an ARM project started in 2011.
+
== coreboot panic room ==
  
http://blogs.coreboot.org/blog/2011/05/11/gsoc2011-project-porting-coreboot-to-arm-architecture/
+
Create a safe boot solution for coreboot to easily and cheaply recover the system.  
  
'''Mentors'''
+
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.
* 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().
+
Having this capability opens up new possibilities:
  
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.  
+
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).
  
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.
+
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.
  
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).
+
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.
  
  
Line 154: Line 249:
 
* Use SMBus/SMLink to send POST failure codes over ethernet using integrated network controllers.
 
* Use SMBus/SMLink to send POST failure codes over ethernet using integrated network controllers.
 
* After panic(), dump RAM contents before they are overwritten.
 
* After panic(), dump RAM contents before they are overwritten.
 +
 +
'''Skill Level'''
 +
* coreboot: competent to expert
 +
 +
'''Requirements'''
 +
* coreboot mainboard
 +
* flash recovery mechanism
  
  
 
'''Mentors'''
 
'''Mentors'''
 
* [[User:Rminnich|Ron Minnich]]
 
* [[User:Rminnich|Ron Minnich]]
 +
<br/><br/>
  
 
== Board config infrastructure ==
 
== 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.
 
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.
 +
 +
We had some data structure work being done in coreboot v3 (based on DTS device tree source), but the approach back then didn't have the desired results. Still, if you want to tackle this task you can get some valuable information in past coreboot v3 discussions about what's feasible and what's infeasible.
  
 
'''Links'''
 
'''Links'''
* ?
+
* Check out the various devicetree.cb files in the src/ directory of the coreboot repository.
  
 
'''Mentors'''
 
'''Mentors'''
* ?
+
* [[User:PatrickGeorgi|Patrick Georgi]]
 
+
* [[User:MJones|Marc Jones]]
 +
<br/><br/>
  
 
== Refactor AMD code ==
 
== Refactor AMD code ==
Line 177: Line 283:
  
 
'''Links'''
 
'''Links'''
* ?
+
* src/cpu/amd/ inside the coreboot source tree
 +
 
 +
'''Skill Level'''
 +
* coreboot: competent
 +
 
 +
'''Requirements'''
 +
* AMD coreboot mainboard and required silicon
 +
* flash recovery mechanism
  
 
'''Mentors'''
 
'''Mentors'''
 
* [[User:Stepan|Stefan Reinauer]]
 
* [[User:Stepan|Stefan Reinauer]]
 +
* [[User:MJones|Marc Jones]]
 +
* [[User:Jason Wang| QingPei Wang]]
 +
* Martin Roth
 +
<br/><br/>
 +
 +
== AMD VSA ==
 +
 +
Get the existing source code of AMD's VSA compiled and working with an open source toolchain. Integrate it into the current build system.
 +
 +
'''Links'''
 +
* [[OpenVSA]], [[AMD Geode Porting Guide]]
 +
 +
'''Skill Level'''
 +
* coreboot: competent
 +
 +
'''Requirements'''
 +
* coreboot mainboard that uses VSA
 +
* flash recovery mechanism
 +
 +
'''Mentors'''
 +
* [[User:MJones|Marc Jones]]
 +
* Martin Roth
 +
<br/><br/>
 +
 +
== Native graphics init ==
 +
 +
Implement native initialization of the graphics hardware (probably AMD or Intel) so no Video BIOS is needed.
 +
 +
This should be added in a maintainable way, that means that updates in the Linux code, if that is used to build upon, can be easily integrated. The code needs to be structured in such a way, that – at least for a certain generation – other boards can use native graphics initialization.
 +
 +
A test and performance possibility, like a payload testing the correct initialization, needs to be added too.
 +
 +
This could be done in combination with making a board port.
 +
 +
'''Links'''
 +
* [https://docs.google.com/document/d/1g8FMob25VZYxbWri2iFB8YiSL8gwF9vKJH3HGxr0xQU/edit?pli=1# Fast User Interface – Death to Video BIOS]
 +
* [http://www.coreboot.org/pipermail/coreboot/2013-March/075512.html Small discussion about initialization of AMD graphics hardware]
 +
* [http://www.coreboot.org/pipermail/coreboot/2013-April/075655.html “Recruitment” message to mailing lists]
 +
 +
'''Skill Level'''
 +
* coreboot: competent
 +
* Linux graphics stack: competent
 +
 +
'''Requirements'''
 +
* coreboot mainboard
 +
* flash recovery mechanism
 +
 +
'''Mentors'''
 +
* …
 +
<br/><br/>
 +
 +
== End user flash tool ==
 +
 +
A tool that takes a coreboot image without payload, and payload binaries (so the user can select which payload to use), combines them according to user wishes.
 +
It copies other required components (EC/ME firmware, VGABIOS) from the running system (ie. dump flash, extract data) and compares their hash against a white list (so we can vouch for their compatibility), then writes the result to flash, unlocking flash if necessary.
 +
 +
Ideally it's a portable graphical tool (assuming that flashrom is available for the target OS). It could use flashrom, the bios_extract tools, and cbfstool in the background and provide the glue to make things work.
 +
 +
'''Skill Level'''
 +
* coreboot: novice
 +
* Systems programming, GUI programming: competent
 +
 +
'''Requirements'''
 +
* coreboot mainboard
 +
* flash recovery mechanism
 +
 +
'''Mentors'''
 +
* …
 +
<br/><br/>
 +
 +
= flashrom Projects =
 +
 +
Flashrom is a project that is closely associated with coreboot and we work together where possible. They maintain a list of project ideas on their own website:
 +
 +
[http://www.flashrom.org/GSoC flashrom project ideas]
 +
 +
 +
'''Mentors'''
 +
* [[User:Dhendrix|David Hendricks]]
 +
* [http://www.flashrom.org/User:Roysjosh Joshua Roys]
 +
* [http://www.flashrom.org/User:Hailfinger Carl-Daniel Hailfinger]
 +
<br/><br/>
 +
 +
= SerialICE Projects =
 +
 +
SerialICE is a project that started out as tool for coreboot development. They maintain a list of project ideas on their own website:
 +
 +
 +
* [http://serialice.com/GSoC SerialICE project ideas]

Revision as of 08:28, 22 April 2013

The following are ideas that have been proposed in the community. These are projects that we think can be managed in the short period of GSoC, and they cover areas where coreboot is trying to reach new users and new use cases. But of course these are not the only things that could be done. Maybe you have a great idea that we just didn't think of yet. Please let us know!


Prospective GSoC students' application should expand on the ideas and provide specific information in the application. If you have questions or comments, please please contact the coreboot mailing list or visit our IRC channel #coreboot on irc.freenode.net. Our GSoC#Mentors are here to help.


coreboot Projects

coreboot mainboard test suite

Create a single tool (most likely a bootable CD/USB drive image) to be booted by coreboot (preferably seabios and FILO) that runs a suite of tests and gathers the results. The tool may also be run on vendor BIOS (for the Red Hat and Canonical developers that work on these) to verify is an issue created/fixed by coreboot or seabios?).

When applying for this task, please state in your proposal what you think the base image/kernel would be used, the method of generating the image, what test you are targeting, and how results are gathered.

Links

Skill Level

  • coreboot and firmware: novice
  • Linux scripting and application development: competent

Requirements

  • A coreboot mainboard

Mentors



coreboot mainboard test result reporting

One of the biggest challenges in coreboot is that it supports many systems in the same codebase. As coreboot develop and systems age, 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

Skill Level

  • coreboot and firmware: novice
  • wiki and web application development: competent

Requirements

  • LAMP setup

Mentors



Infrastructure for automatic code checking

coreboot has a build bot that builds various configurations of coreboot on every gerrit commit. We would like to extend the current build infrastructure 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

Skill Level

  • coreboot and firmware: novice
  • compiler build and makefile knowledge: competent
  • Jenkins and test automation: novice

Requirements

  • coreboot build environment


Mentors



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.

Skill Level

  • coreboot and firmware: novice to competent


Requirements

  • mainboard to port
  • flash recovery mechanism

Mentors



coreboot ARM SoC's mainboard port

While the links below are still relevant, there's now a coreboot port for ARM Exynos5. It was contributed by Google and the chip is used in a Chromebook. The port isn't quite done, but some of the heavy lifting is done, so ports to other SoCs should be easier.

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/


Skill Level

  • coreboot and firmware: competent to expert
  • ARM architecture: novice to competent

Requirements

  • ARM mainboard
  • flash recovery mechanism

Mentors



Implement advanced coreboot features on existing mainboards

A lot of cool new coreboot features are only available on a small subset of the supported mainboards. Those features include:

  • global variables in romstage
  • relocatable ramstage
  • cbmem console
  • timestamps/performance data

This project would identify how to bring those features forward to more boards and complete porting of said mainboards.

Skill Level

  • coreboot and firmware: competent

Requirements

  • coreboot mainboard(s)


Mentors



coreboot ACPI 4.0 and S3 power management

coreboot has support for ACPI tables and S3 support for some platforms, but the implementations are mainboard specific and mostly based on ACPI 2.0. Create a generic solution for ACPI 4.0 table generation and S3 support across all mainboards.

Skill Level

  • coreboot and firmware: competent to expert
  • ACPI and power managment: novice to competent

Requirements

  • coreboot mainboard
  • flash recovery mechanism

Mentors



Tianocore as payload

What SeaBIOS is for PC-BIOS interfaces, Tianocore is for UEFI. Tianocore is the reference implementation that most commercial UEFIs are built on. While coreboot favors other design goals than UEFI, it is 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 pre-initialized (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


Skill Level

  • coreboot: competent to expert
  • UEFI/BIOS firmare: novice to competent

Requirements

  • coreboot mainboard


Mentors



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:

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.

Skill Level

  • coreboot and firmware: novice
  • hardware automation: novice to competent

Requirements

  • able to acquire and develop hardware to be used in automation

Mentors



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

Skill Level

  • coreboot: competent to expert

Requirements

  • coreboot mainboard
  • flash recovery mechanism


Mentors



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.

We had some data structure work being done in coreboot v3 (based on DTS device tree source), but the approach back then didn't have the desired results. Still, if you want to tackle this task you can get some valuable information in past coreboot v3 discussions about what's feasible and what's infeasible.

Links

  • Check out the various devicetree.cb files in the src/ directory of the coreboot repository.

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

  • src/cpu/amd/ inside the coreboot source tree

Skill Level

  • coreboot: competent

Requirements

  • AMD coreboot mainboard and required silicon
  • flash recovery mechanism

Mentors



AMD VSA

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

Links

Skill Level

  • coreboot: competent

Requirements

  • coreboot mainboard that uses VSA
  • flash recovery mechanism

Mentors



Native graphics init

Implement native initialization of the graphics hardware (probably AMD or Intel) so no Video BIOS is needed.

This should be added in a maintainable way, that means that updates in the Linux code, if that is used to build upon, can be easily integrated. The code needs to be structured in such a way, that – at least for a certain generation – other boards can use native graphics initialization.

A test and performance possibility, like a payload testing the correct initialization, needs to be added too.

This could be done in combination with making a board port.

Links

Skill Level

  • coreboot: competent
  • Linux graphics stack: competent

Requirements

  • coreboot mainboard
  • flash recovery mechanism

Mentors



End user flash tool

A tool that takes a coreboot image without payload, and payload binaries (so the user can select which payload to use), combines them according to user wishes. It copies other required components (EC/ME firmware, VGABIOS) from the running system (ie. dump flash, extract data) and compares their hash against a white list (so we can vouch for their compatibility), then writes the result to flash, unlocking flash if necessary.

Ideally it's a portable graphical tool (assuming that flashrom is available for the target OS). It could use flashrom, the bios_extract tools, and cbfstool in the background and provide the glue to make things work.

Skill Level

  • coreboot: novice
  • Systems programming, GUI programming: competent

Requirements

  • coreboot mainboard
  • flash recovery mechanism

Mentors



flashrom Projects

Flashrom is a project that is closely associated with coreboot and we work together where possible. They maintain a list of project ideas on their own website:

flashrom project ideas


Mentors



SerialICE Projects

SerialICE is a project that started out as tool for coreboot development. They maintain a list of project ideas on their own website: