GSoC: Difference between revisions

From flashrom
Jump to navigation Jump to search
No edit summary
(Link Project Ideas doc and Project Proposal Template doc)
(27 intermediate revisions by 5 users not shown)
Line 1: Line 1:
The [[flashrom]] project will hopefully participate in GSoC 2013 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 the coreboot site is also valid for flashrom students, please read them.
Flashrom plans to apply for participation in [https://developers.google.com/open-source/gsoc/timeline GSoC 2022]. We will update this page with more details in February 2022 once the registration is confirmed.


If you want to apply, it is probably a good idea to subscribe to our [[Mailinglist|mailing list]] and take a 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/partially solved by someone else already for example).
We are gathering project ideas in [https://docs.google.com/document/d/1AxMobB2v8Dv2uUwZPZ_vCmmONYDJuliHcnjfWOs4qIs/edit?usp=sharing this doc].


The list below is an idea collection and not set in stone. If you're interested, please talk to us on the [[Mailinglist|flashrom mailing list]] and/or on [[IRC]] irc://irc.freenode.net/#flashrom and we can make them more concrete together depending on your skills and interests.
If you are interested to propose your own idea for GSoC project, have a look at [https://docs.google.com/document/d/1DSg1FykuI7Z3JDY1Qtk8C6JjvpsYISMEwyV4932jtBI/edit?usp=sharing this template].
 
= 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. There exists a patch set implementing this idea by [http://patchwork.coreboot.org/project/flashrom/list/?submitter=3002 Nico Huber] already, but it was not reviewed yet. It would certainly be a good starting point for anyone looking into this project.
 
In general implementing this idea requires the following steps:
* code cleanup (e.g. removal of stray exit() calls and returning proper error codes instead)
* API design and implementation
*: It is not enough to just 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. Naturally the existing command line interface should continue to work (but be separated). This 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(ed) useful, you have been definitely successful.
 
Some obvious UI ideas 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)
 
There have been a number of attempts to create a flashrom GUI, but [[Qflashrom]] is probably the only one of interest for you.
 
= Design and implementation of a native USB flashing protocol =
All existing free USB-based flash programmers have a very naive interface.
The SPI programmers usually act as a simple USB to SPI bridge, mostly tunneling the plain SPI traffic via a USB communications device class (CDC) aka. RS-232 tunnel.
Since USB communication has rather long round trip times this has some performance disadvantages.
It would be much more elegant to tell the programmer what to do more abstractedly instead of sending it the complete flash protocol communication contents which just needs to be forwarded to the chip.
This requires a lot of knowledge at the external programmer though because much of what flashrom does needs to be done by its firmware.
Adding an instruction set interpreted by the programmer might help to keep the complexity within sane bounds.
You can find some preliminary design ideas about such a protocol by Peter Stuge in his [http://git.stuge.se/?p=qiprog.git;a=blob;f=doc/qiprog_protocol.txt git repo].
A programmer based on some embedded platform (e.g. an ARM cortex-m board) should be built utilizing the protocol to evaluate the performance and implementation effort.
 
= ROM image parsing and preparation =
flashrom does not analyze the images fed to it.
Therefor it is not able to detect if the image is correct for the target computer neither to automatically derive [[Board Enable|Board Enables]], detect write protected regions or bootblocks etc.
There exist a number of tools already to dissect, unpack and analyze images.
Some of them reside in the (aptly named) [http://www.coreboot.org/Bios_extract '''Bios extract'''] [http://review.coreboot.org/gitweb?p=bios_extract.git repository].
Another pair of tools are [https://github.com/NikolajSchlej/FD44Editor '''FD44Editor'''] and [https://github.com/NikolajSchlej/FD44Copier '''FD44Copier'''] which can show, edit, and extract lots of information of UEFI images of Intel-based ASUS boards and prepare it to be flashed back.  The [http://hardforum.com/showthread.php?t=1726429 companion thread] tells how to use them and what they do more in-depth.
Then there is '''ich_descriptor_tool''' residing in the flashrom repository, which is able to parse the descriptor region found on most Intel platforms and there is an automatic board enable finder authored by Roxfan which is yet unreleased. If the license permits it other code can of course be used too.
 
The goal of this project is to unify (some of) the tools above, adding further functionality and creating a library that can be used to prepare images before they are fed to flashrom and possibly by flashrom itself.
 
= Recovery of dead boards and onboard flash updates =
* flashrom as payload
* flashrom as UEFI application
* flashrom remote flashing for coreboot panic room mode
* flashrom remote flashing with modified SerialICE
 
= Generic flashrom infrastructure improvements =
Below is a list of smaller projects to improve/refactor some core features of flashrom.
A number of other things of various difficulty can be done too/instead.
You should probably have some experience with the code base already to work on these effectively.
 
* Automatic recovery in case something goes wrong
* Partial reflashing
* Bytewise flashing (similar to the point above)
* Support for multiple read and write functions per chip
* Sanitize (SPI) probing
 
= 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. [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.
 
= 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.

Revision as of 08:27, 13 January 2022

Flashrom plans to apply for participation in GSoC 2022. We will update this page with more details in February 2022 once the registration is confirmed.

We are gathering project ideas in this doc.

If you are interested to propose your own idea for GSoC project, have a look at this template.