Project Ideas: Difference between revisions

From coreboot
Jump to navigation Jump to search
No edit summary
 
(46 intermediate revisions by 13 users not shown)
Line 6: Line 6:


= coreboot Projects =
= coreboot Projects =
== Add SR-IOV support to coreboot ==
* Add SR-IOV support to coreboot
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'''
* coreboot and firmware: competent
== Add IOMMU to AGESA boards ==
* Add IOMMU to AGESA boards
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'''
* coreboot and firmware: competent
== Memtest86+ ==
* Clean memtest86+ codebase.
* Add gfx modules to support firmware other than legacy bios.
** UEFI framebuffer
** VESA framebuffer
** BIOS SVGA using VBE2.0
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'''
* http://www.memtest86.com/technical.htm
'''Skill Level'''
* coreboot and firmware: competent
* Bare metal programming: competent
'''Requirements'''
* QEMU
'''Mentors'''
<br/><br/>


== coreboot mainboard test suite  ==
== 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?).  
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.  
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:
* Downloading a script that sets up a live image to run various tests (Limits the number of tests)
* Creating a script that builds a new live image for this purpose (More flexibility)
* Customizing a distro or something to do what is needed - see the fwts-live image or BITS as examples.  Create a new bootable ISO (Most flexible, and the most work)
 
Possibilities for tests:
* Extending FWTS to check for coreboot specific items (ubuntu & FWTS-live specific)
* Parsing output of cbmem timestamps and coreboot boot log
* Rebooting with various kernel parameters to test different items
* Working with the community & coreboot vendors to develop additional tests


'''Links'''
'''Links'''
* https://wiki.ubuntu.com/Kernel/Reference/fwts
* https://wiki.ubuntu.com/Kernel/Reference/fwts
* https://wiki.ubuntu.com/FirmwareTestSuite/FirmwareTestSuiteLive
* http://biosbits.org/  
* http://biosbits.org/  
* http://linuxfirmwarekit.org/
* https://help.ubuntu.com/community/LiveCDCustomization
* http://article.gmane.org/gmane.comp.video.dri.devel/63948
* https://os-autoinst.github.io/openQA/
* [[Supported Motherboards]]
* [[Supported Motherboards]]


Line 28: Line 85:


'''Mentors'''
'''Mentors'''
* [[User:MJones|Marc Jones]]
* [https://www.coreboot.org/User:MartinRoth Martin Roth]
* [[User:PatrickGeorgi|Patrick Georgi]]
* [[User:MartinRoth|Martin Roth]]
<br/><br/>
<br/><br/>


== coreboot mainboard test result reporting ==
== coreboot mainboard test suite 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. 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 [https://review.coreboot.org/gitweb?p=board-status.git;a=tree git repository] + [[Supported Motherboards]].


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.
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'''
'''Links'''
* http://openbenchmarking.org/
* http://openbenchmarking.org/
* http://www.coreboot.org/Supported_Motherboards
* http://www.flashrom.org/Supported_hardware
* http://www.flashrom.org/Supported_hardware
* [[Supported Motherboards]]
* [https://review.coreboot.org/gitweb?p=board-status.git;a=tree Board status git repo]


'''Skill Level'''
'''Skill Level'''
* coreboot and firmware: novice
* coreboot and firmware: novice
* wiki and web application development: competent
* web development: competent
* machine learning: certainly helps building a good project


'''Requirements'''
'''Requirements'''
* LAMP setup
* web development environment


'''Mentors'''
'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]
* [[User:MJones|Marc Jones]]
<br/><br/>
<br/><br/>
== coreboot on the open source Berkeley RISC V processor ==
As RISCV continues to evolve, so must coreboot. There are three major tasks here:
* revive the 32-bit port, which got kind of overwritten in 2015 by the 64-bit port
* bring the 64-bit port inline with the silicon lowrisc.org is shipping.
* work on the 128-bit port for QEMU
'''Links'''
* http://http://riscv.org/
'''Skill Level'''
* coreboot and firmware: competent
* linux: competent
'''Requirements'''
* Need a system on which to build and run the RISCV toolchain, coreboot, and run simulators.
'''Mentors'''
<br/>Ron Minnich<br/>


== Infrastructure for automatic code checking ==
== Infrastructure for automatic code checking ==
Line 61: Line 141:
* 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.
* Implement automatic building on various OS types - FreeBSD, NetBSD, OSX, and Windows all seem to be used.


'''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/, http://oclint.org/
* Lint tools: [http://lclint.cs.virginia.edu/ Splint]
* Lint tools: [http://lclint.cs.virginia.edu/ Splint]
* Semantic Tester: https://code.google.com/p/c-semantics/
* Semantic Tester: https://code.google.com/p/c-semantics/
Line 78: Line 160:


'''Mentors'''
'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]
* [https://www.coreboot.org/User:MartinRoth Martin Roth]
* [[User:PatrickGeorgi|Patrick Georgi]]
<br/><br/>
<br/><br/>


== 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.
== 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'''
'''Skill Level'''
* coreboot and firmware: novice to competent
* coreboot and firmware: competent


'''Requirements'''
* coreboot mainboard(s)
'''Mentors'''
<br/><br/>
== 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 management: novice to competent


'''Requirements'''
'''Requirements'''
* mainboard to port
* coreboot mainboard
* flash recovery mechanism
* flash recovery mechanism


'''Mentors'''
'''Mentors'''
* [[User:ruik|Rudolf Marek]]
* [[User:MartinRoth|Martin Roth]]
* [[User:MJones|Marc Jones]]
* [[User:Jason Wang|QingPei Wang]]
<br/><br/>
<br/><br/>


== coreboot ARM SoC's mainboard port==
== 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.


While the links below are still relevant, we nowadays have a coreboot port for ARM Exynos. It was contributed by Google and the chip is used in a Chromebook. This means porting to other ARM SoCs is now easier due to generic infrastructure being in place.
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.
* [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.  
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 was an ARM project started in 2011:
http://blogs.coreboot.org/blog/2011/05/11/gsoc2011-project-porting-coreboot-to-arm-architecture/


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'''
'''Skill Level'''
* coreboot and firmware: competent to expert
* coreboot: competent to expert
* ARM architecture: novice to competent


'''Requirements'''
'''Requirements'''
* ARM mainboard
* coreboot mainboard
* flash recovery mechanism
* flash recovery mechanism


'''Mentors'''
'''Mentors'''
* [[User:Rminnich|Ron Minnich]]
* [[User:Jason Wang|QingPei Wang]]
<br/><br/>
<br/><br/>


== Implement advanced coreboot features on existing mainboards ==
== 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'''
<br/><br/>
 
== Infrastructure for accessing block devices  ==
 
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.


A lot of cool new coreboot features are only available on a small subset of the supported mainboards. Those features include:
'''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.
* 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.
'''Links'''
* [[User_talk:MrNuke/Block_Device_API | Initial proposal]]
* [[Board:cubietech/cubieboard | Cubieboard page]]


'''Skill Level'''
'''Skill Level'''
* coreboot and firmware: competent
* coreboot and ARM firmware: competent


'''Requirements'''
'''Requirements'''
* coreboot mainboard(s)
* An ARM board with low-end SoC (for example, Cubieboard, with Allwinner A10)
 


'''Mentors'''
'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]
* [[User:MJones|Marc Jones]]
<br/><br/>
<br/><br/>


== 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.  
== Native graphics init ==
 
Implement native initialization of the graphics hardware (probably AMD or Intel) so no Video BIOS is needed.
 
'''AMD''':
* Difficult as everyhting is done by AtomBios [[https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/4541-what-is-atombios-these-different-drivers]].
 
'''Intel''':
* libgfxinit made great progress to init any Intel GPU (>2nd. Gen Core I)
 
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'''
* [http://www.coreboot.org/pipermail/coreboot/2013-March/075512.html Small discussion about initialization of AMD graphics hardware]


'''Skill Level'''
'''Skill Level'''
* coreboot and firmware: competent to expert
* coreboot: competent
* ACPI and power managment: novice to competent
* Linux graphics stack: competent


'''Requirements'''
'''Requirements'''
* coreboot mainboard
* coreboot mainboard
* flash recovery mechanism
* flash recovery mechanism


'''Mentors'''
'''Mentors'''
* [[User:ruik|Rudolf Marek]]
* Ron Minnich, unless someone better comes along
* Martin Roth
* [[User:MJones|Marc Jones]]
<br/><br/>
<br/><br/>


== Tianocore as payload ==
== 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.


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


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


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.
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
* extract/dump some data/contents from the running system while coreboot is not yet installed, zero or more of the following
** EDID data
** PCI configuration (lspci -nn)
** old flash chip contents
** VGA BIOS in its mangled form dumped from memory (C segment)
** VGA BIOS in its original form extracted from the flash chip contents
** onboard network firmware/configuration/MACaddr, possibly extracted from the flash chip contents or other in-system data sources
* possibly download and mangle BIOS update files from a vendor site
** mostly in case the data mentioned above can't be extracted from the running system or in case newer data is available as download from the vendor
* detect the exact variant of the hardware including any special handling needed (e.g. there are dozens of different Thinkpad T60/T60p variants all using the exact same coreboot code, but some need a VGA option ROM and some don't, the TFT panel definitions differ, etc.)
* check whether the extracted data (mostly VGA BIOS etc.) matches the data that's known to work, e.g. by comparing hashes
* check whether the extracted data has correct internal checksums and if not, check whether fixups are needed or wanted for this particular hardware (e.g. some C segment dumps from VGA option ROMs have broken checksums and their checksums should be fixed automatically by the tool, other VGA option ROMs should yield an error instead)
* present the end user only with the choices that make sense for this specific piece of hardware
* warn the user if hardware with this exact hardware has no complete (or none at all) rule set for working images
* provide a way to import or store rules for doing all the stuff above for multiple boards or board variants


'''Links'''
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.
* http://www.tianocore.org/
* https://github.com/pgeorgi/edk2/tree/coreboot-pkg


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'''
'''Skill Level'''
* coreboot: competent to expert
* coreboot: novice
* UEFI/BIOS firmare: novice to competent
* Systems programming, GUI programming: competent


'''Requirements'''
'''Requirements'''
* coreboot mainboard
* coreboot mainboard
 
* flash recovery mechanism


'''Mentors'''
'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]
* [[User:PatrickGeorgi|Patrick Georgi]]
<br/><br/>
<br/><br/>




== coreboot cheap testing rig ==
== proper configuration support in upstream (devtree -> kconfig -> runtime values) ==
'''Skill Level'''
* coreboot: medium
* C, build system.


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:
'''Requirements'''
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/Slides-LinuxBIOS-QA.pdf Quality Assurance Talk (Slides)]
* knowledge of what types of configuration exist in coreboot
* [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.
'''Mentors'''
<br/><br/>


'''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.
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'''
'''Skill Level'''
* coreboot and firmware: novice
* coreboot: novice
* hardware automation: novice to competent
* Systems programming


'''Requirements'''
'''Requirements'''
* able to acquire and develop hardware to be used in automation 
* none - this can be tested with coreboot booting in QEMU


'''Mentors'''
'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]
<br/><br/>
<br/><br/>


== console via SMBus ==
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.


== coreboot panic room ==
'''Skill Level'''
* coreboot: medium
* soldering: medium


Create a safe boot solution for coreboot to easily and cheaply recover the system.
'''Requirements'''
* none


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.
'''Mentors'''
<br/><br/>


Having this capability opens up new possibilities:
== ARM64 qemu port ==


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


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.
'''Skill Level'''
* coreboot: medium


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.
'''Requirements'''
* none


'''Mentors'''
* adurbin
<br/><br/>


GSoC 2011 project [http://blogs.coreboot.org/blog/2011/05/09/gsoc-project-coreboot-panic-room-diagnostics-also-remote-flashing/] was able to:
== Add U-Boot as a generic coreboot payload ==
* 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.


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.


There are remaining open tasks to:
This project will require work on both the coreboot and U-Boot projects.
* 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'''
'''Skill Level'''
* coreboot: competent to expert
* coreboot: novice
* Makefile and toolchain skills: medium


'''Requirements'''
'''Requirements'''
* coreboot mainboard
* none
* flash recovery mechanism
 


'''Mentors'''
'''Mentors'''
* [[User:Rminnich|Ron Minnich]]
<br/><br/>
<br/><br/>


== Board config infrastructure ==
== Provide toolchain binaries ==


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.
Provides packages/installers of our compiler toolchain for Linux distros, Windows, Mac OS. For Windows, this should also include the environment (shell, make, ...).


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.
'''Skill Level'''
* coreboot: novice


'''Links'''
'''Requirements'''
* Check out the various devicetree.cb files in the src/ directory of the coreboot repository.
* knowledge of package/installer tooling on their target OS


'''Mentors'''
'''Mentors'''
* [[User:PatrickGeorgi|Patrick Georgi]]
<br/>pgeorgi<br/>
* [[User:MJones|Marc Jones]]
 
<br/><br/>
== Nvidia Optimus support ==
 
Write ACPI code to allow Nvidia Optimus support on enabled devices (Lenovo T520/T530/T430/T430s/T420 ...).
 
'''Skill Level'''
* coreboot: medium


== Refactor AMD code ==
'''Requirements'''
* Knownledge of ACPI, Linux graphics driver, a device that is able to run coreboot and Nvidia Optimus


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.
'''Mentors'''
* siro
<br/><br/>


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


'''Links'''
Extend the coreboot kernel modules and expose as much information as possible to sysfs.
* src/cpu/amd/ inside the coreboot source tree
Example: Timestamps collected during boot.


'''Skill Level'''
'''Skill Level'''
* coreboot: competent
* coreboot: easy


'''Requirements'''
'''Requirements'''
* AMD coreboot mainboard and required silicon
* Knownledge of Linux kernel driver development
* flash recovery mechanism


'''Mentors'''
'''Mentors'''
* [[User:Stepan|Stefan Reinauer]]
* ?
* [[User:MJones|Marc Jones]]
* Martin Roth
<br/><br/>
<br/><br/>


== AMD VSA ==
== Enable vboot by default on all platforms ==


Get the source code of AMD's VSA compiled and working with an open source toolchain. Integrate the it into the current build system.
Find out how to enable vboot by default on all compatible platforms:
 
* Adjust the default fmap
'''Links'''
* Create private key for signing
* [[OpenVSA]], [[AMD Geode Porting Guide]]
* Enable vboot in the toolchain
* Verify the signed image
* Document everything


'''Skill Level'''
'''Skill Level'''
* coreboot: competent
* coreboot: medium


'''Requirements'''
'''Requirements'''
* coreboot mainboard that uses VSA
* Knownledge of VBOOT
* flash recovery mechanism


'''Mentors'''
'''Mentors'''
* [[User:MJones|Marc Jones]]
* ?
* Martin Roth
 
<br/><br/>
<br/><br/>


= flashrom Projects =
= 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]
[http://www.flashrom.org/GSoC flashrom project ideas]




'''Mentors'''
'''Mentors'''
* David Hendricks
* Joshua Roys
* Carl-Daniel Hailfinger
<br/><br/>
<br/><br/>


= SerialICE Projects =
= 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]
* [http://serialice.com/GSoC SerialICE project ideas]
'''Mentors'''
<br/><br/>
= ROM-O-Matic =
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.
== Creation of the server ==
It could be developed in a series of steps:
# Build a very limited number of Mainboards, only from known good versions contained in the board-status repository. These would be boards that are blob-free or have all necessary blobs contained in the 3rd-party/blobs repo.
#* Either the toolchain required for the mainboard would be re-built for each build, or a cached toolchain could be used.
#* The build can be verified to match the MD5 sum of the original build.
#* User gets binaries along with source tree to satisfy licenses.
# Extend the board list to boards that needed external blobs which can be found freely available on the internet.  This would be cases where the OEM BIOS can be downloaded, and the pieces can be extracted.  Still only versions that are listed in board-status would be available for building.
#* Tools to automate the download and extraction of these blobs would need to be created.
# Allow building from any valid git commit
# Allow building any valid board.
# Allow including patches into the build for customization of the build.
#* At this point, security becomes an issue, and the build would need to be locked down, similar to the current jenkins setup, which builds in a chroot with network disabled.
# Allow additional binaries to be uploaded to be included into the build.
'''Mentors'''
* [https://www.coreboot.org/User:MartinRoth Martin Roth]
<br/><br/>

Latest revision as of 18:43, 1 February 2018

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

Add SR-IOV support to coreboot

  • Add SR-IOV support to coreboot

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

  • coreboot and firmware: competent

Add IOMMU to AGESA boards

  • Add IOMMU to AGESA boards

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

  • coreboot and firmware: competent

Memtest86+

  • Clean memtest86+ codebase.
  • Add gfx modules to support firmware other than legacy bios.
    • UEFI framebuffer
    • VESA framebuffer
    • BIOS SVGA using VBE2.0

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

  • coreboot and firmware: competent
  • Bare metal programming: competent

Requirements

  • QEMU

Mentors

coreboot mainboard test suite

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:

  • Downloading a script that sets up a live image to run various tests (Limits the number of tests)
  • Creating a script that builds a new live image for this purpose (More flexibility)
  • Customizing a distro or something to do what is needed - see the fwts-live image or BITS as examples. Create a new bootable ISO (Most flexible, and the most work)

Possibilities for tests:

  • Extending FWTS to check for coreboot specific items (ubuntu & FWTS-live specific)
  • Parsing output of cbmem timestamps and coreboot boot log
  • Rebooting with various kernel parameters to test different items
  • Working with the community & coreboot vendors to develop additional tests

Links

Skill Level

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

Requirements

  • A coreboot mainboard

Mentors



coreboot mainboard test suite 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. 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

  • coreboot and firmware: novice
  • web development: competent
  • machine learning: certainly helps building a good project

Requirements

  • web development environment

Mentors

coreboot on the open source Berkeley RISC V processor

As RISCV continues to evolve, so must coreboot. There are three major tasks here:

  • revive the 32-bit port, which got kind of overwritten in 2015 by the 64-bit port
  • bring the 64-bit port inline with the silicon lowrisc.org is shipping.
  • work on the 128-bit port for QEMU

Links

Skill Level

  • coreboot and firmware: competent
  • linux: competent

Requirements

  • Need a system on which to build and run the RISCV toolchain, coreboot, and run simulators.

Mentors
Ron Minnich


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.
  • Implement automatic building on various OS types - FreeBSD, NetBSD, OSX, and Windows all seem to be used.


Links

Skill Level

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

Requirements

  • coreboot build environment


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 management: novice to competent

Requirements

  • coreboot mainboard
  • flash recovery mechanism

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

Infrastructure for accessing block devices

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

  • coreboot and ARM firmware: competent

Requirements

  • An ARM board with low-end SoC (for example, Cubieboard, with Allwinner A10)

Mentors


Native graphics init

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

AMD:

  • Difficult as everyhting is done by AtomBios [[2]].

Intel:

  • libgfxinit made great progress to init any Intel GPU (>2nd. Gen Core I)

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

  • Ron Minnich, unless someone better comes along



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

  • extract/dump some data/contents from the running system while coreboot is not yet installed, zero or more of the following
    • EDID data
    • PCI configuration (lspci -nn)
    • old flash chip contents
    • VGA BIOS in its mangled form dumped from memory (C segment)
    • VGA BIOS in its original form extracted from the flash chip contents
    • onboard network firmware/configuration/MACaddr, possibly extracted from the flash chip contents or other in-system data sources
  • possibly download and mangle BIOS update files from a vendor site
    • mostly in case the data mentioned above can't be extracted from the running system or in case newer data is available as download from the vendor
  • detect the exact variant of the hardware including any special handling needed (e.g. there are dozens of different Thinkpad T60/T60p variants all using the exact same coreboot code, but some need a VGA option ROM and some don't, the TFT panel definitions differ, etc.)
  • check whether the extracted data (mostly VGA BIOS etc.) matches the data that's known to work, e.g. by comparing hashes
  • check whether the extracted data has correct internal checksums and if not, check whether fixups are needed or wanted for this particular hardware (e.g. some C segment dumps from VGA option ROMs have broken checksums and their checksums should be fixed automatically by the tool, other VGA option ROMs should yield an error instead)
  • present the end user only with the choices that make sense for this specific piece of hardware
  • warn the user if hardware with this exact hardware has no complete (or none at all) rule set for working images
  • provide a way to import or store rules for doing all the stuff above for multiple boards or board variants

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

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

Requirements

  • coreboot mainboard
  • flash recovery mechanism

Mentors


proper configuration support in upstream (devtree -> kconfig -> runtime values)

Skill Level

  • coreboot: medium
  • C, build system.

Requirements

  • knowledge of what types of configuration exist in coreboot

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

  • coreboot: novice
  • Systems programming

Requirements

  • none - this can be tested with coreboot booting in QEMU

Mentors

console via SMBus

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

  • coreboot: medium
  • soldering: medium

Requirements

  • none

Mentors

ARM64 qemu port

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

  • coreboot: medium

Requirements

  • none

Mentors

  • adurbin



Add U-Boot as a generic coreboot payload

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

  • coreboot: novice
  • Makefile and toolchain skills: medium

Requirements

  • none

Mentors

Provide toolchain binaries

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

  • coreboot: novice

Requirements

  • knowledge of package/installer tooling on their target OS

Mentors
pgeorgi

Nvidia Optimus support

Write ACPI code to allow Nvidia Optimus support on enabled devices (Lenovo T520/T530/T430/T430s/T420 ...).

Skill Level

  • coreboot: medium

Requirements

  • Knownledge of ACPI, Linux graphics driver, a device that is able to run coreboot and Nvidia Optimus

Mentors

  • siro



Improved Linux sysfs support

Extend the coreboot kernel modules and expose as much information as possible to sysfs. Example: Timestamps collected during boot.

Skill Level

  • coreboot: easy

Requirements

  • Knownledge of Linux kernel driver development

Mentors

  • ?



Enable vboot by default on all platforms

Find out how to enable vboot by default on all compatible platforms:

  • Adjust the default fmap
  • Create private key for signing
  • Enable vboot in the toolchain
  • Verify the signed image
  • Document everything

Skill Level

  • coreboot: medium

Requirements

  • Knownledge of VBOOT

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:


Mentors

ROM-O-Matic

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.

Creation of the server

It could be developed in a series of steps:

  1. Build a very limited number of Mainboards, only from known good versions contained in the board-status repository. These would be boards that are blob-free or have all necessary blobs contained in the 3rd-party/blobs repo.
    • Either the toolchain required for the mainboard would be re-built for each build, or a cached toolchain could be used.
    • The build can be verified to match the MD5 sum of the original build.
    • User gets binaries along with source tree to satisfy licenses.
  2. Extend the board list to boards that needed external blobs which can be found freely available on the internet. This would be cases where the OEM BIOS can be downloaded, and the pieces can be extracted. Still only versions that are listed in board-status would be available for building.
    • Tools to automate the download and extraction of these blobs would need to be created.
  3. Allow building from any valid git commit
  4. Allow building any valid board.
  5. Allow including patches into the build for customization of the build.
    • At this point, security becomes an issue, and the build would need to be locked down, similar to the current jenkins setup, which builds in a chroot with network disabled.
  6. Allow additional binaries to be uploaded to be included into the build.

Mentors



Retrieved from "https://www.coreboot.org/index.php?title=Project_Ideas&oldid=32254"