GCI2010: Difference between revisions
Hailfinger (talk | contribs) |
Hailfinger (talk | contribs) m (→Additional data in flashchips.c: layout) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
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. | 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= | =Code: Tasks related to writing or refactoring code= | ||
| Line 47: | Line 49: | ||
==Document how flashrom is structured internally== | ==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. | 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= | =Outreach: Tasks related to community management and outreach/marketing= | ||
| Line 76: | Line 72: | ||
==Review a few pending patches== | ==Review a few pending patches== | ||
The following aspects are important (most important ones first): | 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. | 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. | ||
| Line 91: | Line 87: | ||
==Additional data in flashchips.c== | ==Additional data in flashchips.c== | ||
Which flash chip data should be stored in flashchips.c in addition to the data that's already there? | 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== | ==Representation of multiple bus masters at the same time== | ||
| Line 121: | Line 117: | ||
=Translation: Tasks related to localization= | =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= | =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? | |||
Latest revision as of 01:41, 1 November 2010
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.
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.
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.
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.
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.
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.
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).
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.
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?