The wiki is being retired!
Documentation is now handled by the same processes we use for code: Add something to the Documentation/ directory in the coreboot repo, and it will be rendered to https://doc.coreboot.org/. Contributions welcome!
- 1 Google Summer of Code 2010
- 2 Why work for coreboot
- 3 Summer of Code Application
- 4 Contact
- 5 Possible ideas
- 5.1 Infrastructure for automatic code checking
- 5.2 TianoCore on coreboot
- 5.3 coreboot port to AMD 800 series chipsets
- 5.4 coreboot mass-porting to AMD 780 series mainboards
- 5.5 coreboot panic room
- 5.6 coreboot cheap testing rig
- 5.7 coreboot GeodeLX port from v3 to v4
- 5.8 drivers for libpayload
- 5.9 Board config infrastructure
- 5.10 flashrom
- 5.11 Your own Project Ideas
- 6 Previous Summer of Code projects
Google Summer of Code 2010
This year, coreboot also tries to host some flashrom projects.
Make sure you check the Deadlines
Why work for coreboot
Why would you like to work for coreboot?
- coreboot offers you the opportunity to work with modern technology "right on the iron".
- Your application will be available to users worldwide and promoted along with all other coreboot projects.
- We are a very passionate team - so you will interact directly with the project initiators and project leaders.
- We have a large, helpful community. Over 100 experts in hardware and firmware lurk on our mailing list, many of them waiting to help you.
Summer of Code Application
Please complete the standard Google SoC 2010 application. Additionally, please provide information on the following:
- Who are you? What are you studying?
- Why are you the right person for this task?
- Do you have any other commitments that we should know about?
- List your C, Assembler and hardware experience.
- List your history with open source projects.
- What is your preferred method of contact? (Phone, email, Skype, etc)
Feel free to keep your application short. A 15 page essay is no better than a 2 page summary. If you wish to write 15 pages, you are of course welcome to do so, and we will gladly put your paper up on the web page. But it is not required for the application.
How to apply
The Drupal project has a great page on How to write an SOC application.
Please also read Google's Advice for Students.
- Google Summer-of-Code projects are a full (day-) time job. This means we expect roughly 30-40 hours per week on your project, during the three months of coding. Obviously we have flexibility, but if your schedule (exams, courses) does not give you this amount of spare time, then maybe you should not apply.
- Getting paid by Google requires that you meet certain milestones. First, you must be in good standing with the community before the official start of the program. We suggest you post some design emails to the mailing list, and get feedback on them, both before applying, and during the "community bonding period" between acceptance and official start. Also, you must have made progress and committed significant code before the mid-term point.
- We are thinking of requiring accepted students to have a blog, where you will write about your project on a regular basis. This is so that the community at large can be involved and help you. SoC is not a private contract between your mentor and you.
DEADLINE FOR STUDENT APPLICATIONS: Students who are interested in working on a coreboot-related GSoC project must apply between March 23, 2009 and April 3, 2009! If you want to apply, please get in contact with us right away!
We will only accept your proposal if you have demonstrated that you can work with our codebase. For that, you have to send a patch to the list which is acceptable. Just ask for simple tasks on the mailing list or on IRC.
If you are interested in becoming a GSoC student, please contact Stefan Reinauer.
There is also an IRC channel on irc.freenode.net: #coreboot
Infrastructure for automatic code checking
We already have a build bot that builds various configurations of coreboot. It would be nice to extend it 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.
- Work on code coverage support for coreboot code (dump data into ram, or via serial. Provide tools to fetch it). Analyse that data.
TianoCore on coreboot
Tiano Core is Intel's EFI implementation. Unlike coreboot, it is not a firmware, but rather a bootloader. Last year we started porting TianoCore to run on coreboot, but there are many things left to do. Improve Tiano Core running as a coreboot payloads, or change coreboot so it can load Tiano Core as a payloads.
This project requires no hardware skills, but especially in case of TianoCore might require knowledge of Windows compilers (VC2005?)
coreboot port to AMD 800 series chipsets
(probably too big of a task)
coreboot mass-porting to AMD 780 series mainboards
(if the code is available until then)
coreboot panic room
(maybe just reuse the SerialICE core, too small project for full GSoC)
coreboot cheap testing rig
create a cheap testing rig which works with the existing board test infrastructure
coreboot GeodeLX port from v3 to v4
significant parts of that are already done, so it's hard to fill a full GSoC with that. One thing could be "verify that everything is brought over", but that's nothing that can be reasonably proven (and it might also be too close to "documentation tasks", which are not allowed)
drivers for libpayload
IDE, AHCI, Bluetooth, Firewire, Smartcards, maybe filesystems. Work towards making FILO only a shell, which uses libpayload for the "real" work. Notice that libpayload code must be licensed BSD-style (so ports from FILO, SeaBIOS or Linux won't work). Pick a given set and tell us why it's enough work for the allocated time, but not too much for you. Also, which sources (if any) you want to draw from.
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.
Note: The list below is an idea collection. Many of the projects are simple enough to serve only as partial GSoC task
- flashrom text mode GUI
- flashrom graphics mode GUI (Sean Nelson has preliminary code)
- flashrom as payload
- flashrom under DOS
- flashrom remote flashing for coreboot panic room mode
- flashrom remote flashing with modified SerialICE
- flashrom support for Nvidia SPI chipset hardware
- flashrom support for Paraflasher hardware
- flashrom support for RayeR SPIPGM hardware
- flashrom support for Willem hardware
- flashrom support for some-yet-uninvented cheap universal LPC/FWH/SPI flasher hardware
- flashrom support for bitbanging LPC/FWH
- flashrom support for bitbanging Parallel
- flashrom support for partial reflashing
- flashrom support for automatic recovery in case something goes wrong
- flashrom support for embedded controllers (ECs) in laptops
Your own Project Ideas
We have come up with some ideas for cool Summer of Code projects here. 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 your application does not need to be based on any of the ideas listed below. The opposite: Maybe you have a great idea that we just didn't think of yet. Please let us know!
Feel free to contact us at the email address below, and don't hesitate to suggest whatever you have in mind.
Previous Summer of Code projects
We successfully participated in Google's Summer of Code in 2007, 2008 and 2009. See our list of previous GSoC projects.