Editing Coreboot (section)

== Design ==
Coreboot typically loads a [[Linux kernel]], but it can load any other [[standalone program|stand-alone]] [[Executable and Linkable Format|ELF]] executable, such as [[iPXE]], [[gPXE]] or Etherboot that can boot a Linux kernel [[Network booting|over a network]], or [[SeaBIOS]]<ref>[http://www.coreboot.org/SeaBIOS SeaBIOS] (previously known as LegacyBIOS) is an open-source legacy BIOS implementation</ref> that can load a Linux kernel, [[Windows 2000]] and later, and BSDs; Windows 2000/[[Windows XP|XP]] and [[OpenBSD]] support was previously provided by ADLO.<ref>{{Cite web|url=http://www.coreboot.org/ADLO|archiveurl=https://web.archive.org/web/20101125130605/http://www.coreboot.org/ADLO|url-status=dead|title=coreboot Add-on Layer (ADLO)|archivedate=25 November 2010}}</ref><ref>{{cite web |url=http://www.missl.cs.umd.edu/sebos_phase2.html |title=SEBOS, Security Enhanced Bootloader for Operating Systems, Phase 2 |archive-url=https://web.archive.org/web/20070619101948/http://www.missl.cs.umd.edu/sebos_phase2.html |archive-date=19 June 2007 |url-status=dead}} - adding PC BIOS Services to coreboot via Bochs BIOS</ref> coreboot can also load a [[Kernel (operating system)|kernel]] from any supported device, such as Myrinet, Quadrics, or SCI [[Computer cluster|cluster]] interconnects. Booting other kernels directly is also possible, such as a [[Plan 9 from Bell Labs|Plan 9]] kernel. Instead of loading a kernel directly, coreboot can pass control to a dedicated boot loader, such as a coreboot-capable version of [[GNU GRUB]] 2.

Coreboot is written primarily in [[C (programming language)|C]], with a small amount of [[assembly code]]. Choosing C as the primary programming language enables easier [[code audit]]s when compared to contemporary PC BIOS that was generally written in assembly,<ref>{{cite web |url=https://phoenixts.com/blog/uefi-vs-legacy-bios/ |title=Comparison of UEFI and legacy BIOS}} pronouncing that same advantage for UEFI</ref> which results in improved security. There is build and runtime support to write parts of coreboot in [[Ada (programming language)|Ada]]<ref>{{cite web |url=https://review.coreboot.org/cgit/coreboot.git/commit/src/lib/gnat?id=e0ed9025cf7453212e5e5a845e34e0b7ecfa3eb9 |title=commit}} adding that support</ref> to further raise the security bar, but it is currently only sporadically used. The source code is released under the [[GPL version 2|GNU GPL version 2]] license.

Coreboot performs the absolute minimal amount of hardware initialization and then passes control to the [[operating system]]. As a result, there is no coreboot code running once the operating system has taken control. A feature of coreboot is that the [[x86]] version runs in [[32-bit]] mode after executing only ten instructions<ref>{{Cite web |url=http://lxr.linux.no/coreboot-v3+r777/arch/x86/geodelx/stage0.S |title=coreboot v3 early startup code |access-date=17 August 2008 |archive-url=https://archive.today/20120710041412/http://lxr.linux.no/coreboot-v3+r777/arch/x86/geodelx/stage0.S |archive-date=10 July 2012 |url-status=dead }}</ref> (almost all other x86 BIOSes run exclusively in [[16-bit]] mode). This is similar to the modern [[UEFI]] firmware, which is used on newer PC hardware.

=== Initializing DRAM ===
The most difficult hardware that coreboot initializes is the [[Memory controller|DRAM controller]]s and [[Dynamic random-access memory|DRAM]]. In some cases, technical documentation on this subject is [[Non-disclosure agreement|NDA]] 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's [[Processor register|general purpose registers]] or Cache-as-RAM as temporary storage.

romcc, a [[C (programming language)|C]] [[compiler]] that uses registers instead of RAM, eases the task. Using romcc, it is relatively easy to make [[System Management Bus|SMBus]] accesses to the [[Serial presence detect|SPD]] ROMs of the DRAM [[DIMM]]s, 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<ref>{{cite web |url=http://rere.qmqm.pl/~mirq/cache_as_ram_lb_09142006.pdf |title=CAR: Using Cache as RAM in Linux BIOS |date=15 January 2009 |access-date=25 February 2014 |author1=Yinghai Lu |author2=Li-Ta Lo |author3=Gregory R. Watson |author4=Ronald G. Minnich |publisher=qmqm.pl |archive-url=https://web.archive.org/web/20160303223305/http://rere.qmqm.pl/~mirq/cache_as_ram_lb_09142006.pdf |archive-date=3 March 2016 |url-status=dead }}</ref><ref>{{Cite web|url=http://www.coreboot.org/images/6/6c/LBCar.pdf|title=A Framework for Using Processor Cache as RAM (CAR)}}</ref> 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.<ref>{{cite web|url=https://mail.coreboot.org/pipermail/coreboot/2014-November/078892.html|title=[coreboot] AMD's binary-only AGESA libraries|last=Griffith|first=Bruce|date=5 November 2014|access-date=2019-09-08}}</ref>