Difference between revisions of "Project Ideas"
Jump to navigation
Jump to search
MartinRoth (talk | contribs) |
MartinRoth (talk | contribs) |
||
| Line 6: | Line 6: | ||
= coreboot Projects = | = coreboot Projects = | ||
== coreboot mainboard test suite == | == coreboot mainboard test suite == | ||
| Line 42: | Line 23: | ||
* Rebooting with various kernel parameters to test different items | * Rebooting with various kernel parameters to test different items | ||
* Working with the community & coreboot vendors to develop additional tests | * Working with the community & coreboot vendors to develop additional tests | ||
'''Links''' | '''Links''' | ||
| Line 64: | Line 40: | ||
'''Mentors''' | '''Mentors''' | ||
<br/><br/> | <br/>[https://www.coreboot.org/User:MartinRoth Martin Roth]<br/> | ||
== coreboot mainboard test suite 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]]. | |||
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. | 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. | 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 | 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://www.flashrom.org/Supported_hardware | |||
* [[Supported Motherboards]] | * [[Supported Motherboards]] | ||
* [https://review.coreboot.org/gitweb?p=board-status.git;a=tree Board status git repo] | * [https://review.coreboot.org/gitweb?p=board-status.git;a=tree Board status git repo] | ||
| Line 92: | Line 70: | ||
== coreboot on the open source Berkeley RISC V processor == | == coreboot on the open source Berkeley RISC V processor == | ||
We've got a preliminary port of coreboot to the Berkeley RISC V. Much work remains. | We've got a preliminary port of coreboot to the Berkeley RISC V. Much work remains to get the port running on real hardware. We have a board with an FPGA version of the chip, which can be provided to the student. | ||
This work would be to make the build process bullet proof and then show that we can boot linux on RISCV under coreboot. | This work would be to make the build process bullet proof and then show that we can boot linux on RISCV under coreboot. Ron has talked to the RISCV folks about this and promises that we'll have really good support. They've been very helpful already. | ||
'''Links''' | '''Links''' | ||
| Line 109: | Line 87: | ||
<br/>Ron Minnich<br/> | <br/>Ron Minnich<br/> | ||
== Infrastructure for automatic code checking == | == Infrastructure for automatic code checking == | ||
| Line 135: | Line 94: | ||
* 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''' | ||
| Line 152: | Line 113: | ||
'''Mentors''' | '''Mentors''' | ||
<br/> | <br/>[https://www.coreboot.org/User:MartinRoth Martin Roth]<br/> | ||
== coreboot ARM SoC's mainboard port== | == coreboot ARM SoC's mainboard port == | ||
While the links below are still relevant, there's now a coreboot port for ARM Exynos5. It was contributed by Google and the chip is used in a Chromebook. The port isn't quite done, but some of the heavy lifting is done, so ports to other SoCs should be easier. | While the links below are still relevant, there's now a coreboot port for ARM Exynos5. It was contributed by Google and the chip is used in a Chromebook. The port isn't quite done, but some of the heavy lifting is done, so ports to other SoCs should be easier. | ||
| Line 221: | Line 167: | ||
'''Skill Level''' | '''Skill Level''' | ||
* coreboot and firmware: competent to expert | * coreboot and firmware: competent to expert | ||
* ACPI and power | * ACPI and power management: novice to competent | ||
'''Requirements''' | '''Requirements''' | ||
| Line 307: | Line 253: | ||
<br/><br/> | <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. | |||
'''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''' | '''Links''' | ||
* | * [[User_talk:MrNuke/Block_Device_API | Initial proposal]] | ||
* [[Board:cubietech/cubieboard | Cubieboard page]] | |||
'''Skill Level''' | '''Skill Level''' | ||
* coreboot: competent | * coreboot and ARM firmware: competent | ||
'''Requirements''' | '''Requirements''' | ||
* | * An ARM board with low-end SoC (for example, Cubieboard, with Allwinner A10) | ||
'''Mentors''' | '''Mentors''' | ||
<br/><br/> | <br/><br/> | ||
== Native graphics init == | == Native graphics init == | ||
| Line 412: | Line 342: | ||
<br/><br/> | <br/><br/> | ||
== proper configuration support in upstream (devtree -> kconfig -> runtime values) == | == proper configuration support in upstream (devtree -> kconfig -> runtime values) == | ||
| Line 477: | Line 393: | ||
'''Mentors''' | '''Mentors''' | ||
<br/>adurbin<br/> | <br/>adurbin<br/> | ||
== 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''' | |||
<br/><br/> | |||
== Provide toolchain binaries == | == Provide toolchain binaries == | ||