GSoC: Difference between revisions

Latest revision as of 19:38, 28 February 2022

Information and Links

Flashrom is applying for participation in GSoC 2022 (also known as Google Summer of Code). We will update this page in March 2022 once the registration is confirmed.

You are very welcome to look at our list of project ideas in this doc.

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

How to contact us

If you are interested in becoming a GSoC student, please have a look at our Contact page.

If you need to contact someone directly, Anastasia Klimchuk (aklm), Felix Singer (flx) and Angel Pons (hell) are our GSoC Admins.

Why you should choose a Flashrom project for GSoC

Flashrom offers you the opportunity to work with modern hardware “right on the iron”.
Hardware is fun. And it’s complicated. You will learn that datasheets are just loose guidelines to the hardware and real insight is gained by systematic tinkering.
Flashrom is the only multi-platform open source solution for flash EEPROM reading/writing for lots of different devices: on-mainboard flash (for BIOS/EFI/coreboot), graphics/network card flash (for firmware), and dozens of specialized programmer devices. If you want to update your BIOS/EFI/coreboot or update some firmware from a running Linux/*BSD/... system, then flashrom is the only choice you have.
Flashrom does hardware access (like firmware/drivers), but completely in user space and without the hassles present in firmware or OS kernels. That way you can write complex hardware access with ease.
Flashrom has a worldwide developer and user base. Big companies like Google and individual users use and contribute to it.
We are a very passionate team – so you will interact directly with the project initiators and project leaders.
We have a friendly and helpful community. Flashrom has some extremely talented and helpful experts in all things flash active in the project, and many of our friends from the coreboot project participate in flashrom as well. They are ready to assist and mentor students participating in GSoC.

Contents of your application

Please have a look at our project proposal template here.

Contributor commitments & requirements

What does it mean to be a Flashrom GSoC contributor?

Google Summer of Code is a significant time commitment for you.

Medium-sized projects are estimated to take 175 hours, while large-sized projects are estimated to take 350 hours. The standard program duration is 12 weeks and in consultation with the mentor it can be extended to 22 weeks. Please keep in mind that the actual number of hours you spend on the project highly depends on your skills and previous experience.

GSoC provides some ways allowing you to be more flexible, but make sure that your schedule (exams, courses) give you sufficient amount of spare time.

Prior to project acceptance, you need to demonstrate that you can work with the flashrom codebase.
1. You need to be able to read and write C code.
2. You need to be able to work with our git repository. Check our Development Guidelines for details.
3. Look at Pending Patches to see what’s going on, who are our active developers and code reviewers, what does code review look like.
4. By the time you have submitted your application, you should have downloaded and built flashrom as well as applied some patches. Run flashrom on real hardware or try at least the dummy programmer driver.
5. Send a patch to Gerrit for review. Check Easy projects or ask for simple tasks on the mailing list or on IRC. Please include your flashrom output and test results in the commit message and/or comments to the patch.
To pass and to be paid by Google, we require that you meet certain milestones.
1. First, you should be in good standing with the community before the official start of the program. We suggest you post some design emails to the mailing list, and get feedback on them, both before applying, and during the "community bonding period" between acceptance and official start.
2. You need to have made progress and committed significant code before the mid-term point and by the final.
3. Once a week, you will post what’s happening on your project on the mailing list. This way you will measure and share progress with the community, and the community at large will be able to help you. GSoC is not a private contract between your mentor and you. If you have your own blog, you are very welcome to post updates there, and we will link your blog from our website.
4. You need to be active on IRC and the mailing list. Sending massive patches for midterm and final without any communication in between is not sufficient.

We don't expect our contributors to be experts in our problem domain, but we don't want you to fail because some basic misunderstanding was in your way of completing the task.

And finally, here are official guidelines for contributors.

@@ Line 1: / Line 1: @@
-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.
+== Information and Links ==
-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).
+Flashrom is applying for participation in [https://developers.google.com/open-source/gsoc/timeline GSoC 2022] (also known as Google Summer of Code). We will update this page in March 2022 once the registration is confirmed.
-The list below is an idea collection. Individual list items may be 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
+You are very welcome to look at our list of project ideas in [https://docs.google.com/document/d/1AxMobB2v8Dv2uUwZPZ_vCmmONYDJuliHcnjfWOs4qIs/edit?usp=sharing this doc].
-= libflashrom - Multiple UIs for flashrom =
+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 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.
+== How to contact us ==
-Some obvious UI ides are:
+If you are interested in becoming a GSoC student, please have a look at our [[Contact]] page.
-* 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 =
+If you need to contact someone directly, Anastasia Klimchuk (aklm), Felix Singer (flx) and Angel Pons (hell) are our GSoC Admins.
-* flashrom as payload
-* flashrom remote flashing for coreboot panic room mode
-* flashrom remote flashing with modified SerialICE
-= SPI bitbanging hardware support =
+== Why you should choose a Flashrom project for GSoC ==
-* 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 =
+* Flashrom offers you the opportunity to work with modern hardware “right on the iron”.
-* Automatic recovery in case something goes wrong
+* Hardware is fun. And it’s complicated. You will learn that datasheets are just loose guidelines to the hardware and real insight is gained by systematic tinkering.
-* Partial reflashing
+* Flashrom is the only multi-platform open source solution for flash EEPROM reading/writing for lots of different devices: on-mainboard flash (for BIOS/EFI/coreboot), graphics/network card flash (for firmware), and dozens of specialized programmer devices. If you want to update your BIOS/EFI/coreboot or update some firmware from a running Linux/*BSD/... system, then flashrom is the only choice you have.
-* Bytewise flashing (similar to the point above)
+* Flashrom does hardware access (like firmware/drivers), but completely in user space and without the hassles present in firmware or OS kernels. That way you can write complex hardware access with ease.
+* Flashrom has a worldwide developer and user base. Big companies like Google and individual users use and contribute to it.
+* We are a very passionate team – so you will interact directly with the project initiators and project leaders.
+* We have a friendly and helpful community. Flashrom has some extremely talented and helpful experts in all things flash active in the project, and many of our friends from the coreboot project participate in flashrom as well. They are ready to assist and mentor students participating in GSoC.
-= Locking and Unlocking =
+== Contents of your application ==
-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.
+Please have a look at our project proposal template  [https://docs.google.com/document/d/1DSg1FykuI7Z3JDY1Qtk8C6JjvpsYISMEwyV4932jtBI/edit?usp=sharing here].
-= Laptop support - Support for ECs (Embedded Controllers) =
+== Contributor commitments & requirements ==
-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).
+What does it mean to be a Flashrom GSoC contributor?
-= Support more chips - Implement (obscure and) unsupported features - Try to make flashrom write EEPROMs =
+Google Summer of Code is a significant time commitment for you.
-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.
+Medium-sized projects are estimated to take 175 hours, while large-sized projects are estimated to take 350 hours. The standard program duration is 12 weeks and in consultation with the mentor it can be extended to 22 weeks. Please keep in mind that the actual number of hours you spend on the project highly depends on your skills and previous experience.
+GSoC provides some ways allowing you to be more flexible, but make sure that your schedule (exams, courses) give you sufficient amount of spare time.
+# Prior to project acceptance, you need to demonstrate that you can work with the flashrom codebase.
+## You need to be able to read and write C code.
+## You need to be able to work with our git repository. Check our [https://www.flashrom.org/Development_Guidelines Development Guidelines] for details.
+## Look at [https://review.coreboot.org/q/project:flashrom Pending Patches] to see what’s going on, who are our active developers and code reviewers, what does code review look like.
+## By the time you have submitted your application, you should have downloaded and built flashrom as well as applied some patches. Run flashrom on real hardware or try at least the dummy programmer driver.
+## Send a patch to Gerrit for review. Check [[Easy projects]] or ask for simple tasks on the mailing list or on IRC. Please include your flashrom output and test results in the commit message and/or comments to the patch.
+# To pass and to be paid by Google, we require that you meet certain milestones.
+## First, you should be in good standing with the community before the official start of the program. We suggest you post some design emails to the mailing list, and get feedback on them, both before applying, and during the "community bonding period" between acceptance and official start.
+## You need to have made progress and committed significant code before the mid-term point and by the final.
+## Once a week, you will post what’s happening on your project on the mailing list. This way you will measure and share progress with the community, and the community at large will be able to help you. GSoC is not a private contract between your mentor and you. If you have your own blog, you are very welcome to post updates there, and we will link your blog from our website.
+## You need to be active on IRC and the mailing list. Sending massive patches for midterm and final without any communication in between is not sufficient.
+We don't expect our contributors to be experts in our problem domain, but we don't want you to fail because some basic misunderstanding was in your way of completing the task.
+And finally, here are [https://google.github.io/gsocguides/student/ official guidelines for contributors].