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