GSoC

We plan to get one (or maybe more) slots at GSoC 2010. This may be independent of coreboot to avoid resource conflicts. Not sure yet.

Ideas

Support more chips

We could come up with a list of unsupported (or partially supported) chips and ask the student(s) to implement support.

Add locking/unlocking functions for all chips

Even the supported chips in our list often lack complete locking code. May be combined with the "support more chips" task to keep the student busy.

Add support for ECs (Embedded Controllers)

Hard task, may be depending on availability of hardware and ability to recover in case something goes wrong.

Add support for various flash programmers out there (Willem etc.)

Will probably require a sizable amount of reverse engineering.

Requirements

This section is addressed to anyone interested working on flashrom.

Requirements for acceptance

You will have to demonstrate their ability to work with the codebase before being accepted. That means you have to solve a task that corresponds with what you picked as project (i.e. if you want to do locking, you have to add locking support to one or two chips). Asking for help on IRC or the mailing list is OK, asking for sample code is not. We have enough sample code in the flashrom tree and that should be sufficient for you. If you are unable to figure out the task by yourself, it is very likely that you will fail anyway, and we'd rather give the slot to someone who can do it without excessive babysitting.

We want to know if you already participated in GSoC the year before, if that participation was successful and where to find the resulting code.

You have to know C and should be able to read datasheets (we can help with datasheet reading because it is hard).

Requirements for a passing grade

Weekly progress reports with code (exception: early phases of EC and external programmers because they will require a whole lot of reading and/or tracing, but in that case we require traces or writeups). It is OK if you need the first two weeks to analyze the codebase in case the task requires a partial rewrite of some code (but in that case we want writeups if no code can be supplied).

For the flash chip tasks (new chips and/or locking) there has to be at least one patch in mergeable shape (review comments addressed, Signed-off-by in place, short changelog written) three weeks after the "coding start". For the EC and external programmer tasks, the deadline for code (may be incomplete or even a stub and not mergeable) is two weeks before midterm evaluation deadline.

You may create your own private source trees, but what counts is the submission of mergeable code to the main flashrom tree. Throwing code over the wall and leaving is not an option.

Patches need to be small (only one type of change) and self-contained for review. A megapatch with all changes accumulated is not OK. Exceptions: If you implement a new external programmer or EC driver, you can submit that new driver in one patch even if it is huge. If you change multiple flash chips at once to a new interface or add information to them, a huge patch is allowed as well.

You are expected to work with the community and rework your code if a reviewer points out bugs or design/style problems.

Support

We will help you if you have trouble with the codebase or with any datasheets. We can help you locate appropriate (cheap) hardware for your task and we know low-level programming well enough to help you debug totally strange issues you may encounter.

We do have a huge archive of datasheets, much more than what you can find with google. We have contacts at some flash vendors, chipset vendors and mainboard vendors, so in case there is a problem with their docs or their hardware, there is a good chance we can ask technicians there.

We have an IRC channel and a mailing list and you can ask any questions there.