Documentation/getting_started/architecture.md

   1 # coreboot architecture
   2
   3 ## Overview
   4 ![][architecture]
   5
   6 [architecture]: comparison_coreboot_uefi.svg
   7
   8 ## Stages
   9 coreboot consists of multiple stages that are compiled as separate binaries and
  10 are inserted into the CBFS with custom compression. The bootblock usually doesn't
  11 have compression while the ramstage and payload are compressed with LZMA.
  12
  13 Each stage loads the next stage at given address (possibly decompressing it).
  14
  15 Some stages are relocatable and can be placed anywhere in DRAM. Those stages are
  16 usually cached in CBMEM for faster loading times on ACPI S3 resume.
  17
  18 Supported stage compressions:
  19 * none
  20 * LZ4
  21 * LZMA
  22
  23 ## bootblock
  24 The bootblock is the first stage executed after CPU reset. It is written in
  25 assembly language and its main task is to set up everything for a C-environment:
  26
  27 Common tasks:
  28
  29 * Cache-As-RAM for heap and stack
  30 * Set stack pointer
  31 * Clear memory for BSS
  32 * Decompress and load the next stage
  33
  34 On x86 platforms that includes:
  35
  36 * Microcode updates
  37 * Timer init
  38 * Switching from 16-bit real-mode to 32-bit protected mode
  39
  40 The bootblock loads the romstage or the verstage if verified boot is enabled.
  41
  42 ### Cache-As-Ram
  43 The *Cache-As-Ram*, also called Non-Eviction mode, or *CAR* allows to use the
  44 CPU cache like regular SRAM. This is particullary useful for high level
  45 languages like `C`, which need RAM for heap and stack.
  46
  47 The CAR needs to be activated using vendor specific CPU instructions.
  48
  49 The following stages run when Cache-As-Ram is active:
  50 * bootblock
  51 * romstage
  52 * verstage
  53 * postcar
  54
  55 ## verstage
  56 The verstage is where the root-of-trust starts. It's assumed that
  57 it cannot be overwritten in-field (together with the public key) and
  58 it starts at the very beginning of the boot process.
  59 The verstage installs a hook to verify a file before it's loaded from
  60 CBFS or a partition before it's accessed.
  61
  62 The verified boot mechanism allows trusted in-field firmware updates
  63 combined with a fail-safe recovery mode.
  64
  65 ## romstage
  66 The romstage initializes the DRAM and prepares everything for device init.
  67
  68 Common tasks:
  69
  70 * Early device init
  71 * DRAM init
  72
  73 ## postcar
  74 To leave the CAR setup and run code from regular DRAM the postcar-stage tears
  75 down CAR and loads the ramstage. Compared to other stages it's minimal in size.
  76
  77 ## ramstage
  78
  79 The ramstage does the main device init:
  80
  81 * PCI device init
  82 * On-chip device init
  83 * TPM init (if not done by verstage)
  84 * Graphics init (optional)
  85 * CPU init (like set up SMM)
  86
  87 After initialization tables are written to inform the payload or operating system
  88 about the current hardware existence and state. That includes:
  89
  90 * ACPI tables (x86 specific)
  91 * SMBIOS tables (x86 specific)
  92 * coreboot tables
  93 * devicetree updates (ARM specific)
  94
  95 It also does hardware and firmware lockdown:
  96 * Write-protection of boot media
  97 * Lock security related registers
  98 * Lock SMM mode (x86 specific)
  99
 100 ## payload
 101 The payload is the software that is run after coreboot is done. It resides in
 102 the CBFS and there's no possibility to choose it at runtime.
 103
 104 For more details have a look at [payloads](../payloads.md).
 105