GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/Documentation/contributing/project_ideas.md

187 lines
8.4 KiB
Markdown
Raw Normal View History

Documentation: Add Project Ideas document We already had such a page on the wiki, but it's outdated and the wiki is supposed to go the way of the dodo anyway. This is a fresh start to make sure that all ideas we're coming up with are still current and that there are mentors willing to support them. Change-Id: Idd68f845930bd37a2293969b9a153cf584d6d15f Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/30972 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-01-16 22:40:01 +01:00
# Project Ideas
This section collects ideas to improve coreboot and related projects and
should serve as a pool of ideas for people who want to enter the field
of firmware development but need some guidance what to work on.
These tasks can be adopted as part of programs like Google Summer of
Code or by motivated individuals outside such programs.
Each entry should outline what would be done, the benefit it brings
to the project, the pre-requisites, both in knowledge and parts. They
should also list people interested in supporting people who want to work
on them - since we started building this list for Google Summer of Code,
we'll adopt its term for those people and call them mentors.
Documentation: take the sting out of the requirements The requirements read a bit as if we only encourage coreboot experts to try to take on these projects. These requirements should be understood as "this is what you'll need to learn", hopefully guiding interested people in picking a project that suits their interests. Change-Id: I43b6e2e0df5f00e1ded8d14cee8c771e3f595ce7 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/31480 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-19 10:16:20 +01:00
The requirements for each project aim for productive work on the project,
but it's always possible to learn them "on the job". If you have any
doubt if you can bring yourself up to speed in a required time frame
(e.g. for GSoC), feel free to ask in the community or the mentors listed
with the projects. We can then try together to figure out if you're a
good match for a project, even when requirements might not all be met.
Documentation: Add Project Ideas document We already had such a page on the wiki, but it's outdated and the wiki is supposed to go the way of the dodo anyway. This is a fresh start to make sure that all ideas we're coming up with are still current and that there are mentors willing to support them. Change-Id: Idd68f845930bd37a2293969b9a153cf584d6d15f Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/30972 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-01-16 22:40:01 +01:00
## Provide toolchain binaries
Our crossgcc subproject provides a uniform compiler environment for
working on coreboot and related projects. Sadly, building it takes hours,
which is a bad experience when trying to build coreboot the first time.
Provide packages/installers of our compiler toolchain for Linux distros,
Windows, Mac OS. For Windows, this should also include the environment
Documentation/project_ideas: Update after 2019 The coverity project is done, for the most part, so drop it. Expand a bit on the scope of the toolchain binary project, and point out that the Ghidra project already has code from GSoC 2019 but could be developed further. Change-Id: I7342cc3133494f69b175b11b1f8342a0f40840e7 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39086 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jacob Garber <jgarber1@ualberta.ca> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2020-02-23 09:51:07 +01:00
(shell, make, ...). A student doesn't have to cover _all_ platforms, but
pick a set of systems that match their interest and knowledge and lay
out a plan on how to do this.
Documentation: Add Project Ideas document We already had such a page on the wiki, but it's outdated and the wiki is supposed to go the way of the dodo anyway. This is a fresh start to make sure that all ideas we're coming up with are still current and that there are mentors willing to support them. Change-Id: Idd68f845930bd37a2293969b9a153cf584d6d15f Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/30972 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-01-16 22:40:01 +01:00
Docs/project_ideas: Expand "toolchain" project description One-off packages do us little good, we need to be able to automate building them. Change-Id: Idd9b6b231435ea9d6e946c7ccaa71174b497742c Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31804 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-03-07 13:49:14 +01:00
The scripts to generate these packages should be usable on a Linux
host, as that's what we're using for our automated build testing system
that we could extend to provide current packages going forward. This
might include automating some virtualization system (eg. QEMU or CrosVM) for
non-Linux builds or Docker for different Linux distributions.
Documentation: Add Project Ideas document We already had such a page on the wiki, but it's outdated and the wiki is supposed to go the way of the dodo anyway. This is a fresh start to make sure that all ideas we're coming up with are still current and that there are mentors willing to support them. Change-Id: Idd68f845930bd37a2293969b9a153cf584d6d15f Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/30972 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-01-16 22:40:01 +01:00
### Requirements
* coreboot knowledge: Should know how to build coreboot images and where
the compiler comes into play in our build system.
* other knowledge: Should know how packages or installers for their
target OS work. Knowledge of the GCC build system is a big plus
* hardware requirements: Nothing special
### Mentors
* Patrick Georgi <patrick@georgi.software>
## Support Power9/Power8 in coreboot
There are some basic PPC64 stubs in coreboot, and there's open hardware
in TALOS2 and its family. While they already have fully open source
firmware, coreboot support adds a unified story for minimal firmware
across architectures.
### Requirements
* coreboot knowledge: Should be familiar with making chipset level
changes to the code.
* other knowledge: A general idea of the Power architecture, the more,
the better
* hardware requirements: QEMU Power bring-up exists, and even if it
probably needs to be fixed up, that shouldn't be an exceedingly large
task. For everything else, access to real Power8/9 hardware and recovery
tools (e.g. for external flashing) is required.
### Mentors
* Timothy Pearson <tpearson@raptorengineering.com>
Documentation: Add KASAN to the project ideas list Adding the Kernel Address Sanitizer feature to coreboot would help to find bugs. Change-Id: If00010e81147ec50e037678230df17c6888e40a2 Signed-off-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-on: https://review.coreboot.org/c/31414 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-02-14 13:15:38 +01:00
## Add Kernel Address Sanitizer functionality to coreboot
The Kernel Address Sanitizer (KASAN) is a runtime dynamic memory error detector.
The idea is to check every memory access (variables) for its validity
during runtime and find bugs like stack overflow or out-of-bounds accesses.
Implementing this stub into coreboot like "Undefined behavior sanitizer support"
would help to ensure code quality and make the runtime code more robust.
### Requirements
* knowledge in the coreboot build system and the concept of stages
* the KASAN feature can be improved in a way so that the memory space needed
during runtime is not on a fixed address provided during compile time but
determined during runtime. For this to achieve a small patch to the GCC will
be helpful. Therefore minor GCC knowledge would be beneficial.
* Implementation can be initially done in QEMU and improved on different
mainboards and platforms
### Mentors
* Werner Zeh <werner.zeh@gmx.net>
Documentation: Add broader payload coverage to project ideas A couple people discussed recently how it's a shame that on some architectures we can bring up a device but then have nothing to do with it afterwards. Having payloads to choose from would help a lot there. Change-Id: Ia66f22947d09afe3076cc2ee12f5b652fe80fc3a Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/31415 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2019-02-14 13:24:44 +01:00
Remove MIPS architecture The MIPS architecture port has been added 5+ years ago in order to support a Chrome OS project that ended up going nowhere. No other board has used it since and nobody is still willing or has the expertise and hardware to maintain it. We have decided that it has become too much of a mainenance burden and the chance of anyone ever reviving it seems too slim at this point. This patch eliminates all MIPS code and MIPS-specific hacks. Change-Id: I5e49451cd055bbab0a15dcae5f53e0172e6e2ebe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34919 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-08-17 00:35:39 +02:00
## Port payloads to ARM, AArch64 or RISC-V
Documentation: Add broader payload coverage to project ideas A couple people discussed recently how it's a shame that on some architectures we can bring up a device but then have nothing to do with it afterwards. Having payloads to choose from would help a lot there. Change-Id: Ia66f22947d09afe3076cc2ee12f5b652fe80fc3a Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/31415 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2019-02-14 13:24:44 +01:00
While we have a rather big set of payloads for x86 based platforms, all other
architectures are rather limited. Improve the situation by porting a payload
to one of the platforms, for example GRUB2, U-Boot (the UI part), Tianocore,
yabits, FILO, or Linux-as-Payload.
Since this is a bit of a catch-all idea, an application to GSoC should pick a
combination of payload and architecture to support.
### Requirements
* coreboot knowledge: Should know the general boot flow in coreboot
* other knowledge: It helps to be familiar with the architecture you want to
work on.
* hardware requirements: Much of this can be done in QEMU or other emulators,
but the ability to test on real hardware is a plus.
### Mentors
* Simon Glass <sjg@chromium.org> for U-Boot payload projects
Documentation: Add Clang support to project ideas Change-Id: Iaccb5ca5606b83a4b37930b4399ddcf9eddd494b Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/31479 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-02-19 10:13:16 +01:00
## Fully support building coreboot with the Clang compiler
Most coreboot code is written in C, and it would be useful to support
a second compiler suite in addition to gcc. Clang is another popular
compiler suite and the build system generally supports building coreboot
with it, but firmware is a rather special situation and we need to
adjust coreboot and Clang some more to get usable binaries out of that
combination.
The goal would be to get the emulation targets to boot reliably first,
but also to support real hardware. If you don't have hardware around,
you likely will find willing testers for devices they own and work from
their bug reports.
### Requirements
* coreboot knowledge: Have a general concept of the build system
* Clang knowledge: It may be necessary to apply minor modifications to Clang
itself, but at least there will be Clang-specific compiler options etc to
adapt, so some idea how compilers work and how to modify their behavior is
helpful.
* hardware requirements: If you have your own hardware that is already
supported by coreboot that can be a good test target, but you will debug
other people's hardware, too.
* debugging experience: It helps if you know how to get the most out of a bug
report, generate theories, build patches to test them and figure out what's
going on from the resulting logs.
### Mentors
* Patrick Georgi <patrick@georgi.software>
Docs/project_ideas: Add coverity scan cleanup project Change-Id: I16d9a7f7088254c5c207adc9299a8525bf38199f Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31805 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2019-03-07 13:50:22 +01:00
Docs/project_ideas: Add a stub for Ghidra integration It may be useful to have a common, easily available toolbench for firmware analysis and Ghidra looks promising. Change-Id: I56d0ff875bb939f6d31f088232f8a6fd168abbb6 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31806 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-03-07 13:50:42 +01:00
## Extend Ghidra to support analysis of firmware images
[Ghidra](https://ghidra-sre.org) is a recently released cross-platform
disassembler and decompiler that is extensible through plugins. Make it
useful for firmware related work: Automatically parse formats (eg. by
integrating UEFITool, cbfstool, decompressors), automatically identify
16/32/64bit code on x86/amd64, etc.
Docs/project_ideas: Add a "parse SerialICE traces" project idea Change-Id: I696811ff93948358f03ff617d294ecc40bd4c746 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31820 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2019-03-08 09:25:29 +01:00
Documentation/project_ideas: Update after 2019 The coverity project is done, for the most part, so drop it. Expand a bit on the scope of the toolchain binary project, and point out that the Ghidra project already has code from GSoC 2019 but could be developed further. Change-Id: I7342cc3133494f69b175b11b1f8342a0f40840e7 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39086 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jacob Garber <jgarber1@ualberta.ca> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2020-02-23 09:51:07 +01:00
This has been done in 2019 with [some neat
features](https://github.com/al3xtjames/ghidra-firmware-utils) being
developed, but it may be possible to expand support for all kinds of firmware
analyses.
Docs/project_ideas: Add a "parse SerialICE traces" project idea Change-Id: I696811ff93948358f03ff617d294ecc40bd4c746 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31820 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2019-03-08 09:25:29 +01:00
## Learn hardware behavior from I/O and memory access logs
[SerialICE](https://www.serialice.com) is a tool to trace the behavior of
executable code like firmware images. One result of that is a long log file
containing the accesses to hardware resources.
It would be useful to have a tool that assists a developer-analyst in deriving
knowledge about hardware from such logs. This likely can't be entirely
automatic, but a tool that finds patterns and can propagate them across the
log (incrementially raising the log from plain I/O accesses to a high-level
description of driver behavior) would be of great use.
This is a research-heavy project.
### Requirements
* Driver knowledge: Somebody working on this should be familiar with
how hardware works (eg. MMIO based register access, index/data port
accesses) and how to read data sheets.
* Machine Learning: ML techniques may be useful to find structure in traces.
### Mentors
* Ron Minnich <rminnich@google.com>
Docs/project_ideas.md: Add a memtest libpayload based payload Change-Id: Iebdb75b99e18fe92aa4c801769532781edf44d9a Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36747 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-11-11 14:06:42 +01:00
## Libpayload based memtest payload
[Memtest86+](https://www.memtest.org/) has some limitations: first and
foremost it only works on x86, while it can print to serial console the
GUI only works in legacy VGA mode.
This project would involve porting the memtest suite to libpayload and
build a payload around it.
### Requirements
* coreboot knowledge: Should know how to build coreboot images and
include payloads.
* other knowledge: Knowledge on how dram works is a plus.
* hardware requirements: Initial work can happen on qemu targets,
being able to test on coreboot supported hardware is a plus.
### Mentors
* TODO