Previous GSoC Projects

From coreboot

Revision as of 22:44, 15 March 2009 by Stepan(Talk | contribs)(Created page with ' = 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 Ke...')

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.

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.

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 here and 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 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 Firmworks, Inc. released the 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 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.

GNUFI or TianoCore payloads

There are two open source EFI implementations out there. GNUFI (or here or here) and 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)

There's a small project called [3] 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.