| || |
There is also an IRC channel on irc.freenode.net: #coreboot
There is also an IRC channel on irc.freenode.net: #coreboot
|−|= Projects 2008 = | |
|−|== SCSI booting in coreboot == | |
|−|Currently coreboot can not boot from an arbitrary SCSI controller. There are two solutions for the problem: | |
|−|* Use Linux and Kexec. This requires to keep the SCSI driver in the flash chip. | |
|−|* 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. | |
|−|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. | |
|−|This is a coreboot v3 project. | |
|−|== All Virtual All The Time ([[AVATT]]) == | |
|−|The goal here is to build a system that comes up running Linux and KVM from power on reset. From that | |
|−|point the system could boot anything -- Windows, Linux, *BSD, Plan 9 -- anything that runs | |
|−|on x86 32 and 64-bit architectures. Coreboot would be | |
|−|integrated with a Linux kernel and initrd that had KVM built in. The initrd would include the minimal set of tools needed for starting new KVM virtual machine guests. Note that Linux booting from coreboot is a solved | |
|−|problem, using the buildrom tool, so the main effort here is to develop a minimal KVM infrastructure that | |
|−|can fit in a 2Mbyte FLASH part. Linux + X11 have been demonstrated in a 1Mbyte part, so we feel that this | |
|−|task is not impossible, but will be a terrific learning experience for a student, and will provide | |
|−|the community with a valuable resource when it is finished. The Xen and KVM communities have both asked | |
|−|for this capability for some time now, so there is a group of people ready to use this system when it is | |
|−|finished. | |
|−|= Projects 2007 = | |
|−|== Booting Windows and other Operating Systems in LinuxBIOS [http://linuxbios.org/Booting_Windows_using_LinuxBIOS]== | |
|−|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: | |
|−|* using a dedicated LinuxBIOS loader (ie. adapting [http://www.reactos.org/ ReactOS] FREELDR) | |
|−|* 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. | |
|−|* 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]. | |
|−|== Port GRUB2 to work in LinuxBIOS == | |
|−|[[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. | |
|−|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://www.coreboot.org/Build_LinuxBIOS_using_LBdistro]== | |
|−|There's a small project called [http://tracker.coreboot.org/trac/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 22:44, 15 March 2009
Google Summer of Code 2009
Welcome to the Google Summer of Code(tm) page of the coreboot project.
Your own Projects
We've listed some ideas for projects here, but we're more than happy to entertain other ideas if you've got any.
Feel free to contact us under the address below, and don't hesitate to suggest whatever you have in mind.
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.
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 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.
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 booting from SeaBIOS.
TianoCore on coreboot
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?)
coreboot graphical port creator
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).
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.
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.
This is a coreboot v3 project. It requires good Java and/or Eclipse skills (or whatever toolkit/language you choose)
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.
Summer of Code Application
Please complete the standard 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 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.
The Drupal project has a great page on How to write an SOC application.
DEADLINE FOR STUDENT APPLICATIONS: Students who are interested in working on a coreboot-related GSoC project must apply between March 24, 2008 and March 30, 2008!
If you are interested in becoming a GSoC student, please contact Stefan Reinauer.
There is also an IRC channel on irc.freenode.net: #coreboot