Documentation is now handled by the same processes we use for code: Add something to the Documentation/ directory in the coreboot repo, and it will be rendered to https://doc.coreboot.org/. Contributions welcome!
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.
Currently multiple boards have chipsets that can support SR-IOV with ARI however this feature is not implemented in coreboot. It is very useful to have for a real server platform.
Skill Level
Currently boards like the H8SCM and AM1ML have a functional IOMMU (according to AMD) however it is not implemented in coreboot.
These boards would be great to have as an introductory users option ($30 used vs $400 for a kgpe-d16) as they can theoretically be functional as blob free (no external flash signing enforcement measures) and they are the last owner controlled x86 boards.
Links
Skill Level
At the moment memtest86+ runs in legacy text mode, which doesn't work with VESA framebuffer or UEFI framebuffer. Having support for new hardware generations would be great, as those do not use legacy text mode any more.
Links
Skill Level
Requirements
Mentors
Create a tool (possibly a bootable CD/USB drive image) to be run on a platform booted with coreboot (using SeaBIOS, GRUB, FILO or some other method) that runs a suite of tests and gathers the results. The tool may also be run on vendor BIOS to verify 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.
Possibilities for a container for the tool could include:
Possibilities for tests:
Links
Skill Level
Requirements
Mentors
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. Because of this, we have an increasing interest in automated tests on real hardware, with reporting. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. Build something more scalable than the current system of git repository + Supported Motherboards.
There should be an authenticated reporting endpoint and some web frontend, that can run on a typical linux system (ultimately hosted on coreboot.org). It should be possible to filter for various criteria. Feature extraction from log files would be a good idea, too. It should also be possible to import the existing data set. Language/framework/library is pretty much your choice, but shouldn't be too exotic unless you can convince us that you intend to maintain it for the long term.
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
Requirements
Mentors
As RISCV continues to evolve, so must coreboot. There are three major tasks here:
Links
Skill Level
Requirements
Mentors
Ron Minnich
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:
Links
Skill Level
Requirements
Mentors
A lot of cool new coreboot features are only available on a small subset of the supported mainboards. Those features include:
This project would identify how to bring those features forward to more boards and complete porting of said mainboards.
Skill Level
Requirements
Mentors
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
Requirements
Mentors
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:
There are remaining open tasks to:
Skill Level
Requirements
Mentors
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
Mentors
Create a simple interface to access block devices, such as NAND, SD cards, MMC, etc. This is needed on some lower-end ARM SoCs in order to load successive coreboot stages.
Example: On Allwinner A10 SoCs, the hardware bootloader will load up to a 24KiB bootblock. That's barely sufficient to initialize DRAM and load the next stage from MMC, and is nowhere near enough to run all stages of coreboot. Coreboot will need to know how to read MMC.
Links
Skill Level
Requirements
Mentors
Implement native initialization of the graphics hardware (probably AMD or Intel) so no Video BIOS is needed.
AMD:
Intel:
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
Requirements
Mentors
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 libflashrom, the bios_extract tools, and cbfstool in the background and provide the glue to make things work.
Additional info about the purpose of this tool: The challenge is to give users a simple way to create a working coreboot image with all the necessary components, including the components we can't provide as coreboot.org downloads for technical or legal reasons. This tool is intended as one-stop shop (one-click tool by default) to create working images without the user having to worry about which options are correct for his/her system. If any options are not applicable for a given system or if those options might result in a system not booting as expected, they should not be shown at all. It is explicitly not desired to just get a GUI exposing the complexity of the underlying tools (we have that, and it's called the command line).
Technical challenges for the design and implementation: To provide a working image for a given board, hardware peculiarities have to be handled automatically as much as possible. The tool has to
The complexity of that logic is very hard to handle if you're open-coding everything, and it might make sense to either invent a language for the rules and actions mentioned above or use JSON or XML wisely. Please note that the tool itself is not supposed to be written in JSON or XML, but rather a cross-platform capable language, preferably with a graphical (i.e. not text mode) user interface.
Providing example logic for one supported coreboot mainboard (not qemu!) based on wiki contents (e.g. for Thinkpad T60) would be a goal as well.
Skill Level
Requirements
Mentors
Skill Level
Requirements
Mentors
== This would involve refactoring the current print system, and allowing sections to enable/disable different levels of output. coreboot currently has a very basic way to do this, turning debug on and off for various sections at build time. Something that is significantly more granular would be nice, and something that could be updated at runtime would be good.
Skill Level
Requirements
Mentors
Not all boards have an accessible serial port, but all boards with socketed RAM have a somehow accessible SMBus (used for reading the SPD-EEPROMs), which can be used very early in the boot process. As a device to receive the logs for example a beaglebone black or a cheap stm32 board with the i2c-star firmware can be used. The console via SMBus isn't that much slower than a serial console and ways faster than the speakermodem output.
Skill Level
Requirements
Mentors
Develop mainboard/chipset support for a ARM64 qemu target. In order to work on ARM64 code one usually needs a ARM64 board. To reduce that barrier, work on a ARM64 qemu port.
Skill Level
Requirements
Mentors
U-Boot already will run as a coreboot payload, but it needs to be modified for each different platform. Some work has already been done to add it to the coreboot build as a payload, but it still doesn't work correctly in a generic fashion. It also won't currently build with the coreboot toolchain.
This project will require work on both the coreboot and U-Boot projects.
Skill Level
Requirements
Mentors
Provides packages/installers of our compiler toolchain for Linux distros, Windows, Mac OS. For Windows, this should also include the environment (shell, make, ...).
Skill Level
Requirements
Mentors
pgeorgi
Write ACPI code to allow Nvidia Optimus support on enabled devices (Lenovo T520/T530/T430/T430s/T420 ...).
Skill Level
Requirements
Mentors
Extend the coreboot kernel modules and expose as much information as possible to sysfs. Example: Timestamps collected during boot.
Skill Level
Requirements
Mentors
Find out how to enable vboot by default on all compatible platforms:
Skill Level
Requirements
Mentors
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:
Mentors
SerialICE is a project that started out as tool for coreboot development. They maintain a list of project ideas on their own website:
Mentors
The ROM-O-Matic is envisioned to be a build server that would be usable by the general public to build ROMS for their mainboards without the need to set up coreboot build system themselves. The coreboot project does not distribute ROM files, requiring users to build their own ROMs.
It could be developed in a series of steps:
Mentors