GSoC: Difference between revisions

From coreboot
Jump to navigation Jump to search
(Remove flashrom from the project list for 2017)
(205 intermediate revisions by 19 users not shown)
Line 1: Line 1:
= Google Summer of Code 2008 =
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.


Welcome to the [http://code.google.com/soc/ Google Summer of Code(tm)] page of the [[Welcome to coreboot|coreboot project]].
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.


= Your own 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 [https://summerofcode.withgoogle.com/how-it-works/#timeline GSoC 2017 timeline].


We've listed some ideas for projects here, but we're more than happy to entertain other ideas if you've got any.
__FORCETOC__
Feel free to contact us under the address below, and don't hesitate to suggest whatever you have in mind.


= Summer of Code 2008 Application =
== coreboot contacts ==


Please complete the standard [http://code.google.com/soc/ Google SoC 2008 application]. Additionally, please provide information on the following:
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.


# Who are you? What are you studying?
[[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 are you the right person for this task?
# Do you have any other commitments that we should know about?
# List your C, Assembler or Java experience. (Depending on the project)
# List your history with open source projects.
# What is your preferred method of contact? (Phone, email, Skype, etc)


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.
= Why work on coreboot for GSoC 2017? =


The Drupal project has a great page on [http://drupal.org/node/59037 How to write an SOC application].
* 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.


'''DEADLINE FOR STUDENT APPLICATIONS:''' Students who are interested in working on a LinuxBIOS-related GSoC project must apply between '''March 24, 2008''' and '''March 30, 2008'''!
= GSoC Student requirements =


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


If you are interested in becoming a GSoC student, please contact [mailto:stepan@coresystems.de Stefan Reinauer].
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.


There is also an IRC channel on irc.freenode.net: #LinuxBIOS (actually a forwarder to #OpenBIOS because it is the same folks hanging out there.)
== 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]], [https://review.coreboot.org/cgit/coreboot.git/plain/Documentation/gerrit_guidelines.md? 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 [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.


= Projects 2008 =
== 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.


== VGA BIOS for Geode LX ==
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.


This project's goal is to write a VGA BIOS (PCI option rom) for AMD Geode LX systems (such as the Linutop, Thincan or XO). There exists a [http://savannah.nongnu.org/projects/vgabios free VGA BIOS] but it knows nothing about real hardware. If you really want to kick the iron, this project could be enhanced to contain a complete infrastructure for including hardware initialization code for many different graphics cards.
= Projects =


== SCSI booting in coreboot ==
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]


Currently coreboot can not boot from an arbitrary SCSI controller. There are two solutions for the problem:
We keep a list of [[previous GSoC Projects]] which might be of interest to you to see what others have accomplished.
* Use Linux and Kexec. This requires to keep the SCSI driver in the flash chip.
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.
* Use x86emu/vm86/[[ADLO]] and the int13 method. This would allow to use the PCI option rom available on all modern SCSI controllers.


So we obviously need a solution based on the later. This could as well be implemented as a Linux program, as an intermediate payload, or as a shared library.
== Your own Project Ideas ==


The code you are going to write needs to catch the int13 interrupt vector that the SCSI option rom installs and make it available to arbitrary (firmware/payload) code trying to load something from disk.
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.


This is a LinuxBIOSv3 project.
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 graphical port creator ==
coreboot welcomes students from all backgrounds and levels of experience.


In coreboot v2, every port to a new mainboard requires that you touch a lot of source files with only minimal changes. In version 3 we try to fix this issue and pack all mainboard specific information into a configuration file that we call the Device Tree Source (DTS).
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.
This Device Tree config file is a simple text file describing what static (non-detectable and/or soldered on) devices are used on the mainbard and how they are wired (SPD-ROM, Interrupt Routing, SuperIO, Northbridge, Southbridge, Hypertransport,..). It is mostly organized as a tree (with some special cases, Hypertransport allows cycles for instance)


The idea is to create a tool, based on the [www.eclipse.org/ Eclipse IDE], Swing, or your favourite portable toolkit, which allows you to drag and drop those components together and describe how they are wired.  
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. ;)


This would be a great help for mainboard vendors that build mainboards of already supported components. No more reading of coreboot code would be required, but rather only the understanding of the hardware, and probably the mainboard schematics.
=== 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?


This is a coreboot v3 project. It requires good Java and/or Eclipse skills (or whatever toolkit/language you choose)
=== 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?


== TianoCore on coreboot ==
=== 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?


[http://www.tianocore.org/ Tiano Core] is Intel's EFI implementation. Unlike coreboot, it is not a firmware, but rather a bootloader. Last year we started porting TianoCore to run on coreboot, but there are many things left to do. Improve Tiano Core running as a coreboot payloads, or change coreboot so it can load Tiano Core as a payloads.
=== Other ===
:Resume (optional):


This project requires no hardware skills, but especially in case of TianoCore might require knowledge of Windows compilers (VC2005?)
== Advice on how to apply ==
* 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]


== libpayload ==
= Mentors =


There are many, many "payloads" for coreboot these days: Linux, FILO, GRUB2, Tiano Core, Open Firmware, etherboot, and some more to count. All these payloads have a few functions in common that they use to read information from coreboot or change coreboot settings in NVRAM. It would be incredibly useful to unify all this code and enhance it, so that not every coreboot payload has to keep reinventing the wheel.
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).


= Projects 2007 =
== Volunteering to be a mentor ==


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.


== Booting Windows and other Operating Systems in LinuxBIOS [http://linuxbios.org/Booting_Windows_using_LinuxBIOS]==
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.


The goal of this sub project is to figure out how to boot Windows Vista/XP/2003. There are three approaches that might proof successful:
{| class="wikitable"
 
|-
* using a dedicated LinuxBIOS loader (ie. adapting [http://www.reactos.org/ ReactOS] FREELDR)
! Name !! Role !! Comms !! AFK / Vacation MMDD-MMDD
* booting Windows on top of Linux using [http://www.xmission.com/~ebiederm/files/kexec/README kexec]/[http://kboot.sourceforge.net/ kboot]
|-
* fixing [[ADLO]] so that it boots Vista/XP and removing the mainboard dependencies in it's code.
| [[User:MartinRoth|Martin Roth]] || coreboot: co-organizer and mentor || chat: martinr Email: gaumless@gmail.com|| No dates yet
* Some information on usage of bios services in Windows can be found [http://www.missl.cs.umd.edu/winint/index1.html here] and [http://www.missl.cs.umd.edu/winint/index2.html here].
|-
 
| [[User:PatrickGeorgi|Patrick Georgi]] || coreboot: co-organizer and mentor || chat: patrickg, pgeorgi ||
== Port GRUB2 to work in LinuxBIOS ==
|-
 
| [[User:Stepan|Stefan Reinauer]] || coreboot/serialice:  mentor  || chat: stepan ||
[[GRUB2]] is going to be _the_ bootloader of choice in the forseeable future. As such, it could replace both Grub legacy and FILO, the LinuxBIOS hack for grub compatibility. FILO lacks many features that come with GRUB2 with no extra effort.
|-
 
| [[User:Rminnich|Ron Minnich]] || coreboot: mentor || chat: rminnich ||
This task splits into four sub-problems:
|-
 
|}
* Add a target i386-linuxbios, next to i386-pc and i386-efi to the configuration process
* Add an IDE driver that does direct access instead of intXX calls
* Make the build process generate a single static ELF image, like it is done on Sparc
* Add support for reading the memory size from the LinuxBIOS table.
 
 
== CMOS Config / Device Tree Browser Payload ==
 
Unlike other BIOSes, Linux has no such thing as a "CMOS setup". This does not mean that you can not configure it. There is a nice and small Linux command line utility called [http://lxbios.sf.net lxbios] for that purpose. But people are often asking for a builtin config tool. Such a config tool could feature VGA graphics (maybe even VESA?), it should be easy to use, allow to browse information from LinuxBIOS' central structure: the device tree, and provide lxbios functionality with some sex appeal.
 
This is a LinuxBIOSv3 project.
 
== Open Firmware payload for LinuxBIOS ==
 
Mitch Bradley from [http://www.firmworks.com/ Firmworks, Inc.] released the [http://www.openbios.org/OpenFirmware Open Firmware sources] under a BSD license. The released code does work in LinuxBIOS, but could use some proper integration and testing on some hardware or in [http://fabrice.bellard.free.fr/qemu/ Qemu].
 
Some ideas:
 
* The released Open Firmware code is very much optimized towards the OLPC. A lot of things don't work yet on other systems, such as using a graphical framebuffer. Therefore things in LinuxBIOS need to be changed. For example, if LinuxBIOS initializes a graphics mode, it should add a LinuxBIOS table entry that specifies the address of the framebuffer and the depth and resolution.
* Add words to view the LinuxBIOS table in OFW
* Add words to change LinuxBIOS CMOS settings from OFW
* For LinuxBIOSv3, the start address of the payload can be variable. This is a fundamental change to v2, and will make life a lot easier and LinuxBIOS a lot more flexible. OFW requires to know its in-rom address at build time. This needs to be fixed to a dynamic behavior
* Also, there's no good documentation on what features can be used and how they can be used. Like the graphical OLPC menu, the built-in web server.
* Get a STOP-A like behavior working in Linux
* Get Smart Firmware working with new compilers
* Get Smart Firmware working as a payload
* Enhance the [[Distributed and Automated Testsystem]] to work with FILO and OpenFirmware payloads, and add The Hayes ANS Forth testsuite.
 
Some parts might require cooperation with other GSoC projects:
 
* Boot from Non-OFW SCSI controllers by running their int13 handler
* Boot Windows XP/2003/Vista in OFW
 
This project might benefit from Forth skills.
 
== GNUFI or TianoCore payloads ==
 
There are two open source EFI implementations out there. [http://gnufi.blogspot.com/ GNUFI] (or [http://www.hermann-uwe.de/blog/gnufi-the-gnu-firmware-implementation here] or [http://www.gnu.org/software/gnufi/ here]) and [http://www.tianocore.org/ TianoCore]. Try getting those to work as LinuxBIOS payloads, or change LinuxBIOS so it can load them as payloads.
 
This project requires no hardware skills, but especially in case of TianoCore might require knowledge of Windows compilers (VC2005?)
 
== Boot OpenSolaris, FreeBSD, NetBSD, OpenBSD or other free OSes ==
 
LinuxBIOS has (despite its name) been a little Linux centric. A nice project would be to analyze what it takes to get OpenSolaris, the BSDs or other free operating systems to work in LinuxBIOS, without the need for legacy emulation (ie. no [[ADLO]])
 
== Improve Linux as a BIOS [http://linuxbios.org/Build_LinuxBIOS_using_LBdistro]==
 
There's a small project called [http://www.linuxbios.org/viewvc/?root=buildrom buildrom] which creates a payload from a Linux kernel and some user space utilities. It has been written to work with the OLPC. This project could be enhanced to work on all supported LinuxBIOS motherboards.
 
== Porting Flashrom utility to Windows 2000/XP ==
 
Flashrom is used to burn LinuxBIOS binary to flash chips in the target motherboards. It runs on Unix/Linux. In this project the flashrom utility is ported from Linux/Unix to Windows 2000/XP. The Windows port is called Winflashrom. The project is divided into two tasks. The first task is to port most of the user space flashrom source code to MinGW and the second task is to code a Windows device driver to provide direct hardware access for the user space code. The difficulty of this task is in providing a reliable Windows device driver for the user space code.

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