Revision as of 14:45, 5 March 2012

The flashrom project participates in GSoC under the patronage of coreboot's GSoC administration. Depending on the number and quality of applications (for both projects) and available mentors, there will be usually one or two slots for flashrom projects. Most of the information on their site is also valid for flashrom students, please read them.

If you want to apply, it is probably a good idea to subscribe to our mailing list look at our page with easy projects. You can show us that you are able to work with our codebase and/or read datasheets by solving some of the problems noted there. It is a good idea to talk to us before you start though (list items may be outdated or worked on by someone else already for example).

The list below is an idea collection. Individual list items are too simple to serve as complete GSoC task on their own, 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

libflashrom - Multiple UIs for flashrom

libflashrom is the name for the part of flashrom's code that forms its core and should eventually be independent from any user interface. This allows easy creation of user interfaces and integration to existing applications. The separation has not been completed yet:

code cleanup (e.g. removal of stray exit() calls and returning proper error codes instead)
API design
It is not enough to separate the code from the existing user interface. There must also be added some glue code so that the separate parts can be developed independently. For example there has to be a generic way to query programmer modules for their available options so that UI code can present them to the user without knowing about that specific programmer before. You can find a few thoughts at libflashrom.

It is probably a good idea to work in parallel on a user interface so that you become aware of problems and missing API bits. It is also an easy way to evaluate your work. If we see that your UI code can work independent of the libflashrom code in the way it should while providing the interaction possibilities we deem useful, you have been definitely successful.

Some obvious UI ides are:

flashrom TUI (text mode user interface) (for command line and flashrom-as-payload)
flashrom GUI (graphics mode user interface) (should be cross-platform, has been tried a few times and may be based on those attempts)

Recovery of dead boards and onboard flash updates

flashrom as payload
flashrom remote flashing for coreboot panic room mode
flashrom remote flashing with modified SerialICE

SPI bitbanging hardware support

flashrom support for Nvidia SPI chipset hardware (DONE)
flashrom support for RayeR SPIPGM hardware (DONE)
flashrom support for Paraflasher hardware
flashrom support for Willem hardware (unfinished patch exists)
flashrom support for some-yet-uninvented cheap universal LPC/FWH/SPI flasher hardware (e.g. Raspberry Pi, patch exists)
flashrom support for bitbanging LPC/FWH (code exists, Uwe Hermann needs to post it somewhere)
flashrom support for bitbanging Parallel

Generic flashrom infrastructure improvements

Automatic recovery in case something goes wrong
Partial reflashing
Bytewise flashing (similar to the point above)

Locking and Unlocking

Many chips support some kind of write protection. Currently flashrom just tries to disable it if needed to be able to write freely. Google's flashrom branch has some further support, which was not accepted upstream. Your task would be to design and implement acceptable data structures, APIs and user interfaces to make a generic approach to lock and unlock of flash regions possible.

Laptop support - Support for ECs (Embedded Controllers)

This one is really HARD. If you're lucky and if you have datasheets, you can add support for a single laptop 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 embedded controller which won't cause you to give up in frustration. Still, it might be beneficial if you're willing to solder (to recover from a bricked board).

Support more chips - Implement (obscure and) unsupported features - Try to make flashrom write EEPROMs

Most unsupported chips need some architectural work in flashrom's core because they behave substantially different to most other chips. The same applies to EEPROMs. Some yet unsupported features like OTP, locking or GPIO control may have been seen too obscure and not in the scope of flashrom. It might be fun to work on them and evaluate the resulting changes to flashrom's core. The main objective here is not to produce mergeable code for upstream, but to show what changes to the existing code would have to be done. If those are sustainable without breaking anything and do not bloat flashrom too much, integrating the code is of course a subgoal.

@@ Line 1: / Line 1: @@
-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.
+The flashrom project participates in GSoC under the patronage of [http://coreboot.org/GSoC coreboot's GSoC administration]. Depending on the number and quality of applications (for both projects) and available mentors, there will be usually one or two slots for flashrom projects. Most of the information on their site is also valid for flashrom students, please read them.
-= Ideas =
+If you want to apply, it is probably a good idea to subscribe to our [[Mailinglist|mailing list]] look at our page with [[easy projects]]. You can show us that you are able to work with our codebase and/or read datasheets by solving some of the problems noted there. It is a good idea to talk to us before you start though (list items may be outdated or worked on by someone else already for example).
-== Support more chips ==
+The list below is an idea collection. Individual list items are too simple to serve as complete GSoC task on their own, but they are grouped to reasonable tasks. If you're interested, please talk to us on the [[Mailinglist|flashrom mailing list]] and/or on IRC irc://irc.freenode.net/#flashrom
-We could come up with a list of unsupported (or partially supported) chips and ask the student(s) to implement support.
+= libflashrom - Multiple UIs for flashrom =
+libflashrom is the name for the part of flashrom's code that forms its core and should eventually be independent from any user interface. This allows easy creation of user interfaces and integration to existing applications. The separation has not been completed yet:
+* code cleanup (e.g. removal of stray exit() calls and returning proper error codes instead)
+* API design
+*: It is not enough to separate the code from the existing user interface. There must also be added some glue code so that the separate parts can be developed independently. For example there has to be a generic way to query programmer modules for their available options so that UI code can present them to the user without knowing about that specific programmer before. You can find a few thoughts at [[libflashrom]].
-== Add locking/unlocking functions for all chips ==
+It is probably a good idea to work in parallel on a user interface so that you become aware of problems and missing API bits. It is also an easy way to evaluate your work. If we see that your UI code can work independent of the libflashrom code in the way it should while providing the interaction possibilities we deem useful, you have been definitely successful.
-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.
+Some obvious UI ides are:
+* flashrom TUI (text mode user interface) (for command line and flashrom-as-payload)
+* flashrom GUI (graphics mode user interface) (should be cross-platform, has been tried a few times and may be based on those attempts)
-== Add support for ECs (Embedded Controllers) ==
+= Recovery of dead boards and onboard flash updates =
+* flashrom as payload
+* flashrom remote flashing for coreboot panic room mode
+* flashrom remote flashing with modified SerialICE
-Hard task, may be depending on availability of hardware and ability to recover in case something goes wrong.
+= SPI bitbanging hardware support =
+* flashrom support for Nvidia SPI chipset hardware (DONE)
+* flashrom support for RayeR SPIPGM hardware (DONE)
+* flashrom support for [[Paraflasher]] hardware
+* flashrom support for Willem hardware (unfinished patch exists)
+* flashrom support for some-yet-uninvented cheap universal LPC/FWH/SPI flasher hardware (e.g. Raspberry Pi, patch exists)
+* flashrom support for bitbanging LPC/FWH (code exists, Uwe Hermann needs to post it somewhere)
+* flashrom support for bitbanging Parallel
-== Add support for various flash programmers out there (Willem etc.) ==
+= Generic flashrom infrastructure improvements =
+* Automatic recovery in case something goes wrong
+* Partial reflashing
+* Bytewise flashing (similar to the point above)
-Will probably require a sizable amount of reverse engineering.
+= Locking and Unlocking =
-= Requirements =
+Many chips support some kind of write protection. Currently flashrom just tries to disable it if needed to be able to write freely. [http://git.chromium.org/gitweb/?p=chromiumos/third_party/flashrom.git;a=summary Google's flashrom branch] has some further support, which was not accepted upstream. Your task would be to design and implement acceptable data structures, APIs and user interfaces to make a generic approach to lock and unlock of flash regions possible.
-This section is addressed to anyone interested working on flashrom.
+= Laptop support - Support for ECs (Embedded Controllers) =
-== Requirements for acceptance ==
+This one is really HARD. If you're lucky and if you have datasheets, you can add support for a single laptop 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 embedded controller which won't cause you to give up in frustration. Still, it might be beneficial if you're willing to solder (to recover from a bricked board).
-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.
+= Support more chips - Implement (obscure and) unsupported features - Try to make flashrom write EEPROMs =
-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.
+Most unsupported chips need some architectural work in flashrom's core because they behave substantially different to most other chips. The same applies to EEPROMs. Some yet unsupported features like OTP, locking or GPIO control may have been seen too obscure and not in the scope of flashrom. It might be fun to work on them and evaluate the resulting changes to flashrom's core. The main objective here is not to produce mergeable code for upstream, but to show what changes to the existing code would have to be done. If those are sustainable without breaking anything and do not bloat flashrom too much, integrating the code is of course a subgoal.
-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.

GSoC: Difference between revisions