GSoC: Difference between revisions

From coreboot
Jump to navigation Jump to search
No edit summary
No edit summary
Line 4: Line 4:


The coreboot project also tries to host some flashrom projects.
The coreboot project also tries to host some flashrom projects.


== Deadlines ==
== Deadlines ==


Make sure you check the official [http://google-melange.appspot.com/gsoc/events/google/gsoc2012 timeline].
Make sure you check the official [http://google-melange.appspot.com/gsoc/events/google/gsoc2012 timeline].


= Why work for coreboot =
= Why work for coreboot =
Line 56: Line 54:


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.
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.


== How to apply ==
== How to apply ==
Line 63: Line 60:


Please also read Google's [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Advice for Students].
Please also read Google's [http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents Advice for Students].


== Some Caveats ==
== Some Caveats ==
Line 73: Line 69:
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).
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 ==
== Time Frame ==


'''DEADLINE FOR STUDENT APPLICATIONS:''' Students who are interested in working on a coreboot-related GSoC project must apply between '''March 26, 2012''' and '''April 6, 2012'''! If you want to apply, please get in contact with us right away, not just when you send your application!
'''DEADLINE FOR STUDENT APPLICATIONS:''' Students who are interested in working on a coreboot-related GSoC project must apply between '''March 26, 2012''' and '''April 6, 2012'''! If you want to apply, please get in contact with us right away, not just when you send your application!


== Student requirements ==
== Student requirements ==
Line 89: Line 83:
If you are interested in becoming a GSoC student, please contact [mailto:marcj303@gmail.com Marc Jones] or visit our IRC channel on irc.freenode.net: #coreboot
If you are interested in becoming a GSoC student, please contact [mailto:marcj303@gmail.com Marc Jones] or visit our IRC channel on irc.freenode.net: #coreboot


 
== coreboot GSoC Mentors ==
= coreboot GSoC Mentor =
Please add you name to this list and follow the coreboot mentor link to [http://www.google-melange.com/gsoc/profile/mentor/google/gsoc2012?org=coreboot apply to be a coreboot mentor]
Please add you name to this list and follow the coreboot mentor link to [http://www.google-melange.com/gsoc/profile/mentor/google/gsoc2012?org=coreboot apply to be a coreboot mentor]


Line 99: Line 92:


= Possible ideas =
= Possible ideas =
The following are some ideas that have come up in the community. Some are more or less suitable for GSoC and prospective students' application should expand on some ideas and pair back others.
== coreboot ==


Please look at our [[Project Ideas|project ideas page]].


== flashrom ==
== flashrom ==


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
The flashrom project is somewhat independent of coreboot and has its own website and wiki. You can find project ideas for flashrom [http://www.flashrom.org/GSoC here].
 
''[http://www.flashrom.org/GSoC/2010 http://www.flashrom.org/GSoC/2010] has more flashrom ideas and suggestions.''
 
=== Multiple UIs for flashrom ===
* flashrom TUI (text mode user interface) (for command line and flashrom-as-payload)
* flashrom GUI (graphics mode user interface) (should be cross-platform, Sean Nelson has preliminary code you can base this on)
 
=== Recovery of dead boards and onboard flash updates ===
* flashrom as payload
* flashrom remote flashing for coreboot panic room mode
* flashrom remote flashing with modified SerialICE
 
=== SPI bitbanging hardware support ===
* 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 (total coding time estimated ~2-3 days, not sufficient for GSOC)
 
=== 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)
 
== Linux Firmware Kit, BITS ==
 
There are various test suites for firmware aspects, esp. those that interacts with the operating systems. Unfortunately, some of these projects are dead, some seem to be forked and developed semi-publically, and having all that stuff in lots of different places is a big hassle.
 
The goal of this project is to pick up the pieces, and create a single tool (most likely a bootable CD/USB drive image) that can be booted on vendor BIOS (for the Red Hat and Canonical developers that work on these) as well as coreboot (preferably seabios and FILO to improve testability - is an issue created/fixed by coreboot or seabios?). This can then be improved in various ways.
 
There's also intel-gpu-tools that might have some useful tests (at least for intel-boards): http://article.gmane.org/gmane.comp.video.dri.devel/63948
 
When applying for this task, please state in your proposal what you think might be worthy extensions to the existing tests.
 
Required knowledge for this task: Not so much coreboot/firmware level, but you should have some idea of the boot process of a Linux system (as these test suites are mostly Linux based). GSoC probably won't provide enough time to learn all that (Linux boot process, firmware interfaces such as ACPI) and still develop the tools in some useful way.
 
== 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:Stepan|Stefan Reinauer]]
 
 
== coreboot test suite ==
Create a test suite to gather and report coreboot mainboard and payload settings. This project may leverage libpayload, coreinfo, memtest86, BITS, and other tools. The suite should gather result and report them at summary and detailed levels.  The goal is to help coreboot developers identify problems and to test coreboot features. This project should work closely with the testing rig and test reporting projects. It is important the the student considers how testing and reporting can be extended as features and tests are added in the future.
 
=== Links ===
* [http://biosbits.org/ BITS]
http://www.coreboot.org/Supported_Motherboards
 
=== Mentor ===
* [[User:MJones|Marc Jones]]
 
== 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
* [[InSystemFlasher]] is a cheap DIY hardware prototype for building an automated testing rig for modern SPI-based boards. This could be used as a starting point.
 
=== Mentors ===
* [[User:Stepan|Stefan Reinauer]]
 
 
== coreboot mainboard test result reporting ==
One of the biggest challenges in coreboot is support many systems in the same codebase. As systems age and coreboot continues to develop, the condition of mainboards becomes unknown. This project would define a coreboot test results reporting mechanism, gather data, and report passing and failing systems on a webpage. This project would work closely with the coreboot test suite project and/or the hardware test rig project. A good example of test results gathering and reporting is done by the Phoronix/Openbenchmark. The student should investigate other test and reporting solutions to leverage the best options for coreboot.  It is important the the student considers how testing and reporting can be extended as features and tests are added in the future.
 
=== Links ===
* http://openbenchmarking.org/
* http://www.coreboot.org/Supported_Motherboards
 
=== Mentor ===
* [[User:Stepan|Stefan Reinauer]]
* [[User:MJones|Marc Jones]]
 
 
== coreboot ports for Family14 mainboards ==
Identify potential mainboards to port based on the recently released AMD Family 14 support. The goal would be to support publicly available plaftorms with a number of payloads and operating systems.
 
=== Mentor ===
*[[User:Jason Wang|QingPei Wang]]
 
 
== coreboot ACPI/S3/power managment ==
coreboot has support for ACPI tables and S3 support for some platforms, but it is very mainboard specific. Create a generic solution for ACPI table generation and S3 support.
 
=== Mentor ===
*
 
 
==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.
 
Note that coreboot has in the past supported three different CPUs (x86, Alpha, PPC), so the structure is there for adding in a new processor family.
We will need to find the right platform to do the work, but I (Ron) can provide a board and JTAG debugger if needed.
 
=== Mentors ===
* Bari Ari
* [[User:Rminnich|Ron Minnich]]
* [[User:Jason Wang|QingPei Wang]]
 
== coreboot panic room ==
 
Create a safe boot solution for coreboot to easily and cheaply recover the system in case of a panic().
 
Ron would like to base this solution around SerialICE. The basic idea is that the system always boots to SerialICE. There is a test in CMOS for 'last boot worked' and, if this is set, SerialICE finds a coreboot in cbfs and runs it. If 'last boot worked' is not set, or the user hits some magic keyboard sequence, SerialICE takes control.
 
SerialICE needs to be extended (not much) to make this work. Having this capability would make it possible for Ron to get some very hard ports working that are just not possible today. At the same time, there are lots of hardware boards to test this idea on, so it should be easy to get it working.
 
It might be possible to integrate this into the coreboot build as a bootblock option (in the same spot as the fallback/normal switch and the simple loader).
 
=== Mentors ===
* [[User:Rminnich|Ron Minnich]]
 
 
== Board config infrastructure ==
 
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.
 
=== Links ===
* ?
 
=== Mentors ===
* ?
 
 
== Refactor AMD code ==
 
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.
 
=== Links ===
* ?
 
=== Mentors ===
* [[User:Stepan|Stefan Reinauer]]
 
 
=== 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 embedded 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 ==
== 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.
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.


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!
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!


Feel free to contact us at the email address above, and don't hesitate to suggest whatever you have in mind.
Feel free to contact us at the email address or IRC channel above, and don't hesitate to suggest whatever you have in mind.
 


= Previous Summer of Code projects =
= Previous Summer of Code projects =


We successfully participated in Google's Summer of Code in 2007, 2008, 2009, 2010 and 2011. See our [[Previous GSoC Projects|list of previous GSoC projects]] or [http://code.google.com/soc/ Google's archive].
We successfully participated in Google's Summer of Code in 2007, 2008, 2009, 2010 and 2011. See our [[Previous GSoC Projects|list of previous GSoC projects]] or [http://code.google.com/soc/ Google's archive].

Revision as of 13:31, 5 March 2012

Google Summer of Code 2012

Welcome to the Google Summer of Code 2012 page of the coreboot project.

The coreboot project also tries to host some flashrom projects.

Deadlines

Make sure you check the official timeline.

Why work for coreboot

Why would you like to work for coreboot?

  • coreboot offers you the opportunity to work with modern technology "right on the iron".
  • Your application will be available to users worldwide and promoted along with all other coreboot projects.
  • 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.


Summer of Code Application

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

Name:
Email:
IM/IRC/Skype/other contact:
Country/Timezone:
School:
Degree Program:
Year:
Most students have some time off planned during GSoC. Do you have any vacations? When and how long?


coreboot welcomes students from all backgrounds and levels of experience. To be seriously consider for coreboot GSoC, we recommend joining the mailing list and IRC channel. 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. By the time you have submitted your application, you should have downloaded, built a and booted coreboot in QEMU, SimNow, or on real hardware. Please, email your serial output results to the mailing list.
The following information will help coreboot match students with mentors and projects.
Please comment on your software and firmware experience.
Have you participated in the coreboot community before?
Have you contributed to an open source project? Which one? What was your experience?
Have you built and run coreboot? Did you have problems?
Bonus, Did you find and fix a coreboot bug? Did you send a patch to the email list?


Please provide an overview of your project and a break down your project in small specific goals. 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?


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.

How to apply

The Drupal project has a great page on How to write an SOC application.

Please also read Google's 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 require 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. http://blogs.coreboot.org/

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.

Time Frame

DEADLINE FOR STUDENT APPLICATIONS: Students who are interested in working on a coreboot-related GSoC project must apply between March 26, 2012 and April 6, 2012! If you want to apply, please get in contact with us right away, not just when you send your application!

Student requirements

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.


Contact

If you are interested in becoming a GSoC student, please contact Marc Jones or visit our IRC channel on irc.freenode.net: #coreboot

coreboot GSoC Mentors

Please add you name to this list and follow the coreboot mentor link to apply to be a coreboot mentor


Possible ideas

coreboot

Please look at our project ideas page.

flashrom

The flashrom project is somewhat independent of coreboot and has its own website and wiki. You can find project ideas for flashrom here.

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.

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!

Feel free to contact us at the email address or IRC channel above, and don't hesitate to suggest whatever you have in mind.


Previous Summer of Code projects

We successfully participated in Google's Summer of Code in 2007, 2008, 2009, 2010 and 2011. See our list of previous GSoC projects or Google's archive.

Retrieved from "https://www.coreboot.org/index.php?title=GSoC&oldid=11049"