« previous 1 2 3 4 5 next »

The beginnings of coreboot

AB: Stefan, Eric, how did it start for you?

Stefan Reinauer: I started the OpenBIOS project in 1997, by writing a linux kernel driver to do BIOS updates, and I called it "/dev/bios". It took me until some time in 1998 to get it working on a couple of mainboard/flashchip combinations. My idea was to implement the firmware console that SUN was offering to their customers: Open Firmware, known as IEEE 1275-1994. Along the way I found FreeBIOS and Tiara.

Still having no progress on my own BIOS/Firmware in 1999 I was really happy to see the LANL guys chime in. They took whatever open source code they could find , and fixed it up until it could boot a Linux kernel. Their first versions made heavy use of FreeBIOS and some smaller bits of what we had as OpenBIOS back then, and they eventually took over the FreeBIOS project on Source Forge.

Eric Biederman: In the beginning of 2000 I was out looking for work. Linux Networx at the time had just transitioned into being a start-up doing clusters, so the job I was hired to do was to implement LinuxBIOS for them.

The real work on LinuxBIOS began. I started with the partial port to the Intel L440GX motherboard and had something that was close to shippable. Unfortunately the first version was ready by the time the hardware was end-of-life but I learned a lot. Then to see how portable the work could be and because we were shipping an interesting number of Alpha machines, I ported LinuxBIOS Compaq Alpha DS10.

AB: Which alternatives to LinuxBIOS, if any, existed back then?

RM: For x86 there was OpenBIOS, just started at that time. For PPC, there was the PPCBoot, which has become U-Boot and continues to thrive – U-Boot is a very fine project.

AB: Can you describe the architectural differences in design and the challenges you faced while implementing new features?

RM: V1 was great for fairly simply systems as they existed: single northbridge with a shared front side bus between the CPUs, with that northbridge connected to a single south via PCI; the basic simple picture.

The K8 was the real driver for change in v1; that CPU and its complexity (three hyper-transport busses per cpu; memory controller per CPU; flexible topology) required the change in configuration and the new driver model. The work on v2 began in 2002. The three key ideas in v2 were the use of a configuration language that let us define topology; ROMCC, so we could minimise the use of assembly; and the device object model, a very flexible piece of code that gives us great control over the hard problem of allocating resources in the kind of complicated device trees found on K8 systems with PCIE root complexes. We discovered a few things along the way: first, that our code was really good: AMD told us in Oct. 2006 that the hyper-transport code in v2 was better than anything else out there!; and, second, that our BIOS was really good: we could easily boot with one CPU on a two CPU machine, and most commercial BIOSes would lock up in that situation (such as the factory BIOS on the Sun Ultra 40).

To give you some idea of how incredible the code is, the memory start-up code runs in parallel on some multicore systems. In other words, V2 is multicore-ready and SMP-safe. I just talked to a vendor the other day who thought that this idea was really futuristic – yet we have had it for several years.

V2 is very powerful, but also very complex; V3 is aimed at making work easier. My goal for a long time has been to support the engineers who can only put about 10 per cent of their time – one day every two weeks – into working with the BIOS code. We really pushed hard to use standards that people were used to, and removed some of the more esoteric features in V2 that people found confusing: ROMCC, "linker sets" and other tricky gcc/gld usages; the custom configuration system.

Next: About ROMCC and v3

« previous 1 2 3 4 5 next »