GCI2010

We hope to participate in Google Code-in 2010 (basically Google Summer of code for 13-18 year old students)

Please note that the task list is not finished, and we will add more tasks once we know how long individual tasks are supposed to take.

See http://www.coreboot.org/GCI2010 for a small list of coreboot related tasks.

Code: Tasks related to writing or refactoring code

Add all chips listed in flashchips.h to flashchips.c

This means you have to find the datasheet for each chip (ask us, we have a huge datasheet archive), compare it with some already supported chip, then add struct flashchip for the new chip to flashchips.c.

Estimated time depends on your datasheet reading skills, and is between 5 minutes and 2 hours per chip.

Add all chips supported by the Linux MTD layer to flashchips.c

Given that the Linux MTD code and flashrom are GPLv2, copy-paste is OK, but keep in mind that the data structures differ and that the Linux MTD chip definitions have less info about erase methods than flashrom. OTOH, some info in Linux MTD chip defintions is not (yet) present in flashrom, so you may have to carry some useful info forward as comments. You will have to look up the datasheet for each chip as with the task above.

Compare Ezoflash support list with flashrom support list, add missing chips to flashchips.c

Find the datasheets, etc. For more info, see the tasks above.

Compare Willem/... support list with flashrom support list, add missing chips to flashchips.c

See above.

Finish the flashrom Qt GUI

Sean Nelson wrote a Qt GUI for the flashrom executable, but it needs to be finished and extended to take advantage of all flashrom features.

Convert the flashrom Qt GUI to use libflashrom

For some applications libflashrom is preferable to a flashrom executable. Investigate which variant makes more sense.

Create a Windows GUI for flashrom

Check if the existing Qt GUI can be reused or if flashrom needs a totally separate native Windows GUI.

Add comments before each function

Document the parameters taken by the function, the return value and what the function does.

Finish libflashrom

This task is REALLY hard. Help us find a good and maintainable library interface for flashrom which is still usable 2 years from now. It is strongly suggested that you have some experience with library programming and/or creating stable interfaces.

Documentation: Tasks related to creating/editing documents

Collect tutorials on the web, move them to flashrom.org

Find tutorials and useful blog posts about flashrom, then ask the authors if we may reproduce/edit the content on flashrom.org. All documentation should be in a central place.

Write a tutorial on how to use flashom

We have an exhaustive man page, but many people can't read man pages. They need some handholding and simple examples they can copy-and-paste without thinking. Help them use flashrom.

Document the requirements for sending patches

This document should already be on the wiki. Locate it, check the style and readability, and extend it.

Document how flashrom is structured internally

The usual call paths are quite important, and especially with libflashrom we need to tell people how to use the code.

Outreach: Tasks related to community management and outreach/marketing

Talk at LUG meetings about flashrom

Not sure if this is an appropriate task.

Design/create promotional material

We need flyers explaining what flashrom does, why it is great, etc.

Ask fellow students/buddies to test flashrom

Read-only tests, not on laptops/notebooks. Make sure to collect the output from

flashrom -V
lspci -nnvvvxxx
superiotool -deV

We try to build a database of which mainboards support flashrom and which need work to detect the chip and/or to write to the chip.

Quality Assurance: Tasks related to testing and ensuring code is of high quality

Test compilation of flashrom with all compilers you can find

This includes non-GCC compilers like MSVC, LLVM, ICC. Test multiple versions of each. Report problems, and send fixes if you can.

Review a few pending patches

The following aspects are important (most important ones first):

• Correctness. Check for obvious breakage.
• More correctness. Check for unlikely corner cases (strange flash chip sizes, error handling, ...). Bonus points if the code in question uses non-trivial math (overflow, address calculations, ...) and you document+check each corner case. Feel free to include mathematical proofs if you're inclined.
• Design. The code should fit the flashrom design and structure.
• Coding style. Check for typedef abuse, too deep nesting, unreadable code.
• Coding cosmetics. Check for whitespace issues, spelling, grammar.

If you don't feel confident enough to handle all aspects of a review, please review anyway and indicate in your review which points were checked by you.

Run flashrom with dummy programmer and chip emulator

Check if it works, and invent/extend a torture test script. Investigate whether valgrind/... can be used in such tests.

Research: Tasks related to studying a problem and recommending solutions

Additional data in flashchips.c

Which flash chip data should be stored in flashchips.c in addition to the data that's already there?

• Voltage
• Form factor
• Pinout
• Timing (individual commands, low-level timing on the electric bus, frequency range for chip communication)
• Alternative programming methods

Representation of multiple bus masters at the same time

Some mainboards have multiple SPI masters and it is not obvious which SPI master hosts the flash chip. Find a way to handle multiple SPI masters at the same time. Generalize the infrastructure for other buses.

Representation of multiple flash chips

The current way to handle multiple chips is a really horrible hack.

Design the libflashrom interface

Which functions should be exported? Do we need helper functions to make usage easy? Can we offer an interface which is future-proof?

Handling layout files with implicit commands

Figure out how to deal with layouts where contents are marked as untouchable/unreadable etc.

Training: Tasks related to helping others learn more

Document flash recovery advice on IRC

People often come to #flashrom because flashing failed. Watch how we help them, then write up a tutorial about recovery. Make sure to mention differences between flashrom versions (versions before 0.9.1 should be avoided, 0.9.2 is rather OK, 0.9.3 is recommended for now, and 0.9.4 will be the first version to make recovery easy).

Document reverse engineering board enables

We already have docs for that, but not in a central place. Find all docs, and create a short writeup which explains where to look.

Document how to create an entry in flashchip.c

It's easy, but you have to know where to look in the flash chip datasheets. Provide examples where to look and what various phrases in the datasheet mean. Explain pitfalls like "LPC firmware flash" which means "FWH flash" instead of "LPC flash". Some documentation is already in the wiki (Random notes).

Translation: Tasks related to localization

Provide translations of code

flashrom messages can be translated, but deciding which messages to translate is hard. Identify a suitable subset of messages, make sure developers agree, then find out how to best integrate translated messages in flashrom. Hint: cli_output.c can be used for this.

Provide translations of Howtos, tutorials, the man page

Translate those docs, and make sure to clearly state which version of the original document they are based on.

User Interface: Tasks related to user experience research or user interface design and interaction

GUI

Do we want one? Which functions should be offered by the GUI? Will a GUI impact reliability of the code (timing etc)? Does a GUI mean we get more stupid users unwilling to read the docs? How can a GUI handle errors in flashrom?

Command line interface

Are the messages too verbose or too short? Do we need additional options? Do we need a new interactive commandline frontend?