1# Project Ideas 2 3This section collects ideas to improve coreboot and related projects and 4should serve as a pool of ideas for people who want to enter the field 5of firmware development but need some guidance what to work on. 6 7These tasks can be adopted as part of programs like Google Summer of 8Code or by motivated individuals outside such programs. 9 10Each entry should outline what would be done, the benefit it brings 11to the project, the pre-requisites, both in knowledge and parts. They 12should also list people interested in supporting people who want to work 13on them - since we started building this list for Google Summer of Code, 14we'll adopt its term for those people and call them mentors. 15 16The requirements for each project aim for productive work on the project, 17but it's always possible to learn them "on the job". If you have any 18doubt if you can bring yourself up to speed in a required time frame 19(e.g. for GSoC), feel free to ask in the community or the mentors listed 20with the projects. We can then try together to figure out if you're a 21good match for a project, even when requirements might not all be met. 22 23## Small projects 24 25This is a collection of tasks which don't require deep knowledge on 26coreboot itself. If you are a beginner and want to get familiar with the 27the project and the code base, or if you just want to get your hands 28dirty with some small tasks, then these are for you. 29 30 * Resolve static analysis issues reported by [scan-build] and 31 [Coverity scan]. More details on the page for 32 [Coverity scan integration]. 33 34 * Resolve issues reported by the [linter][Linter issues] 35 36[scan-build]: https://coreboot.org/scan-build/ 37[Coverity scan]: https://scan.coverity.com/projects/coreboot 38[Coverity scan integration]: ../infrastructure/coverity.md 39[Linter issues]: https://qa.coreboot.org/job/coreboot-untested-files/lastSuccessfulBuild/artifact/lint.txt 40 41## Provide toolchain binaries 42Our crossgcc subproject provides a uniform compiler environment for 43working on coreboot and related projects. Sadly, building it takes hours, 44which is a bad experience when trying to build coreboot the first time. 45 46Provide packages/installers of our compiler toolchain for Linux distros, 47Windows, Mac OS. For Windows, this should also include the environment 48(shell, make, ...). A student doesn't have to cover _all_ platforms, but 49pick a set of systems that match their interest and knowledge and lay 50out a plan on how to do this. 51 52The scripts to generate these packages should be usable on a Linux 53host, as that's what we're using for our automated build testing system 54that we could extend to provide current packages going forward. This 55might include automating some virtualization system (eg. QEMU or CrosVM) for 56non-Linux builds or Docker for different Linux distributions. 57 58### Requirements 59* coreboot knowledge: Should know how to build coreboot images and where 60 the compiler comes into play in our build system. 61* other knowledge: Should know how packages or installers for their 62 target OS work. Knowledge of the GCC build system is a big plus 63* hardware requirements: Nothing special 64 65### Mentors 66 67## Support Power9/Power8 in coreboot 68There are some basic PPC64 stubs in coreboot, and there's open hardware 69in TALOS2 and its family. While they already have fully open source 70firmware, coreboot support adds a unified story for minimal firmware 71across architectures. 72 73### Requirements 74* coreboot knowledge: Should be familiar with making chipset level 75 changes to the code. 76* other knowledge: A general idea of the Power architecture, the more, 77 the better 78* hardware requirements: QEMU Power bring-up exists, and even if it 79 probably needs to be fixed up, that shouldn't be an exceedingly large 80 task. For everything else, access to real Power8/9 hardware and recovery 81 tools (e.g. for external flashing) is required. 82 83### Mentors 84* Timothy Pearson <[email protected]> 85 86## Port payloads to ARM, AArch64 or RISC-V 87While we have a rather big set of payloads for x86 based platforms, all other 88architectures are rather limited. Improve the situation by porting a payload 89to one of the platforms, for example GRUB2, U-Boot (the UI part), edk2, 90FILO, or Linux-as-Payload. 91 92Since this is a bit of a catch-all idea, an application to GSoC should pick a 93combination of payload and architecture to support. 94 95### Requirements 96* coreboot knowledge: Should know the general boot flow in coreboot 97* other knowledge: It helps to be familiar with the architecture you want to 98 work on. 99* hardware requirements: Much of this can be done in QEMU or other emulators, 100 but the ability to test on real hardware is a plus. 101 102### Mentors 103* Simon Glass <[email protected]> for U-Boot payload projects 104 105## Fully support building coreboot with the Clang compiler 106Most coreboot code is written in C, and it would be useful to support 107a second compiler suite in addition to gcc. Clang is another popular 108compiler suite and the build system generally supports building coreboot 109with it, but firmware is a rather special situation and we need to 110adjust coreboot and Clang some more to get usable binaries out of that 111combination. 112 113The goal would be to get the emulation targets to boot reliably first, 114but also to support real hardware. If you don't have hardware around, 115you likely will find willing testers for devices they own and work from 116their bug reports. 117 118### Requirements 119* coreboot knowledge: Have a general concept of the build system 120* Clang knowledge: It may be necessary to apply minor modifications to Clang 121 itself, but at least there will be Clang-specific compiler options etc to 122 adapt, so some idea how compilers work and how to modify their behavior is 123 helpful. 124* hardware requirements: If you have your own hardware that is already 125 supported by coreboot that can be a good test target, but you will debug 126 other people's hardware, too. 127* debugging experience: It helps if you know how to get the most out of a bug 128 report, generate theories, build patches to test them and figure out what's 129 going on from the resulting logs. 130 131### Mentors 132 133## Extend Ghidra to support analysis of firmware images 134[Ghidra](https://ghidra-sre.org) is a recently released cross-platform 135disassembler and decompiler that is extensible through plugins. Make it 136useful for firmware related work: Automatically parse formats (eg. by 137integrating UEFITool, cbfstool, decompressors), automatically identify 13816/32/64bit code on x86/amd64, etc. 139 140This has been done in 2019 with [some neat 141features](https://github.com/al3xtjames/ghidra-firmware-utils) being 142developed, but it may be possible to expand support for all kinds of firmware 143analyses. 144 145## Learn hardware behavior from I/O and memory access logs 146[SerialICE](https://www.serialice.com) is a tool to trace the behavior of 147executable code like firmware images. One result of that is a long log file 148containing the accesses to hardware resources. 149 150It would be useful to have a tool that assists a developer-analyst in deriving 151knowledge about hardware from such logs. This likely can't be entirely 152automatic, but a tool that finds patterns and can propagate them across the 153log (incrementially raising the log from plain I/O accesses to a high-level 154description of driver behavior) would be of great use. 155 156This is a research-heavy project. 157 158### Requirements 159* Driver knowledge: Somebody working on this should be familiar with 160 how hardware works (eg. MMIO based register access, index/data port 161 accesses) and how to read data sheets. 162* Machine Learning: ML techniques may be useful to find structure in traces. 163 164### Mentors 165* Ron Minnich <[email protected]> 166 167## Libpayload based memtest payload 168[Memtest86+](https://www.memtest.org/) has some limitations: first and 169foremost it only works on x86, while it can print to serial console the 170GUI only works in legacy VGA mode. 171 172This project would involve porting the memtest suite to libpayload and 173build a payload around it. 174 175### Requirements 176* coreboot knowledge: Should know how to build coreboot images and 177 include payloads. 178* other knowledge: Knowledge on how dram works is a plus. 179* hardware requirements: Initial work can happen on qemu targets, 180 being able to test on coreboot supported hardware is a plus. 181 182### Mentors 183* TODO 184 185## Fix POST code handling 186coreboot supports writing POST codes to I/O port 80. 187There are various Kconfigs that deal with POST codes, which don't have 188effect on most platforms. 189The code to send POST codes is scattered in C and Assembly, some use 190functions, some use macros and others simply use the `outb` instruction. 191The POST codes are duplicated between stages and aren't documented properly. 192 193 194Tasks: 195* Guard Kconfigs with a *depends on* to only show on supported platforms 196* Remove duplicated Kconfigs 197* Replace `outb(0x80, ...)` with calls to `post_code(...)` 198* Update Documentation/POSTCODES 199* Use defines from console/post_codes.h where possible 200* Drop duplicated POST codes 201* Make use of all possible 255 values 202 203### Requirements 204* knowledge in the coreboot build system and the concept of stages 205* other knowledge: Little experience with C and x86 Assembly 206* hardware requirements: Nothing special 207 208### Mentors 209* Patrick Rudolph <[email protected]> 210* Christian Walter <[email protected]> 211 212## Board status replacement 213The [Board status page](https://coreboot.org/status/board-status.html) allows 214to see last working commit of a board. The page is generated by a cron job 215that runs on a huge git repository. 216 217Build an open source replacement written in Golang using existing tools 218and libraries, consisting of a backend, a frontend and client side 219scripts. The backend should connect to an SQL database with can be 220controlled using a RESTful API. The RESTful API should have basic authentication 221for management tasks and new board status uploads. 222 223At least one older test result should be kept in the database. 224 225The frontend should use established UI libraries or frameworks (for example 226Angular) to display the current board status, that is if it's working or not 227and some details provided with the last test. If a board isn't working the last 228working commit (if any) should be shown in addition to the broken one. 229 230Provide a script/tool that allows to: 2311. Push mainboard details from coreboot master CI 2322. Push mainboard test results from authenticated users containing 233 * working 234 * commit hash 235 * bootlog (if any) 236 * dmesg (if it's booting) 237 * timestamps (if it's booting) 238 * coreboot config 239 240### Requirements 241* coreboot knowledge: Non-technical, needed to perform requirements analysis 242* software knowledge: Golang, SQL for the backend, JS for the frontend 243 244### Mentors 245* Patrick Rudolph <[email protected]> 246* Christian Walter <[email protected]> 247