Hi, I have about 11 years of experience with coreboot. I got involved while developing a custom BIOS for an embedded system.
You may already have caught some presentation I or one of the other developers have made about the project. There's a bunch of links over at http://www.coreboot.org/Screenshots Richard Yao wrote: > Core Boot is a Linux distribution. Sorry sir, but no. coreboot (one word, lowercase) is an open source BIOS replacement. Proprietary BIOSes do two things: 1. hardware initialization on http://stuge.se/pc2010.png everything red requires init by firmware 2. starts an operating system this means implementing the BIOS Boot Specification, running master boot record code into real mode segment 7c00h, eltorito CD-ROM extensions and all of that crap coreboot does step 1. and nothign else, and significantly faster than common proprietary BIOSes. When coreboot is done it starts another, separate, program, we call that program "the payload." The payload and coreboot are stored together in the boot flash, but are not linked together. The payload can be any bare-metal program. There are many legacy-free bootloader payloads, including GRUB2 and gPXE/iPXE/whateverit'scalledtoday, but it can just as easily be an operating system kernel or an embedded application if no OS is needed. Boot flash are often 32Mbit today, so Linux and a small initramfs fits comfortably. The default payload is SeaBIOS, which is also the firmware QEMU uses. SeaBIOS is an open source legacy BIOS implementation, and the combination of coreboot and SeaBIOS provides a legacy-compatible boot environment that starts your system exactly like an old-fashioned proprietary BIOS. With coreboot my laptop boots from power button to firefox in a little over 8 seconds. Out of that time, coreboot runs for about 600 milliseconds. This is a fairly typical number. > The 80386's RESET state is emulated uniformly across all x86 and amd64, > so it should not take much effort to support the basic functions of > setting up the CPU, loading the kernel (from the EEPROM) and jumping > into it. This is word for word what the founders of the coreboot project (then called LinuxBIOS) thought back in 1999, and it blew up in their face. In the following 15 years hardware has gotten significantly more complex, and significantly more closed, again please have a look at http://stuge.se/pc2010.png The closer you are to the CPU the more impossible it is to acquire reliable documentation for how to program the hardware. > Those are the only things that a BIOS replacement needs to do. Please join the project! If you find lowlevel programming interesting it is an amazing good time, even if progress is slow at times. Now is a fantastic time to get involved! For the first time in the history of the project, there is code in the repository for all current hardware platforms from both AMD and Intel. > they are doing far more than those basic functions I hope I've been able to clarify that actually coreboot does nothing other than what is neccessary. This is the very essence of coreboot. > Basic functionality would only require the work of a few people. I'm afraid that this is rather naive. An experienced coreboot developer given all required documentation[1] (and ideally some 100-1000k EUR/USD worth of test equipment) can possibly do a port to a new hardware platform (new CPU and chipset) in twelve to eighteen months full time. A hard core developer but without previous experience from PC firmware and coreboot should add some six months for loading the domain into her head. [1] For Intel this requires two stages of NDAs and a decent business case where Intel will sell five-six figure amounts of chips, or fewer chips but to an important customer. In contrast, AMD put the documentation on their webpage. NVIDIA did not give the documentation to anyone no matter what the business case. VIA doesn't publish documentation on the web, but some coreboot developers do have good relations with them. Over the last couple years Google have hired most of the active coreboot developers including the project founder, and they've been working on support for Intel's Sandy Bridge and Ivy Bridge platforms, which powers the new Chromebook. I do not know how much time they've spent, but from my outside view I estimate that it took this amazing team of engineers between 25 and 30 man-months. This may be a very optimistic estimate. These new Intel platforms require a blob, firmware for a microcontroller in the chipset, which runs while the main CPU is still held in reset, in order to do some early prepararation of the system. The firmware blob is signed by Intel. I don't know if the signature scheme has been broken, I guess it might at some point, but that will likely be by the usual IT security crowd suspects. In Google's coreboot code they are using Intel's reference code for initializing the memory controller. This is so far also a blob, again as opposed to AMD who have released their reference code under dual BSD and GPL license, and although it is theoretically possible to replace this with self-written code that is not really economical. Please look through the SDRAM, DDR and DDR2 self-written init code in coreboot for the various platforms, and then think about the complexity added by DDR3, and I expect that hardware vendors and JEDEC are hard at work on DDR4. Memory controller init involves among other things a brute force search of electrical signal drive strengths to find the correct setting for stable operation. > Linux already has thousands of developers working on hardware support, > including developers from Intel. We should be able to leverage that. Forget about that. Everything that happens on the Linux level is really a different matter. > Did I miss any technical obstacles? PCs have 35 years of hardware legacy. It's quite possibly the worst pile of hardware crap on top of hardware crap you can imagine. It's a feat that anything works at all. You mention 80386, but all PCs still start in real mode, 8086 style. In another five or ten years maybe that will change, and (some) hardware will become much more locked down. But I'm not sure, DOS remains a significant market. Someone said "Intel make the best x86 emulators." and that is spot on. Besides that microcontroller inside your CPU there's of course also the CPU microcode. There are no modern x86 machines. FSF has long considered coreboot a high priority project, because it makes UEFI irrelevant, and it very much puts users in full control, while at the same time being transparent thanks to the open source. They don't do much in terms of contributions though. I can understand that. The way for coreboot to become relevant is to ship from factory. Everyone with experience from the IBV (Independent BIOS Vendor) industry knows what a special marketplace this is. It's very interesting, but don't let anyone tell you that anything is easy. The technical obstacles are the least of the problems. //Peter
