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: @@
-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.
+== Information and Links ==
-= Ideas =
+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.
-== Support more chips ==
+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].
-We could come up with a list of unsupported (or partially supported) chips and ask the student(s) to implement support.
+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].
-== Add locking/unlocking functions for all chips ==
+== How to contact us ==
-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.
+If you are interested in becoming a GSoC student, please have a look at our [[Contact]] page.
-== Add support for ECs (Embedded Controllers) ==
+If you need to contact someone directly, Anastasia Klimchuk (aklm), Felix Singer (flx) and Angel Pons (hell) are our GSoC Admins.
-Hard task, may be depending on availability of hardware and ability to recover in case something goes wrong.
+== Why you should choose a Flashrom project for GSoC ==
-== Add support for various flash programmers out there (Willem etc.) ==
+* 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.
-Will probably require a sizable amount of reverse engineering.
+== Contents of your application ==
-= Requirements =
+Please have a look at our project proposal template  [https://docs.google.com/document/d/1DSg1FykuI7Z3JDY1Qtk8C6JjvpsYISMEwyV4932jtBI/edit?usp=sharing here].
-This section is addressed to anyone interested working on flashrom.
+== Contributor commitments & requirements ==
-== Requirements for acceptance ==
+What does it mean to be a Flashrom GSoC contributor?
-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.
+Google Summer of Code is a significant time commitment for you.
-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.
+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.
-You have to know C and should be able to read datasheets (we can help with datasheet reading because it is hard).
+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.
-== Requirements for a passing grade ==
+# 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.
-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).
+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.
-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.
+And finally, here are [https://google.github.io/gsocguides/student/ official guidelines for contributors].
-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.