[coreboot] Fwd: Re: Open Firmware

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Thu Jun 5 22:31:36 CEST 2008


Hi all,

I felt compelled to respond to the post by Werner Almesberger on
openmoko-kernel, but forgot to CC it here, so you get it as forwarded mail.

Regards,
Carl-Daniel

-------- Original Message --------
Subject: 	Re: Open Firmware
Date: 	Thu, 05 Jun 2008 22:16:37 +0200
From: 	Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
To: 	openmoko-kernel at lists.openmoko.org
References: 	7780e76c0805231833x58ac3655j34e2eb1ee9bdbe40 at mail.gmail.com



Hi all,

sorry for appearing out of nowhere. I have been following Openmoko for
quite some time and I'm very pleasantly surprised by what has been
achieved in such short time.

Werner Almesberger wrote:
> I wonder what troubles OLPC ran into with LinuxBIOS. I can understand
> the slow boot time issues, but it should be easy enough to add a
> fastpath for this.

As someone who participated in early porting of LinuxBIOS (now coreboot)
to the OLPC platform, I feel I'm qualified to answer this.
Basically, in the beginning there was a choice between a proprietary
BIOS and LinuxBIOS+Linux in the ROM. Since LinuxBIOS-Linux worked so
well, that solution was chosen. However, size constraints of the ROM
eventually led to the conclusion that something smaller than a full
Linux kernel in the ROM was desirable. At that point, OpenFirmware
became open source and it was subsequently used in combination with
LinuxBIOS in the ROM. After some time, Mitch Bradley (OpenFirmware
creator and expert) was (iirc) hired by OLPC to work on the firmware
full time. Since he's an OpenFirmware expert and was not too familiar
with the LinuxBIOS code, he eventually decided to move early hardware
init into OpenFirmware and remove LinuxBIOS.
The slow boot time was only partially (~10%) caused by LinuxBIOS version
2 and that issue has been fixed in coreboot v3. I have seen rather slow
AMD Geode machines run through coreboot v3 initialization in 500 ms
(including RAM setup, PCI setup etc.), so 500 ms after poweron you get
to pass execution to a Linux kernel. Depending on your hardware, faster
startup is possible.


At the beginning of this year, LinuxBIOS was renamed to coreboot because
we're neither a BIOS nor do we have Linux dependencies. However, we
optionally support a Linux kernel (and a traditional BIOS emulation if
anyone wants that) as a so-called payload, the thing that's executed
directly after the lowlevel hardware init has been performed.

We (the coreboot team) are very interested in validating our brand new
coreboot version 3 design on multiple architectures. It works well on
x86 (AMD GeodeLX is tested right now) and you can bundle it with a Linux
kernel in ROM easily. We call that scenario LAB (Linux As Bootloader)
and some people use it heavily. Since coreboot supports LZMA compressed
payloads natively, having a complete Linux kernel in ROM is not a big
size challenge anymore.

If anybody wants to port coreboot to the FreeRunner or any other
platform, we'd be happy to help. A first look at the code is probably
easiest if you pick the coreboot v3 qemu(x86) target and work from there.

More info about coreboot is available at http://www.coreboot.org/ .
The mailing list is http://www.coreboot.org/mailman/listinfo/coreboot
IRC (may be a bit slow to respond) http://www.coreboot.org/IRC

If you have any questions, want a short demo, pointers to "cool
features" lists or a generic introduction, feel free to ask either me
personally or all developers via our mailing list.

Regards,
Carl-Daniel



-- 
http://www.hailfinger.org/





More information about the coreboot mailing list