Documentation is now handled by the same processes we use for code: Add something to the Documentation/ directory in the coreboot repo, and it will be rendered to https://doc.coreboot.org/. Contributions welcome!
coreboot (formerly known as LinuxBIOS) is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today's computers.
It performs just a little bit of hardware initialization and then executes what is called a payload.
Some of the many possible payloads are: a Linux kernel, FILO (a GRUB-like bootloader for booting from disk), GRUB2, Open Firmware, Etherboot/GPXE, SeaBIOS (for booting Windows XP, Windows Vista, Windows 7, NetBSD and Linux), and many others.
The initial motivation for the project was maintenance of large clusters, but unsurprisingly, interest and contributions have come from people with varying backgrounds. The latest version of coreboot can be used in a wide variety of scenarios including clusters, embedded systems, desktop PCs, servers, and more.
For more information, see History.
Current PCs used as cluster nodes depend on a vendor-supplied BIOS for booting. The BIOS in turn relies on inherently unreliable devices such as floppy disks and hard drives to boot the operating system. In addition, current BIOS software is unable to accommodate non-standard hardware making it difficult to support experimental work. The BIOS is slow and often erroneous and redundant and, most importantly, maintenance is a nightmare. Imagine walking around with a keyboard and monitor to every one of the 128 nodes in a cluster to change one BIOS setting.
coreboot with Linux as a payload (other payloads are possible!) gunzip's the Linux kernel straight out of NVRAM and essentially requires no moving parts other than the CPU fan. It does a minimal amount of hardware initialization before jumping to the kernel start and lets Linux do the rest. As a result, it is much faster (current record: 3 seconds), which has sparked interest in the consumer electronics community as well. Moreover, updates can be performed over the network.
Using a real operating system to boot another operating system provides much greater flexibility than using a simple netboot program or the BIOS. Because Linux is the boot mechanism, it can boot over standard Ethernet or over other interconnects such as Myrinet, Quadrics, or SCI. It can use SSH connections to load the kernel, or it can use the InterMezzo caching file system or traditional NFS. Cluster nodes can be as simple as they need to be — perhaps as simple as a CPU and memory, no disk, no floppy, and no file system. The nodes will be much less autonomous thus making them easier to maintain.
Some aspects of DRM are not travelling well with the idea of a free computer system. As many computer magazines already pointed out, there may be future restrictions imposed by BIOSes, that a customer is little aware of before purchase and might not harmonize with the idea of freedom and/or security in some cases.
The coreboot project was started in the winter of 1999 in the Advanced Computing Laboratory at Los Alamos National Laboratory (LANL) by Ron Minnich. Two undergraduate students, James Hendricks and Dale Webster spent their winter vacation putting together the proof of concept implementation.
Since then, a long list of people have contributed both in discussions and actual code. Please don't be shy and let us know if you are missing from the list. It's not a purposeful omission, just an unfortunate mistake.
The coreboot project was initially funded by the Los Alamos Computer Science Institute and the Department of Energy's Office of Science.
See also the list of coreboot sponsors.
See the Supported Motherboards page for which mainboards are supported, and also the list of Supported Chipsets and Devices. See the Products page for a list of vendors selling products running coreboot. Finally, you could look at the coreboot source tree, in src/mainboard.
If your board is not already supported, it will likely take you years of work to port coreboot to operate correctly on it unless you have experience with firmware level C development and good knowledge of the underlying (x86 or ARM) architecture.
If you do not see your board in the above sources, please send the following to the mailing list:
If you can't do step 1 above, please describe (as best you can) the specific CPU chip and the chipset used on the mainboard.
Usually in less than a day, someone will respond on the coreboot mailing list, most often with bad news. However it is possible that your mainboard is supported in the main coreboot source tree, or that support is currently in development, so it won't hurt to ask. It's also possible (and unfortunately, likely) that the manufacturer will not release information needed to provide coreboot support. In the latter case, please let the manufacturer know that you want coreboot support and his failure to release chipset information is making that very difficult.
See the products page.
coreboot should support almost any modern operating system. To support operating systems that use BIOS calls, SeaBIOS is mandantory, as coreboot doesn't provide these by itself:
coreboot does not natively support:
Please feel free to test booting any of the above using SeaBIOS and report to the coreboot mailing list.
See the Supported Chipsets and Devices page.
See Mailinglist.
Yes, see IRC.
See the download page.
See the Build HOWTO.
There are many ways how you can help us:
See Glossary.
Of course.
The current performance coreboot compatible x86-64 motherboard is the KGPE-D16 which has dual PCI-e x16 2.0 slots, 192GB max RAM and can support fast CPU's such as the G34 16 core Opteron 6386SE, 6287SE and 6284SE - with one of those the bottleneck will be always be GPU related if you are playing a highly multi-threaded game.
If you aren't using the computer for something very important you can save a lot of money and have an affordable libre firmware gaming platform by getting a used CPU. You can even use IOMMU-GFX to have multiple separate VM's and thus have more than one player on the same machine (needs one gfx card per VM)
If you do not want to have to buy an SSI-EEB compatable case there is also the KCMA-D8 which is the KGPE-D16's regular ATX little brother, although the CPU's max out at 8 cores per and there aren't as many PCI-e slots (no dual x16 so no crossfire).
NOTE: game needs to be highly multithreaded due to poor c32/g34 opteron single threaded performance, having half core turbo functional helps with this. Thus brand new and old games work great but games from 3-6 years ago may work poorly.
Opteron C32/G34 CPU's to buy for gaming:
G34 16 core: 6386SE 6287SE 6284SE
G34 8 Core: 6328 (approx FX-8310)
C32 8 Core 4386
Note: On multi CPU or 16 core setups you will have poor performance and stuttering if your OS does not properly allocate NUMA memory.
When developing or simply trying out coreboot you always need a means to revert to your old BIOS in case something goes wrong. One way to do this is to get an extra BIOS chip (PLCC32, DIP32, DIP8, or other) and copy your original BIOS image onto that chip (using flashrom, for example). If you have a socketed BIOS (not soldered onto the mainboard), you can hot-swap the chips while your computer is running (Do not hot swap with your hands - You must use an insulated chip removal tool to avoid a short-circuit)
You have several options to get spare BIOS chips:
See the hardware tools section of the developer's manual.
$ minicom -s -> Serial port setup -> Press A and enter your COM device (ttyS0 or ttyS1 or ttyUSB0, depending on your COM port) -> Press E and choose "115200 8N1" (default) -> Disable Hardware and Software Flow Control (via F and G) -> Press enter to leave the menu -> Save setup as.. -> Enter "lb" -> Exit from minicom
$ minicom -o lb
As much documentation as you can possibly get your hands on. At minimum, you will need the docs for the chipset.
There have been reports of people getting coreboot working by booting with the OEM BIOS. Then, they would read the static contents of the PCI config registers after boot. coreboot is then built to match the static contents read from the PCI config registers.
The problem with this approach is that chipsets generally require dynamic vs static configuration values during their initialization. The configuration register contents will change from one stage of initialization to the next. Since the contents of the registers read is only the final state of the configuration registers, the chipset won't be properly initialized if these are the only configuration values used.
Getting a mainboard up without chipset docs can be a very long and involved process.
If the documentation for your chipset covered by a NDA with no source release agreement, you won't be able to release your code back to the coreboot project in general, or you will violate the GPL. Many vendors accept releasing the source code, produced after reading such specs, while they don't allow the specs themselves to be revealed. Also, you can offer them the opportunity to review your code, before releasing it to the public.
The reason is the complexity of the problem. We support a lot of hardware, and a given chip on a given board will most likely not be configured quite the same as the same chip on some other board. To help make code navigation easier, pick a target and build that target. Then, in the build directory, type make tags or make etags to get your favorite tags file.
Please carefully read the Development Guidelines for more information.
Please see [1].
If the BIOS chip is socketed, it can be removed and flashed in a rom/flash burner and quickly re-installed.
You have the option of using the external programmers supported by flashrom or some other external programmer which comes with its own software. Depending on the flash chip type, various options exist. For older parallel flash chips, some of these burners cost $700 and more plus they complete a flash in 30 seconds (like the Conitec Galep V), but if you are willing to wait 5 minutes for a flash and manually set DIP switches, the Enhanced Willem Universal Programmer will do the job for only $40-60 USD. There are several models of the Willem Programmer, each supporting many chips, but not all, so be sure to get one that supports your BIOS chip. You could also use the Paraflasher which is a really low-cost programmer with parts sold for $20 or less. The flashrom wiki has a list of hardware you can use for programming.
If your chip is PLCC, you will also need the push pin trick or a PLCC chip extractor/puller or just thread nylon string under the PLCC chip from corner to corner and yank up it straight up. Read more about chip extraction in the developer manual.
Download the appropriate flash update utility. Build the coreboot image as explained above and use the flash update utility to update the BIOS. Be warned that not all update utilities allow you to load your own BIOS image. NOTE: Many vendor specific flash utilities refuse to write "foreign" BIOS images, such as coreboot.
Therefore we suggest that you use the universal flash utility called flashrom which was developed and improved by many coreboot developers, and it works under Linux/*BSD/MacOSX/Solaris/DOS.
Example:
bash$ sudo ./flashrom -V flashrom v0.9.2-r1000 on Linux 2.6.34-rc7-git5 (x86_64), built with libpci 3.1.7, GCC 4.4.3 flashrom is free software, get the source code at http://www.flashrom.org No coreboot table found. Found chipset "Intel ICH9", enabling flash write... OK. This chipset supports the following protocols: FWH,SPI. Calibrating delay loop... 663M loops per second, 100 myus = 199 us. OK. Found chip "Winbond W25x80" (1024 KB, SPI) at physical address 0xfff00000. No operations were specified.
Alternatively you could either use the DOS uniflash utility, or use its source code, which is also available for download from the uniflash site (in Turbo Pascal 7) as a reference for adding support for your flash chip to flashrom. Uniflash supports a lot of different flash chips, and chip interfaces, but so far SPI support is only present in flashrom. You can use flashrom and uniflash for PCI expansion card flashing, such as on RTL8139 Ethernet card (32pin DIL), which allows flashing of your BIOS chip on the NIC if manufacturer provides the circuitry. Please note that flashrom and uniflash support different cards and you should check which utility supports the programmer hardware you own.
Another tool which runs in linux is ctflasher, but it is not maintained anymore and might not work with current Linux kernels.
There are some posts about the BIOS Savior RD1 that suggest its integrated flash device is of low quality; it may take 10 or more flash programming attempts to get a good update to the RD1 flash device. As a result, the following steps have proven to be successful while using the RD1:
The RD1 has been used in the above fashion with great success on the Tyan S2885 mainboard. Unfortunately the RD1 does not work on the nVidia CK8-04 CRB mainboard. The CK8-04 CRB may require a flash device that the RD1 does not support.
The RD1 has worked well as a "do nothing" adapter that allows swapping the BIOS flash device between a flash burner and a mainboard without any wear to the mainboard's BIOS socket.
Any time you stick your hand into an open machine while the power is on, you're risking life and limb. That said, there are also some other not-so-nice things that can happen if you mess up (not that we would know).
remember: make sure your important data is on a disconnected drive while you experiment.
ESD can damage disk drives, boards, DoC's and other parts. The majority of the time, ESD events cause the component to degrade, but not fail testing procedures, resulting in failure at a later date. Because components do not fail immediately, technicians often underestimate the cost of not using ESD prevention measures. Provide at minimum some ESD protection by wearing an antistatic wrist strap attached to the chassis ground on your system when handling parts.
Always handle boards carefully. They can be extremely sensitive to ESD. Hold boards only by their edges. After removing a board from its protective wrapper or from the system, place it component side up on a grounded, static free surface. Use a conductive foam pad if available. Do not slide the board over any surface.
To further reduce the chances of ESD, you should create an ESD safe workstation that includes at minimum:
The idea is to ensure that all components you are going to interact with have the same charge. By connecting everything to the computer case, you ensure that the components of the case, the chair, and your body all have the same charge. If every object has the same charge, the electrons will not jump from one object to another minimizing the risk of ESD damage.
There's a good description of the BIOS implementation of the PIRQ in the red PCI book, and here's a description of the $PIR data structure.
coreboot saves the $PIR data structure between 0xf0000 & 0x100000. Search for $PIR and then save it before copying over the BIOS.
See also the ADLO README for more information.
Note from Ron: I have edited this somewhat to remove Geode-specific items.
Christer Weinigel writes:
To: rminnich@lanl.gov
Cc: linuxbios@lanl.gov
Subject: Re: LinuxBIOS + Etherboot HOWTO?
I had some trouble using LinuxBIOS + etherboot...
My bad, I messed up and used mkelfImage-1.6 that I got from ftp.lnxi.com, when I realized that I ought to use the one from freebios/util everything started working.
Here's what I did to get LinuxBIOS + Etherboot loading and booting a Linux kernel using TFTP.
/Christer
Get etherboot-5.0 from the CVS tree on etherboot.sourceforge.net.
Modify etherboot-5.0/src/Config, comment out:
# BIOS select don't change unless you know what you are doing
#CFLAGS32+= -DPCBIOS
and uncomment the following:
# Options to make a version of Etherboot that will work under linuxBIOS.
CFLAGS32+= -DLINUXBIOS -DCONFIG_TSC_CURRTICKS -DCONSOLE_SERIAL \
-DCOMCONSOLE=0x3f8 -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE
Compile Etherboot to make an elf file for your ethernet card:
make bin32/natsemi.elf
Compile and install mkelfImage from freebios/util/mkelfImage.
Create a bootimage to put on your TFTP server:
mkelfImage --command-line="root=/dev/hda2 console=ttyS0,38400" \
--kernel vmlinux -o /tftpboot/kernel
Finally, make sure that your BOOT/DCHP server is answering and that the TFTP server is active.
Tell LinuxBIOS to boot an elf Image, and tell LinuxBIOS where it is:
option USE_ELF_BOOT=1
I have placed natsemi.elf in the first 64k of my BIOS flash chip, and LinuxBIOS in the second 64k.
insmod bios.o
dd if=natsemi.elf of=/dev/bios bs=64k
dd if=linuxbios.rom of=/dev/bios bs=64k seek=1
Finally boot LinuxBIOS.
There is no Geode graphics support in coreboot. Install the Geode framebuffer driver for console graphics and the X driver for X support on your Geode Linux image. Current kernel and X distributions contain the required drivers. Until the driver loads there is only serial console output.
Driver source:
2.6.23 kernel framebuffer driver
Please read the testbios FAQ.
If you see this error, you have to install iasl, Intel's ASL Optimizing Compiler:
This might be useful in some situations, and to output a number to a POST card:
printf "\001" | dd bs=1 seek=128 of=/dev/port
or using iotools:
iotools io_write8 0x80 0x42
In case of linux commands above do output to POST card, but the value is immediately replaced by 0x00 due to io_delay. Further explanations can be found on kernel mailinglist archive
In DOS (not Windows XP) use:
mov al, 42; out al, 80h
To output 42 type
o 80 42
in DOS debug.exe.
When using LPT (parallel port) POST card - write to port assigned to parallel port, eg. 0x3BC, 0x378, 0x278. Some SuperIOs/EmbeddedControllers will decode 0x80 like ENE KB926
And if yes, can they be modified?
Answer: Yes, coreboot is applying microcode patches on AMD and Intel CPUs. However, this field is little documented, so coreboot uses only unmodified, vendor-provided microcode. Few people think, that system design can seriously be improved by modifications here ( �Code patches mostly disable erraneous functions and opcodes).
Note: If you are following these instructions to build coreboot for your motherboard, this is only necessary if you have a motherboard with an embedded VGA card. If your VGA is a PCI / PCI-Express add-on card, coreboot will find and run the ROM by itself.
See VGA_support for the details.
There are 8 dynamic MTRRs available on x86.
This message tells you that there's an error with PCI device resources.
It might be an error in the PCI handling code or the devicetree.
Short answer: NO.
Long answer:
There's little use in doing that, as a lots of initialization has already been done by the proprietary BIOS (or coreboot) by the time the PCI expansion ROM is executed. It won't be possible to run coreboot from a PCI expansion ROM after a proprietary BIOS has already been running for instance.
Note: The Intel ICH7 southbridge seems to allows booting from PCI ROMs (not arbitrary PCI expansion ROMs as used on graphics cards, SCSI controllers, etc.) -- maybe this should be investigated in order to check if or how it might be useful.
Please see FAQ/Obsolete for (probably) obsolete FAQ items.