Difference between revisions of "Project Ideas"

From coreboot
Jump to navigation Jump to search
Line 6: Line 6:


= coreboot Projects =
= coreboot Projects =
== 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'''
* [[User_talk:MrNuke/Block_Device_API | Initial proposal]]
* [[Board:cubietech/cubieboard | Cubieboard page]]
'''Skill Level'''
* coreboot and ARM firmware: competent
'''Requirements'''
* An ARM board with low-end SoC (for example, Cubieboard, with Allwinner A10)
'''Mentors'''
<br/><br/>


== 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
Possibilities for reporting:
* Upload to the coreboot board_status repo
* Reporting on the wiki
* Creating a database to hold the data and some sort of front-end to view the data


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


We have an increasing interest in automated tests on real hardware, with reporting. Build something more scalable than the current system of [https://review.coreboot.org/gitweb?p=board-status.git;a=tree git repository] + [[Supported Motherboards]] (see the timeline below the table to see the problem unfold).
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 ties directly to the test suite itself, which will need its reporting interface updated to match the back-end changes.
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. There are three chips coming out end of 2015 and it would be great to be ready for them.  
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. If the student gets far enough we'll supply them with either an FGPA board or real hardware to take it even further. I've talked to the RISCV folks about this and we'll have really good support. They've been very helpful already.
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/>


== coreboot mainboard test result 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. 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.
'''Links'''
* http://openbenchmarking.org/
* http://www.coreboot.org/Supported_Motherboards
* http://www.flashrom.org/Supported_hardware
'''Skill Level'''
* coreboot and firmware: novice
* wiki and web application development: competent
'''Requirements'''
* LAMP setup
'''Mentors'''
<br/><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/>
<br/>[https://www.coreboot.org/User:MartinRoth Martin Roth]<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.
 
'''Skill Level'''
* coreboot and firmware: novice to competent
 
 
'''Requirements'''
* mainboard to port
* flash recovery mechanism
 
'''Mentors'''
<br/><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 managment: novice to competent
* ACPI and power management: novice to competent


'''Requirements'''
'''Requirements'''
Line 307: Line 253:
<br/><br/>
<br/><br/>


== Refactor AMD code ==
== Infrastructure for accessing block devices  ==


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


Alternatively, figure out a way how to build them in parallel and have coreboot select the right one on runtime.
'''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'''
* src/cpu/amd/ inside the coreboot source tree
* [[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'''
* AMD coreboot mainboard and required silicon
* An ARM board with low-end SoC (for example, Cubieboard, with Allwinner A10)
* flash recovery mechanism


'''Mentors'''
'''Mentors'''
<br/><br/>
<br/><br/>


== AMD VSA ==
Get the existing source code of AMD's VSA compiled and working with an open source toolchain. Integrate it into the current build system.
'''Links'''
* [[OpenVSA]], [[AMD Geode Porting Guide]]
'''Skill Level'''
* coreboot: competent
'''Requirements'''
* coreboot mainboard that uses VSA
* flash recovery mechanism
'''Mentors'''
<br/><br/>


== Native graphics init ==
== Native graphics init ==
Line 412: Line 342:
<br/><br/>
<br/><br/>


== proper fmap support in upstream ==
fmap, short for flash map is a partitioning format used on Chromebooks and other devices. Standardizing on it could simplify our CBFS handling a lot.
'''Skill Level'''
* coreboot: novice
* Systems programming
'''Requirements'''
* coreboot mainboard
* flash recovery mechanism
'''Mentors'''
<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 ==

Revision as of 16:42, 12 February 2016