Peter, thanks for the detailed email. I have a few questions. 1. As far as I know, Das U-Boot and Core Boot are mutually exclusive. Why should Linux distribution developers want to use Core Boot instead of Das U-Boot? 2. It seems to me that you do not need any Linux code. Exactly what is the relationship between the Core Boot codebase and the Linux codebase? 3. How does getting a x86 system to boot differ from getting a MIPS system or ARM system to boot? Does it only work because the vendors made it work or is x86 fundamentally harder?
On 06/19/2012 11:27 PM, Peter Stuge wrote: > 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 >
