| coreboot | |
|---|---|
 | |
| Original authors | Ronald G. Minnich, Eric Biederman, Li-Ta (Ollie) Lo, Stefan Reinauer, and the coreboot community |
| Initial release | 1999; 26 years ago (1999) |
| Stable release | |
| Repository | |
| Written in | MostlyC, about 1% inassembly and optionallySPARK |
| Platform | IA-32,x86-64,ARMv7,[3] ARMv8,RISC-V, POWER8 |
| Type | Firmware |
| License | GPLv2-only[4] |
| Website | www |
coreboot (formerlyLinuxBIOS)[5] is an open‑source project that provides lightweightfirmware to initialize hardware and then load an operating system. It is designed to replace proprietary firmware (traditionalBIOS orUEFI implementations) by performing the minimal tasks required to start a modern32-bit or64-bitoperating system.
Because coreboot performs low‑level hardware initialization, it must be ported to each supportedchipset andmotherboard model; consequently, availability is limited to platforms for which support has been implemented.
One of the well‑known variants of coreboot isLibreboot, asoftware distribution that focuses on removing proprietarybinary blobs from the firmware stack.
The coreboot project began with the goal of creating a BIOS that boots quickly and handles errors intelligently.[6] It is distributed under the terms of theGNU General Public License version 2 (GPLv2). Main contributors includeLANL,SiS,AMD, Coresystems and Linux Networx, Inc, as well as motherboard vendorsMSI,Gigabyte andTyan, which offer coreboot alongside their standard BIOS or provide specifications of the hardware interfaces for some of their motherboards.Google partly sponsors the coreboot project.[7]CME Group, a financial public company, began supporting the coreboot project in 2009.[8]
Other than the first three models, allChromebooks run coreboot.[9] Code fromDas U-Boot has been assimilated to enable support for processors based on theARM instruction set.[10]
In June 2019, coreboot began to use theNSA softwareGhidra for itsreverse engineering efforts onfirmware-specific problems following the release of the suite asfree and open source software.[11]
coreboot supports multiple CPU architectures, includingIA-32,x86-64,ARM,ARM64,MIPS andRISC-V. Support covers a variety ofsystem-on-a-chip (SoC) platforms as well; early development focused on AMDGeode processors (notably those used in theOLPC project). Artec Group added Geode LX support for itsThinCan model DBE61; that code was adopted by AMD and further improved for the OLPC after it was upgraded to the Geode LX platform, and is further developed by the coreboot community to support other Geode variants. coreboot can be flashed onto a Geode platform usingFlashrom.
From that initial development on AMD Geode based platforms, coreboot support has been extended onto many AMD processors and chipsets. The processor list includes Family 0Fh and 10h (K8 core), and recently Family 14h (Bobcat core,Fusion APU). coreboot support also extends to AMD chipsets:RS690,RS7xx,SB600, and SB8xx.
In AMD Generic Encapsulated Software Architecture (AGESA)—abootstrap protocol by which system devices on AMD64 mainboards are initialized—was open sourced in early 2011, aiming to provide required functionality for coreboot system initialization on AMD64 hardware.[12] However, as of 2014 such releases never became the basis for future development by AMD, and were subsequently halted.[13]
Devices that could be preloaded with coreboot or one of its derivatives include:
Coreboot typically loads aLinux kernel, but it can load any otherstand-aloneELF executable, such asiPXE,gPXE or Etherboot that can boot a Linux kernelover a network, orSeaBIOS[23] that can load a Linux kernel,Windows 2000 and later, and BSDs; Windows 2000/XP andOpenBSD support was previously provided by ADLO.[24][25] coreboot can also load akernel from any supported device, such as Myrinet, Quadrics, or SCIcluster interconnects. Booting other kernels directly is also possible, such as aPlan 9 kernel. Instead of loading a kernel directly, coreboot can pass control to a dedicated boot loader, such as a coreboot-capable version ofGNU GRUB 2.
Coreboot is primarily implemented inC, with a small amount ofassembly code. Choosing C as the primary programming language facilitatescode audits when compared to contemporary PC BIOS that was generally written in assembly,[26] which results in improved security. There is build and runtime support to write parts of coreboot inAda[27] to further raise the security bar, but it is currently only sporadically used. The source code is released under theGNU GPL version 2 license.
Coreboot performs the absolute minimal amount of hardware initialization and then passes control to theoperating system. As a result, there is no coreboot code running once the operating system has taken control. A feature of coreboot is that thex86 version runs in32-bit mode after executing only ten instructions[28] (almost all other x86 BIOSes run exclusively in16-bit mode). This is similar to the modernUEFI firmware, which is used on newer PC hardware.
The most difficult hardware that coreboot initializes is theDRAM controllers andDRAM. In some cases, technical documentation on this subject isNDA restricted or unavailable. RAM initialization is particularly difficult because before the RAM is initialized it cannot be used. Therefore, to initialize DRAM controllers and DRAM, the initialization code may have only the CPU'sgeneral purpose registers or Cache-as-RAM as temporary storage.
romcc, aCcompiler that uses registers instead of RAM, eases the task. Using romcc, it is relatively easy to makeSMBus accesses to theSPD ROMs of the DRAMDIMMs, that allows the RAM to be used.
With newer x86 processors, the processor cache can be used as RAM until DRAM is initialized. The processor cache has to be initialized into Cache-as-RAM[29][30] mode as well, but this needs fewer instructions than initializing DRAM. Also, the Cache-as-RAM mode initialization is specific to CPU architectures, thus more generic than DRAM initialization, which is specific to each chipset and mainboard.
For most modern x86 platforms, closed source binary-only components provided by the vendor are used for DRAM setup. For Intel systems, FSP-M is required, while AMD has no current support. Binary AGESA is currently used for proprietary UEFI firmware on AMD systems, and this model is expected to carry over to any future AMD-related coreboot support.[31]
Developers use a variety of hardware and software debugging tools when working on coreboot. These include in‑circuitemulators,JTAG probes (for example the Sage SmartProbe), and BIOS/firmware emulators. Code may be tested on emulators or downloaded to target hardware rather than being immediately flashed to a BIOS device.[32][33] being an example. Code can be built on, or downloaded to, BIOS emulators rather than flashing the BIOS device.
coreboot loads a payload after hardware initialization. Payloads may be written with thelibpayload helper library or be independent projects. Notable payloads include the following:
One physical meeting is the European Coreboot Conference which was organized in October 2017 and lasted for three days.
| Event and year | Date | Host city | Venue | Resources | Themes |
|---|---|---|---|---|---|
| ECC2017 | 26.10. – 29.10 | Bochum, Germany | RUB Convention Center | https://ecc2017.com |
coreboot has a number of variants from its original code base each with slightly different objectives:.
{{cite web}}: CS1 maint: bot: original URL status unknown (link)
Media related toCoreboot at Wikimedia Commons| Processes |  | ||||||
|---|---|---|---|---|---|---|---|
| Bootingfirmware |
| ||||||
| Hybrid firmware bootloader | |||||||
| Bootloaders |
| ||||||
| Partition layouts | |||||||
| Partitions | |||||||
| Utilities |
| ||||||
| Network boot | |||||||
| ROM variants | |||||||
| Related | |||||||