[http://www.marvell.com/products/processors/embedded/kirkwood/ Marvell Processors] These ARM SOC's with PCIe will become popular in netbooks later this year. These systems can take advantage of coreboot's strength in properly configuring PCI devices, fast boot time and payload support.

[http://www.marvell.com/products/processors/embedded/kirkwood/ Marvell Processors] These ARM SOC's with PCIe will become popular in netbooks later this year. These systems can take advantage of coreboot's strength in properly configuring PCI devices, fast boot time and payload support.

+

+

Note that coreboot has in the past supported three different CPUs (x86, Alpha, PPC), so the structure is there for adding in a new processor family.

+

We will need to find the right platform to do the work, but I (Ron) can provide a board and JTAG debugger if needed.

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

Some Caveats

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.

Note that "regular basis" in the last item does _not_ mean "3 days before evaluation deadlines". You should be "around" all the time (reporting your feedback, sending in partial successes).
We don't expect our students to be experts in our problem domain, but we don't want you to fail because some basic misunderstanding was in your way of completing the task.

Time Frame

DEADLINE FOR STUDENT APPLICATIONS: Students who are interested in working on a coreboot-related GSoC project must apply between March 29, 2010 and April 9, 2010! If you want to apply, please get in contact with us right away, not just when you send your application!

Student requirements

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.

Contact

If you are interested in becoming a GSoC student, please contact Stefan Reinauer.

There is also an IRC channel on irc.freenode.net: #coreboot

Possible ideas

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.

Links

Mentors

TianoCore on coreboot

Tiano Core is Intel's EFI implementation. Unlike coreboot, it is not a firmware, but rather a bootloader. In 2008 there was an initial port of TianoCore to run on coreboot, but there are many things left to do.

Improve Tiano Core / EDK2 running as a coreboot payload

Implement a coreboot framebuffer driver for Tiano Core

Implement a coreboot flash filesystem (CBFS) driver for Tiano Core

Integrate and automate check out and build process of Tiano Core

Create CorebootPkg using OVMF instead of DUET.

Provide a script that creates working binaries for the EDK shell, EDK apps, FAT driver(?), ...

The final work must compile on a cross gcc, and coreboot's crossgcc script has to be adapted so it can build this compiler (if the default script is not capable of doing so yet)

This project requires no hardware skills, but especially in case of TianoCore will require knowledge of Microsoft compilers as well as the GNU tool chain.

Links

Mentors

coreboot port to Marvell ARM SOC's with PCIe

Marvell Processors These ARM SOC's with PCIe will become popular in netbooks later this year. These systems can take advantage of coreboot's strength in properly configuring PCI devices, fast boot time and payload support.

Note that coreboot has in the past supported three different CPUs (x86, Alpha, PPC), so the structure is there for adding in a new processor family.
We will need to find the right platform to do the work, but I (Ron) can provide a board and JTAG debugger if needed.

Mentors

coreboot mass-porting to AMD 780 series mainboards

Mentors

coreboot panic room

Create a safe boot solution for coreboot to easily and cheaply recover the system in case of a panic().

I would like to base this solution around SerialICE. The basic idea is that the system always boots to SerialICE. There is a test in CMOS for 'last boot worked' and, if this is set, SerialICE finds a coreboot in cbfs and runs it. If 'last boot worked' is not set, or the user hits some magic keyboard sequence, SerialICE takes control.

SerialICE needs to be extended (not much) to make this work. Having this capability would make it possible for me to get some very hard ports working that are just not possible today. At the same time, there are lots of hardware boards to test this idea on, so it should be easy to get it working.

Links

Mentors

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)

Links

?

Mentors

?

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. We will not accept code that has been taken from other (GPL) projects. If you are taking this project you have to be willing and capable of writing your own hardware drivers.

Links

?

Mentors

Stefan Reinauer

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.

Links

?

Mentors

?

Refactor AMD code

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.

Links

?

Mentors

Payload infrastructure

Incorporate payload building into the coreboot build. kconfig options could be added for supported payloads, those payload could be updated to build with kconfig as well. Payloads that build with libpayload need would need default configs. Payloads should also be built with the crossgcc tools. This is related to the libpayload and board config infrastructure above. ---MJones

Links

?

Mentors

?

flashrom

Note: The list below is an idea collection. Individual list items are simple enough to serve only as partial GSoC task, but they are grouped to reasonable tasks. If you're interested, please talk to us on the flashrom mailing list and/or on IRC irc://irc.freenode.net/#flashrom

Generic flashrom infrastructure improvements

flashrom support for automatic recovery in case something goes wrong

flashrom support for partial reflashing

flashrom support for bytewise flashing (similar to the point above)

Laptop support

This one is really HARD. If you're lucky and if you have datasheets, you can do it in maybe 1 month. If you're unlucky, it can take the whole GSoC or more. If there is interest, we'll try to find an embeddec controller which won't cause you to give up in frustration. Still, it might be beneficial if you're willing to solder.

flashrom support for embedded controllers (ECs) in laptops

Links

Mentors

?

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 above, and don't hesitate to suggest whatever you have in mind.