GSoC: Difference between revisions

From coreboot
Jump to navigation Jump to search
(Remove flashrom from the project list for 2017)
(125 intermediate revisions by 15 users not shown)
Line 1: Line 1:
= Google Summer of Code 2010 =
coreboot is applying for [https://summerofcode.withgoogle.com/ Google Summer of Code 2017] as a mentoring organization.
It is not assumed that we are accepted yet. We will announce this on the mailing list, chat.coreboot.org and update this page when we are informed on 27 February.


http://3.bp.blogspot.com/_fxRR_bT3LgA/S5U3rk2J-eI/AAAAAAAACE8/mBRYQwSqvqQ/s400/2010_NoURL_300x267px.jpg
coreboot has many [[Project Ideas]] for various ability levels. The coreboot project also acts as an umbrella organization for other open-source firmware related projects.


Welcome to the [http://code.google.com/soc/ Google Summer of Code(tm)] page of the [[Welcome to coreboot|coreboot project]]. Apply for a coreboot GSoC project at http://socghop.appspot.com/.
Official student application period in 2017 is from March 20 to April 3, with results announced on April 4.  For the complete timeline, please see the [https://summerofcode.withgoogle.com/how-it-works/#timeline GSoC 2017 timeline].


This year, coreboot also tries to host some flashrom projects.
__FORCETOC__


== Deadlines ==
== coreboot contacts ==


Make sure you check the [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline Deadlines]
If you are interested in participating in GSoC as a student student, please visit [https://chat.coreboot.org/ chat.coreboot.org]. Working closely with the community is highly encouraged, as we've seen that our most successful students are generally very involved.


= Why work for coreboot =
[[User:PatrickGeorgi|Patrick Georgi]] and [[User:MartinRoth|Martin Roth]] are the coreboot GSoC admins for 2017.  Please feel free to reach out to them directly if you have any questions.


Why would you like to work for coreboot?
= Why work on coreboot for GSoC 2017? =


* coreboot offers you the opportunity to work with modern technology "right on the iron".
* coreboot offers you the opportunity to work with various architectures right on the iron. coreboot supports both current and older silicon for a wide variety of chips and technologies.
* Your application will be available to users worldwide and promoted along with all other coreboot projects.
* coreboot has a worldwide developer and user base.
* We are a very passionate team - so you will interact directly with the project initiators and project leaders.  
* We are a very passionate team, so you will interact directly with the project initiators and project leaders.  
* We have a large, helpful community. Over 100 experts in hardware and firmware lurk on our mailing list, many of them waiting to help you.
* We have a large, helpful community. coreboot has some extremely talented and helpful experts in firmware involved in the project. They are ready to assist and mentor students participating in GSoC.
* One of the last areas where open source software is not common is firmware. Running proprietary firmware can have severe effects on user's freedom and security. coreboot changes that by providing a common framework for initial hardware initialization and you can help us succeed.


= GSoC Student requirements =


= Summer of Code Application =
What will be required of you to be a coreboot GSoC student?


Please complete the standard [http://code.google.com/soc/ Google SoC 2010 application]. Additionally, please provide information on the following:
Google Summer of Code is a full-time job. This means we expect you to work roughly 40 hours per week on your project, during the three months of coding. Obviously we have flexibility, but if your schedule (exams, courses, other obligations) does not give you this amount of time, then you should not apply. We expect to be able to see this level of effort in student output.


# Who are you? What are you studying?
== Before applying ==
# Why are you the right person for this task?
*Prior to project acceptance, you have demonstrated that you can work with the coreboot codebase.
# Do you have any other commitments that we should know about?
:*By the time you have submitted your application, you should have downloaded, built and booted coreboot in QEMU, SimNow, or on real hardware. Please email your serial output results to the mailing list.  
# List your C, Assembler and hardware experience.
:*Look over some of the development processes guidelines: [[git]], [https://review.coreboot.org/cgit/coreboot.git/plain/Documentation/gerrit_guidelines.md? Gerrit Etiquette and Guidelines], [[Development Guidelines]], and [[Developer Manual]]
# List your history with open source projects.
:*Get signed up for gerrit and push at least one patch to Gerrit for review. Check [[Easy projects]] or ask for simple tasks on the mailing list or on chat.coreboot.org if you need ideas.
# What is your preferred method of contact? (Phone, email, Skype, etc)
:*Look through some patches on gerrit to get an understanding of the review process and common issues
*Before applying, you should also join the [https://www.coreboot.org/mailman/listinfo/coreboot mailing list] and [https://chat.coreboot.org chat.coreboot.org]. Introduce yourself and mention that you are a prospective GSoC student. Ask questions and discuss the project that you are considering. Community involvement is a key component of coreboot development.


Feel free to keep your application short. A 15 page essay is no better than a 2 page summary. If you wish to write 15 pages, you are of course welcome to do so, and we will gladly put your paper up on the web page. But it is not required for the application.
== During the program ==
* To pass and to be paid by Google requires that you meet certain milestones.
:* First, you must be in good standing with the community before the official start of the program. We expect you to 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 must have made progress and committed significant code before the mid-term point and by the final.
:* We require that accepted students to maintain a blog, where you are expected to write about your project *WEEKLY*. This is a way to measure progress and for the community at large to be able to help you. GSoC is *NOT* a private contract between your mentor and you. [https://blogs.coreboot.org/ blogs.coreboot.org]
* Student must be active in the community on chat.coreboot.org and the mailing list.
* Students are expected to work on development publicly, and to push commits to the project on a regular basis. Depending on the project and what your mentor agrees to, these can be published directly to the project or to a public repository such as gitlab or github. If you are not publishing directly to the project codebase, be aware that we do not want large dumps of code that need to be rushed to meet the mid-term and final goals.


== How to apply ==
The Drupal project has a great page on [http://drupal.org/node/59037 How to write an SOC application].
Please also read Google's [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Advice for Students].
== Some Caveats ==
* Google Summer-of-Code projects are a full (day-) time job. This means we expect roughly 30-40 hours per week on your project, during the three months of coding. Obviously we have flexibility, but if your schedule (exams, courses) does not give you this amount of spare time, then maybe you should not apply.
* Getting paid by Google requires that you meet certain milestones. First, you must 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. Also, you must have made progress and committed significant code before the mid-term point.
* We are thinking of requiring accepted students to have a blog, where you will write about your project on a regular basis. This is so that the community at large can be involved and help you. SoC is not a private contract between your mentor and you.
Note that "regular basis" in the last item does _not_ mean "3 days before evaluation deadlines". You should be "around" all the time (reporting your feedback, sending in partial successes).
We don't expect our students 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.
We don't expect our students 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.


== Time Frame ==
= Projects =


'''DEADLINE FOR STUDENT APPLICATIONS:''' Students who are interested in working on a coreboot-related GSoC project must apply between '''March 29, 2010''' and '''April 9, 2010'''! If you want to apply, please get in contact with us right away, not just when you send your application!
There are many development tasks available in coreboot. Please visit the following pages for some ideas or come up with your own idea.
* [[Project Ideas|coreboot project ideas]]
<!-- * [https://www.flashrom.org/GSoC flashrom project ideas] -->
* [https://serialice.com/GSoC SerialICE project ideas]


== Student requirements ==
We keep a list of [[previous GSoC Projects]] which might be of interest to you to see what others have accomplished.
Similarly the [https://blogs.coreboot.org/blog/category/gsoc/ blog posts related to previous GSoC projects] might give some insights to what it is like to be a coreboot GSoC student.


We will only accept your proposal if you have demonstrated that you can work with our codebase. For that, you have to send a patch to the list which is acceptable. Just ask for simple tasks on the mailing list or on IRC.
== Your own Project Ideas ==
 
= Contact =
 
If you are interested in becoming a GSoC student, please contact [mailto:stepan@coresystems.de Stefan Reinauer].
 
There is also an IRC channel on irc.freenode.net: #coreboot
 
= Possible ideas =
 
== Infrastructure for automatic code checking ==
 
We already have a build bot that builds various configurations of coreboot. It would be nice to extend it with various code validation routines, for example:
* Validate that there's no regression in doxygen documentation (eg. are all arguments to functions still explained in @param tags, eg. after new arguments were added?)
* Make code lint clean (and maybe extend lint to not fall into our traps), and run lint over the tree. Report regressions
* Use LLVM's static code checking facilities, report regressions.
* Work on code coverage support for coreboot code (dump data into ram, or via serial. Provide tools to fetch it). Analyse that data.
 
=== Links ===
* LLVM tools: [http://clang.llvm.org/StaticAnalysis.html Clang static analyser], [http://llvm.org/ProjectsWithLLVM/#Calysto SSA assertion checker]
* Lint tools: [http://lclint.cs.virginia.edu/ Splint]
* Coverage: [http://ltp.sourceforge.net/test/coverage/lcov.php LCOV], [http://ggcov.sourceforge.net GGCOV]
 
=== Mentors ===
* [[User:MJones|Marc Jones]]
* [[User:Stepan|Stefan Reinauer]]
 
== TianoCore on coreboot ==
 
[[Image:Tianocoreboot.png|160px|right]]
 
[http://www.tianocore.org/ Tiano Core] is Intel's EFI implementation. Unlike coreboot, it is not a firmware, but rather a bootloader. In 2008 there was an initial port of TianoCore to run on coreboot, but there are many things left to do.
 
* Improve Tiano Core / EDK2 running as a coreboot payload
* Implement a coreboot framebuffer driver for Tiano Core
* Implement a coreboot flash filesystem (CBFS) driver for Tiano Core
* Integrate and automate check out and build process of Tiano Core
* Create CorebootPkg using OVMF instead of DUET.
* Provide a script that creates working binaries for the EDK shell, EDK apps, FAT driver(?), ...
* The final work must compile on a cross gcc, and coreboot's crossgcc script has to be adapted so it can build this compiler (if the default script is not capable of doing so yet)
 
This project requires no hardware skills, but especially in case of TianoCore will require knowledge of Microsoft compilers as well as the GNU tool chain.
 
=== Links ===
* [http://www.tianocore.org/ Tiano Core]
* https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/
 
=== Mentors ===
* [[User:Rminnich|Ron Minnich]]
* [[User:Stepan|Stefan Reinauer]]
* [[User:MJones|Marc Jones]]
 
==coreboot port to Marvell ARM SOC's with PCIe==
[http://www.marvell.com/products/processors/embedded/kirkwood/ Marvell Processors] These ARM SOC's with PCIe will become popular in netbooks later this year. These systems can take advantage of coreboot's strength in properly configuring PCI devices, fast boot time and payload support.
 
=== Mentors ===
* Bari Ari
 
== coreboot port to AMD 800 series chipsets ==
(probably too big of a task)
:I'm not sure that this is too of a big task. I think 800 is closely related to 780 and would be slightly harder than a 780 board port. ---[[User:MJones|MJones]]
 
=== Mentors ===
* [[User:Stepan|Stefan Reinauer]]
* [[User:MJones|Marc Jones]]
 
== coreboot mass-porting to AMD 780 series mainboards ==
 
Grab a couple of AMD 780 based mainboards and port coreboot to it.
 
=== Mentors ===
* [[User:Rminnich|Ron Minnich]]
* [[User:Stepan|Stefan Reinauer]]
* [[User:MJones|Marc Jones]]
 
== coreboot panic room ==
 
Create a safe boat solution for coreboot to easily and cheaply recover the system in case of a panic()
 
=== Mentors ===
* ?
 
== coreboot cheap testing rig ==
The goal of this project is to create a cheap testing rig which works with the existing board test infrastructure. We have a hardware test system since 2006:
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/Slides-LinuxBIOS-QA.pdf Quality Assurance Talk (Slides)]
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestIntegrationManual.pdf Test Integration Manual]
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/DevelopersManual.pdf Test Developers Manual]
* [http://www.coresystems.de/PDFs/LinuxBIOS-testing/TestSpecification.pdf Test Specification]
 
The initial version of our testing rig used a remote power switch and was rather expensive. With cheaper technologies such as X10, it's possible to drop the testing costs per board significantly.
 
=== Links ===
* http://qa.coresystems.de
 
=== Mentors ===
* [[User:Stepan|Stefan Reinauer]]
 
== coreboot GeodeLX port from v3 to v4 ==
 
significant parts of that are already done, so it's hard to fill a full GSoC with that. One thing could be "verify that everything is brought over", but that's nothing that can be reasonably proven (and it might also be too close to "documentation tasks", which are not allowed)
 
=== Links ===
* ?
 
=== Mentors ===
* ?
 
== drivers for libpayload ==
 
IDE, AHCI, Bluetooth, Firewire, Smartcards, maybe filesystems. Work towards making FILO only a shell, which uses libpayload for the "real" work.
 
Notice that libpayload code must be licensed BSD-style (so ports from FILO, SeaBIOS or Linux won't work).
Pick a given set and tell us why it's enough work for the allocated time, but not too much for you. Also, which sources (if any) you want to draw from. We will not accept code that has been taken from other (GPL) projects. If you are taking this project you have to be willing and capable of writing your own hardware drivers.


=== Links ===
We have come up with some ideas for cool Summer of Code projects. These are projects that we think can be managed in the short period of GSoC, and they cover areas where coreboot is trying to reach new users and new use cases.
* ?


=== Mentors ===
Of course your application does not need to be based on any of the ideas listed. The opposite: Maybe you have a great idea that we just didn't think of yet. Please let us know!
* Stefan Reinauer


== Board config infrastructure ==
= coreboot Summer of Code Application =
Design data structures that host information about the board layout so coreboot can better initialize components and generate all kinds of tables (mptable, pirq, acpi, ...) from that dynamically (at build or runtime, as appropriate). Adapt boards to use that instead of the current hardcodes.


== Refactor AMD code ==
coreboot welcomes students from all backgrounds and levels of experience.  
AMD K8 and AMD Fam10 are different enough to have their own code. This is unfortunate, as you have to decide which CPU type you use in a given mainboard. Refactor AMD code so a single image can support both chip types on a given board. Also move tables from get_bus_conf and the like to the device tree or kconfig options (or runtime detection), as appropriate.


=== Mentors ===
Your application should include a complete project proposal. You should document that you have the knowledge and the ability to complete your proposed project. This may require a little research and understanding of coreboot prior to sending your application. The community and coreboot project mentors are your best resource in fleshing out your project ideas and helping with a project timeline. We recommend that you get feedback and recommendations on your proposal before the application deadline.
* [[User:Stepan|Stefan Reinauer]]


== Payload infrastructure ==
Please complete the standard Google SoC application and project proposal. Prospective coreboot GSoC student should provide the following information as part of their application. If you are applying for a flashrom or SerialICE project use common sense when using the template below, this is part of the test. ;)
Incorporate payload building into the coreboot build. kconfig options could be added for supported payloads, those payload could be updated to build with kconfig as well. Payloads that build with libpayload need would need default configs. Payloads should also be built with the crossgcc tools. This is related to the libpayload and board config infrastructure above. ---[[User:MJones|MJones]]


== flashrom ==
=== Personal Information ===
:Name:
:Email:
:Phone number:
:chat/IM/IRC/Skype/other contact:
:Country/Timezone:
:Normal working hours(UTC):
:School:
:Degree Program:
:Expected graduation date:
:Short bio / overview of your background:
:What are your other time commitments? Do you have a job, classes, vacations? When and how long?


Note: The list below is an idea collection. Individual list items are simple enough to serve only as partial GSoC task, but they are grouped to reasonable tasks.  If you're interested, please talk to us on the flashrom mailing list and/or on IRC irc://irc.freenode.net/#flashrom
=== Software experience ===
:Github / Web Page / Blog / Microblog / Portfolio:
:Links to one or more patches submitted to the project you're applying for:
:Links to posts on the mailing list with the serial output of your build: [https://www.coreboot.org/pipermail/coreboot/ Mailing List Archives]
:Please comment on your software and firmware experience.
:Have you contributed to an open source project? Which one? What was your experience?
:Did you build and run coreboot? Did you have problems?


''[http://www.flashrom.org/GSoC/2010 http://www.flashrom.org/GSoC/2010] has more flashrom ideas and suggestions.''
=== Your project ===
: Please provide an overview of your project (in your own words).
:: Provide break down of your project in small specific weekly goals. Think about the potential timeline.
:: How will you accomplish this goal? What is your working style?
:: Explain what risks or potential problems your project might experience.
:: What would you expect as a minimum level of success?
:: Do you have a stretch goal?


=== Multiple GUIs for flashrom ===
=== Other ===
:Resume (optional):


* flashrom text mode GUI (for command line and flashrom-as-payload)
== Advice on how to apply ==
* flashrom graphics mode GUI (should be cross-platform, Sean Nelson has preliminary code you can base this on)
* The Drupal project has a great page on [https://www.drupal.org/node/59037 how to write an SOC application].
* GSoC Student Guide: [http://en.flossmanuals.net/GSoCStudentGuide/]
* Secrets for GSoC success: [http://softwareswirl.blogspot.com/2014/03/my-secret-tip-for-gsoc-success.html]


=== Recovery of dead boards and onboard flash updates ===
= Mentors =


* flashrom as payload
Each accepted project will have a lead mentor and a backup mentor. We will match mentors and students based on the project, experience level, and geographic location (native language, culture and time zone).
* flashrom remote flashing for coreboot panic room mode
* flashrom remote flashing with modified SerialICE


=== SPI bitbanging hardware support ===
Summer of Code primary mentors, are expected to stay in frequent contact with the student and provide guidance such as code reviews, pointers to useful documentation, etc. This should generally be a time commitment of one to two hours a week.
 
* flashrom support for Nvidia SPI chipset hardware
* flashrom support for RayeR SPIPGM hardware
* flashrom support for [[Paraflasher]] hardware
* flashrom support for Willem hardware
* flashrom support for some-yet-uninvented cheap universal LPC/FWH/SPI flasher hardware
* flashrom support for bitbanging LPC/FWH (code exists, Uwe Hermann
* flashrom support for bitbanging Parallel
 
=== Generic flashrom infrastructure improvements ===
 
* flashrom support for automatic recovery in case something goes wrong
* flashrom support for partial reflashing
* flashrom support for bytewise flashing (similar to the point above)
 
=== Laptop support ===
 
This one is really HARD. If you're lucky and if you have datasheets, you can do it 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 embeddec controller which won't cause you to give up in frustration. Still, it might be beneficial if you're willing to solder.
* flashrom support for embedded controllers (ECs) in laptops
 
 
=== Links ===
* [http://www.flashrom.org/ flashrom]
 
=== Mentors ===
* ?
 
== Your own Project Ideas ==


We have come up with some ideas for cool Summer of Code projects here. These are projects that we think can be managed in the short period of GSoC, and they cover areas where coreboot is trying to reach new users and new use cases.
Backup mentors are expected to coordinate with the primary mentor and student on a regular basis, and keep track of the student process. They should be work with the primary mentor and be available to take over mentoring duty if the primary mentor is unavailable (vacations, sickness, emergencies).


But of course your application does not need to be based on any of the ideas listed below. The opposite: Maybe you have a great idea that we just didn't think of yet. Please let us know!
== Volunteering to be a mentor ==


Feel free to contact us at the email address above, and don't hesitate to suggest whatever you have in mind.
If you'd like to volunteer to be a mentor, please read the [https://developers.google.com/open-source/gsoc/resources/manual#mentor_manual GSoC Mentor Manual].  This will give you a better idea of expectations, and where to go for help.
After that, contact Martin or Patrick and let them know that you're interested.


= Previous Summer of Code projects =
The following coreboot developers have volunteered to be GSoC 2017 mentors. Please stop by [https://chat.coreboot.org chat.coreboot.org] and say hi to them and ask them questions.


We successfully participated in Google's Summer of Code in 2007, 2008 and 2009. See our [[Previous GSoC Projects|list of previous GSoC projects]].
{| class="wikitable"
|-
! Name !! Role !! Comms !! AFK / Vacation MMDD-MMDD
|-
| [[User:MartinRoth|Martin Roth]] || coreboot: co-organizer and mentor || chat: martinr Email: gaumless@gmail.com|| No dates yet
|-
| [[User:PatrickGeorgi|Patrick Georgi]] || coreboot: co-organizer and mentor || chat: patrickg, pgeorgi ||
|-
| [[User:Stepan|Stefan Reinauer]] || coreboot/serialice:  mentor  || chat: stepan ||
|-
| [[User:Rminnich|Ron Minnich]] || coreboot: mentor || chat: rminnich ||
|-
|}

Revision as of 10:05, 21 January 2017

coreboot is applying for Google Summer of Code 2017 as a mentoring organization. It is not assumed that we are accepted yet. We will announce this on the mailing list, chat.coreboot.org and update this page when we are informed on 27 February.

coreboot has many Project Ideas for various ability levels. The coreboot project also acts as an umbrella organization for other open-source firmware related projects.

Official student application period in 2017 is from March 20 to April 3, with results announced on April 4. For the complete timeline, please see the GSoC 2017 timeline.


coreboot contacts

If you are interested in participating in GSoC as a student student, please visit chat.coreboot.org. Working closely with the community is highly encouraged, as we've seen that our most successful students are generally very involved.

Patrick Georgi and Martin Roth are the coreboot GSoC admins for 2017. Please feel free to reach out to them directly if you have any questions.

Why work on coreboot for GSoC 2017?

  • coreboot offers you the opportunity to work with various architectures right on the iron. coreboot supports both current and older silicon for a wide variety of chips and technologies.
  • coreboot has a worldwide developer and user base.
  • We are a very passionate team, so you will interact directly with the project initiators and project leaders.
  • We have a large, helpful community. coreboot has some extremely talented and helpful experts in firmware involved in the project. They are ready to assist and mentor students participating in GSoC.
  • One of the last areas where open source software is not common is firmware. Running proprietary firmware can have severe effects on user's freedom and security. coreboot changes that by providing a common framework for initial hardware initialization and you can help us succeed.

GSoC Student requirements

What will be required of you to be a coreboot GSoC student?

Google Summer of Code is a full-time job. This means we expect you to work roughly 40 hours per week on your project, during the three months of coding. Obviously we have flexibility, but if your schedule (exams, courses, other obligations) does not give you this amount of time, then you should not apply. We expect to be able to see this level of effort in student output.

Before applying

  • Prior to project acceptance, you have demonstrated that you can work with the coreboot codebase.
  • By the time you have submitted your application, you should have downloaded, built and booted coreboot in QEMU, SimNow, or on real hardware. Please email your serial output results to the mailing list.
  • Look over some of the development processes guidelines: git, Gerrit Etiquette and Guidelines, Development Guidelines, and Developer Manual
  • Get signed up for gerrit and push at least one patch to Gerrit for review. Check Easy projects or ask for simple tasks on the mailing list or on chat.coreboot.org if you need ideas.
  • Look through some patches on gerrit to get an understanding of the review process and common issues
  • Before applying, you should also join the mailing list and chat.coreboot.org. Introduce yourself and mention that you are a prospective GSoC student. Ask questions and discuss the project that you are considering. Community involvement is a key component of coreboot development.

During the program

  • To pass and to be paid by Google requires that you meet certain milestones.
  • First, you must be in good standing with the community before the official start of the program. We expect you to 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 must have made progress and committed significant code before the mid-term point and by the final.
  • We require that accepted students to maintain a blog, where you are expected to write about your project *WEEKLY*. This is a way to measure progress and for the community at large to be able to help you. GSoC is *NOT* a private contract between your mentor and you. blogs.coreboot.org
  • Student must be active in the community on chat.coreboot.org and the mailing list.
  • Students are expected to work on development publicly, and to push commits to the project on a regular basis. Depending on the project and what your mentor agrees to, these can be published directly to the project or to a public repository such as gitlab or github. If you are not publishing directly to the project codebase, be aware that we do not want large dumps of code that need to be rushed to meet the mid-term and final goals.

We don't expect our students 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.

Projects

There are many development tasks available in coreboot. Please visit the following pages for some ideas or come up with your own idea.

We keep a list of previous GSoC Projects which might be of interest to you to see what others have accomplished. Similarly the blog posts related to previous GSoC projects might give some insights to what it is like to be a coreboot GSoC student.

Your own Project Ideas

We have come up with some ideas for cool Summer of Code projects. These are projects that we think can be managed in the short period of GSoC, and they cover areas where coreboot is trying to reach new users and new use cases.

Of course your application does not need to be based on any of the ideas listed. The opposite: Maybe you have a great idea that we just didn't think of yet. Please let us know!

coreboot Summer of Code Application

coreboot welcomes students from all backgrounds and levels of experience.

Your application should include a complete project proposal. You should document that you have the knowledge and the ability to complete your proposed project. This may require a little research and understanding of coreboot prior to sending your application. The community and coreboot project mentors are your best resource in fleshing out your project ideas and helping with a project timeline. We recommend that you get feedback and recommendations on your proposal before the application deadline.

Please complete the standard Google SoC application and project proposal. Prospective coreboot GSoC student should provide the following information as part of their application. If you are applying for a flashrom or SerialICE project use common sense when using the template below, this is part of the test. ;)

Personal Information

Name:
Email:
Phone number:
chat/IM/IRC/Skype/other contact:
Country/Timezone:
Normal working hours(UTC):
School:
Degree Program:
Expected graduation date:
Short bio / overview of your background:
What are your other time commitments? Do you have a job, classes, vacations? When and how long?

Software experience

Github / Web Page / Blog / Microblog / Portfolio:
Links to one or more patches submitted to the project you're applying for:
Links to posts on the mailing list with the serial output of your build: Mailing List Archives
Please comment on your software and firmware experience.
Have you contributed to an open source project? Which one? What was your experience?
Did you build and run coreboot? Did you have problems?

Your project

Please provide an overview of your project (in your own words).
Provide break down of your project in small specific weekly goals. Think about the potential timeline.
How will you accomplish this goal? What is your working style?
Explain what risks or potential problems your project might experience.
What would you expect as a minimum level of success?
Do you have a stretch goal?

Other

Resume (optional):

Advice on how to apply

Mentors

Each accepted project will have a lead mentor and a backup mentor. We will match mentors and students based on the project, experience level, and geographic location (native language, culture and time zone).

Summer of Code primary mentors, are expected to stay in frequent contact with the student and provide guidance such as code reviews, pointers to useful documentation, etc. This should generally be a time commitment of one to two hours a week.

Backup mentors are expected to coordinate with the primary mentor and student on a regular basis, and keep track of the student process. They should be work with the primary mentor and be available to take over mentoring duty if the primary mentor is unavailable (vacations, sickness, emergencies).

Volunteering to be a mentor

If you'd like to volunteer to be a mentor, please read the GSoC Mentor Manual. This will give you a better idea of expectations, and where to go for help. After that, contact Martin or Patrick and let them know that you're interested.

The following coreboot developers have volunteered to be GSoC 2017 mentors. Please stop by chat.coreboot.org and say hi to them and ask them questions.

Name Role Comms AFK / Vacation MMDD-MMDD
Martin Roth coreboot: co-organizer and mentor chat: martinr Email: gaumless@gmail.com No dates yet
Patrick Georgi coreboot: co-organizer and mentor chat: patrickg, pgeorgi
Stefan Reinauer coreboot/serialice: mentor chat: stepan
Ron Minnich coreboot: mentor chat: rminnich