|
|
| (175 intermediate revisions by 16 users not shown) |
| Line 1: |
Line 1: |
| = Google Summer of Code 2009 =
| | {{#externalredirect: https://doc.coreboot.org/contributing/gsoc.html}} |
| | |
| http://code.google.com/images/2009socwithlogo.gif
| |
| | |
| Welcome to the [http://code.google.com/soc/ Google Summer of Code(tm)] page of the [[Welcome to coreboot|coreboot project]].
| |
| | |
| = Your own Projects =
| |
| | |
| 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.
| |
| | |
| 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 below, and don't hesitate to suggest whatever you have in mind.
| |
| | |
| = 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]
| |
| | |
| === Mentors ===
| |
| * [[User:PatrickGeorgi|Patrick Georgi]]
| |
| * [[User:MJones|Marc Jones]]
| |
| * [[User:Stepan|Stefan Reinauer]]
| |
| | |
| == VGA BIOS for Geode LX ==
| |
| | |
| 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.
| |
| | |
| === Links ===
| |
| * [http://savannah.nongnu.org/projects/vgabios free VGA BIOS]
| |
| | |
| === Mentors ===
| |
| * [[User:Ward|Ward Vandewege]]
| |
| * [[User:Stepan|Stefan Reinauer]]
| |
| * [[User:MJones|Marc Jones]]
| |
| * [[User:Stuge|Peter Stuge]]
| |
| | |
| == USB Option ROM for SeaBIOS ==
| |
| | |
| SeaBIOS is our latest and greatest way to boot all kinds of different operating systems. It is a coreboot payload that implements 16bit BIOS interrupts as they are needed by nearly all boot loaders today. In the last year, SeaBIOS learned how to cope with coreboot ACPI, and how to boot off SCSI drives. One major feature that we're desperately lacking is USB stick/disk/cdrom booting from SeaBIOS.
| |
| USB support for SeaBIOS should be implemented as a PCI option rom, using the [[libpayload]] USB stack. The USB stack currently supports UHCI controllers. Part of this project could also be to add OHCI and EHCI support to the USB stack in libpayload (not a requirement for participation, but would sure be nice!)
| |
| | |
| === Links ===
| |
| * [[SeaBIOS]]
| |
| * [[libpayload]]
| |
| | |
| === Mentors ===
| |
| | |
| * [[User:MJones|Marc Jones]]
| |
| * [[User:PatrickGeorgi|Patrick Georgi]]
| |
| * [[User:Stepan|Stefan Reinauer]]
| |
| | |
| == TianoCore on coreboot ==
| |
| | |
| [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.
| |
| | |
| This project requires no hardware skills, but especially in case of TianoCore might require knowledge of Windows compilers (VC2005?)
| |
| | |
| === Links ===
| |
| * [http://www.tianocore.org/ Tiano Core]
| |
| | |
| === Mentors ===
| |
| * [[User:Rminnich|Ron Minnich]]
| |
| * [[User:Stepan|Stefan Reinauer]]
| |
| * [[User:MJones|Marc Jones]]
| |
| | |
| == AVATT part 2 ==
| |
| | |
| [[AVATT]] is coreboot+Linux+KVM as hypervisor in the ROM. A first version was done during last GSoC, but there is still a pretty big TODO list.
| |
| === TODO ===
| |
| * make the kvm userspace tool not to crash anymore. A possible solution would be to fix the TLS issues from the version of uClibc we currently use (daily snapshots from their SVN tree). This could even mean porting the uClibc-nptl branch to x86 if both of the x86 linuxthreads branches prove to be too hard to fix.
| |
| * user-friendly tool that can create and run virtual machines.
| |
| * automatically starting the virtual machines at boot.
| |
| * get the network to work in qemu since it fails with both coreboot v2 and v3.
| |
| * integrate the virt-manager daemon inside the ROM image, if it and its dependencies fit the remaining free space. This needs network support, to really be useful.
| |
| * fix compilation on x86_64 boxes by compiling everything in 64bit mode. We need a 64bit hardware anyway since the SVM instructions are available only on recent 64 bit boxes so this shouldn't matter too much, except for some extra wasted ROM space caused by the 64bit code. We can't cross-compile because we're not using a full toolchain, like buildroot does.
| |
| * keep the versions as up-to-date as possible but also compatible with each other
| |
| | |
| === Mentors ===
| |
| * [[User:Hailfinger|Carl-Daniel Hailfinger]]
| |
| * [[User:Rminnich|Ron Minnich]]
| |
| * [[User:Stepan|Stefan Reinauer]]
| |
| | |
| = Previous Summer of Code projects =
| |
| | |
| We successfully participated in Google's Summer of Code in 2007 and 2008. See our [[Previous GSoC Projects|list of previous GSoC projects]].
| |
| | |
| = 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 [http://code.google.com/soc/ Google SoC 2008 application]. Additionally, please provide information on the following:
| |
| | |
| # Who are you? What are you studying?
| |
| # Why are you the right person for this task?
| |
| # Do you have any other commitments that we should know about?
| |
| # List your C, Assembler and hardware experience.
| |
| # 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.
| |
| | |
| == 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.
| |
| | |
| == Time Frame ==
| |
| | |
| '''DEADLINE FOR STUDENT APPLICATIONS:''' Students who are interested in working on a coreboot-related GSoC project must apply between '''March 23, 2009''' and '''April 3, 2009'''! If you want to apply, please get in contact with us right away!
| |
| | |
| = 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
| |