Commit | Line | Data |
---|---|---|
9703d9d7 CM |
1 | Booting AArch64 Linux |
2 | ===================== | |
3 | ||
4 | Author: Will Deacon <will.deacon@arm.com> | |
5 | Date : 07 September 2012 | |
6 | ||
7 | This document is based on the ARM booting document by Russell King and | |
8 | is relevant to all public releases of the AArch64 Linux kernel. | |
9 | ||
10 | The AArch64 exception model is made up of a number of exception levels | |
11 | (EL0 - EL3), with EL0 and EL1 having a secure and a non-secure | |
12 | counterpart. EL2 is the hypervisor level and exists only in non-secure | |
13 | mode. EL3 is the highest priority level and exists only in secure mode. | |
14 | ||
15 | For the purposes of this document, we will use the term `boot loader' | |
16 | simply to define all software that executes on the CPU(s) before control | |
17 | is passed to the Linux kernel. This may include secure monitor and | |
18 | hypervisor code, or it may just be a handful of instructions for | |
19 | preparing a minimal boot environment. | |
20 | ||
21 | Essentially, the boot loader should provide (as a minimum) the | |
22 | following: | |
23 | ||
24 | 1. Setup and initialise the RAM | |
25 | 2. Setup the device tree | |
26 | 3. Decompress the kernel image | |
27 | 4. Call the kernel image | |
28 | ||
29 | ||
30 | 1. Setup and initialise RAM | |
31 | --------------------------- | |
32 | ||
33 | Requirement: MANDATORY | |
34 | ||
35 | The boot loader is expected to find and initialise all RAM that the | |
36 | kernel will use for volatile data storage in the system. It performs | |
37 | this in a machine dependent manner. (It may use internal algorithms | |
38 | to automatically locate and size all RAM, or it may use knowledge of | |
39 | the RAM in the machine, or any other method the boot loader designer | |
40 | sees fit.) | |
41 | ||
42 | ||
43 | 2. Setup the device tree | |
44 | ------------------------- | |
45 | ||
46 | Requirement: MANDATORY | |
47 | ||
61bd93ce AB |
48 | The device tree blob (dtb) must be placed on an 8-byte boundary and must |
49 | not exceed 2 megabytes in size. Since the dtb will be mapped cacheable | |
50 | using blocks of up to 2 megabytes in size, it must not be placed within | |
51 | any 2M region which must be mapped with any specific attributes. | |
9703d9d7 | 52 | |
61bd93ce AB |
53 | NOTE: versions prior to v4.2 also require that the DTB be placed within |
54 | the 512 MB region starting at text_offset bytes below the kernel Image. | |
9703d9d7 CM |
55 | |
56 | 3. Decompress the kernel image | |
57 | ------------------------------ | |
58 | ||
59 | Requirement: OPTIONAL | |
60 | ||
61 | The AArch64 kernel does not currently provide a decompressor and | |
62 | therefore requires decompression (gzip etc.) to be performed by the boot | |
63 | loader if a compressed Image target (e.g. Image.gz) is used. For | |
64 | bootloaders that do not implement this requirement, the uncompressed | |
65 | Image target is available instead. | |
66 | ||
67 | ||
68 | 4. Call the kernel image | |
69 | ------------------------ | |
70 | ||
71 | Requirement: MANDATORY | |
72 | ||
4370eec0 | 73 | The decompressed kernel image contains a 64-byte header as follows: |
9703d9d7 | 74 | |
4370eec0 RF |
75 | u32 code0; /* Executable code */ |
76 | u32 code1; /* Executable code */ | |
a2c1d73b MR |
77 | u64 text_offset; /* Image load offset, little endian */ |
78 | u64 image_size; /* Effective Image size, little endian */ | |
79 | u64 flags; /* kernel flags, little endian */ | |
9703d9d7 | 80 | u64 res2 = 0; /* reserved */ |
4370eec0 RF |
81 | u64 res3 = 0; /* reserved */ |
82 | u64 res4 = 0; /* reserved */ | |
83 | u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */ | |
6c020ea8 | 84 | u32 res5; /* reserved (used for PE COFF offset) */ |
4370eec0 RF |
85 | |
86 | ||
87 | Header notes: | |
88 | ||
a2c1d73b MR |
89 | - As of v3.17, all fields are little endian unless stated otherwise. |
90 | ||
4370eec0 | 91 | - code0/code1 are responsible for branching to stext. |
a2c1d73b | 92 | |
cdd78578 MS |
93 | - when booting through EFI, code0/code1 are initially skipped. |
94 | res5 is an offset to the PE header and the PE header has the EFI | |
a2c1d73b | 95 | entry point (efi_stub_entry). When the stub has done its work, it |
cdd78578 | 96 | jumps to code0 to resume the normal boot process. |
9703d9d7 | 97 | |
a2c1d73b MR |
98 | - Prior to v3.17, the endianness of text_offset was not specified. In |
99 | these cases image_size is zero and text_offset is 0x80000 in the | |
100 | endianness of the kernel. Where image_size is non-zero image_size is | |
101 | little-endian and must be respected. Where image_size is zero, | |
102 | text_offset can be assumed to be 0x80000. | |
103 | ||
104 | - The flags field (introduced in v3.17) is a little-endian 64-bit field | |
105 | composed as follows: | |
6c020ea8 | 106 | Bit 0: Kernel endianness. 1 if BE, 0 if LE. |
9d372c9f AB |
107 | Bit 1-2: Kernel Page size. |
108 | 0 - Unspecified. | |
109 | 1 - 4K | |
110 | 2 - 16K | |
111 | 3 - 64K | |
a7f8de16 AB |
112 | Bit 3: Kernel physical placement |
113 | 0 - 2MB aligned base should be as close as possible | |
114 | to the base of DRAM, since memory below it is not | |
115 | accessible via the linear mapping | |
116 | 1 - 2MB aligned base may be anywhere in physical | |
117 | memory | |
118 | Bits 4-63: Reserved. | |
a2c1d73b MR |
119 | |
120 | - When image_size is zero, a bootloader should attempt to keep as much | |
121 | memory as possible free for use by the kernel immediately after the | |
122 | end of the kernel image. The amount of space required will vary | |
123 | depending on selected features, and is effectively unbound. | |
124 | ||
125 | The Image must be placed text_offset bytes from a 2MB aligned base | |
a7f8de16 AB |
126 | address anywhere in usable system RAM and called there. The region |
127 | between the 2 MB aligned base address and the start of the image has no | |
128 | special significance to the kernel, and may be used for other purposes. | |
a2c1d73b MR |
129 | At least image_size bytes from the start of the image must be free for |
130 | use by the kernel. | |
a7f8de16 AB |
131 | NOTE: versions prior to v4.6 cannot make use of memory below the |
132 | physical offset of the Image so it is recommended that the Image be | |
133 | placed as close as possible to the start of system RAM. | |
a2c1d73b | 134 | |
6c020ea8 AB |
135 | Any memory described to the kernel (even that below the start of the |
136 | image) which is not marked as reserved from the kernel (e.g., with a | |
a2c1d73b MR |
137 | memreserve region in the device tree) will be considered as available to |
138 | the kernel. | |
9703d9d7 CM |
139 | |
140 | Before jumping into the kernel, the following conditions must be met: | |
141 | ||
142 | - Quiesce all DMA capable devices so that memory does not get | |
143 | corrupted by bogus network packets or disk data. This will save | |
144 | you many hours of debug. | |
145 | ||
146 | - Primary CPU general-purpose register settings | |
147 | x0 = physical address of device tree blob (dtb) in system RAM. | |
148 | x1 = 0 (reserved for future use) | |
149 | x2 = 0 (reserved for future use) | |
150 | x3 = 0 (reserved for future use) | |
151 | ||
152 | - CPU mode | |
153 | All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, | |
154 | IRQ and FIQ). | |
155 | The CPU must be in either EL2 (RECOMMENDED in order to have access to | |
156 | the virtualisation extensions) or non-secure EL1. | |
157 | ||
158 | - Caches, MMUs | |
159 | The MMU must be off. | |
160 | Instruction cache may be on or off. | |
c218bca7 CM |
161 | The address range corresponding to the loaded kernel image must be |
162 | cleaned to the PoC. In the presence of a system cache or other | |
163 | coherent masters with caches enabled, this will typically require | |
164 | cache maintenance by VA rather than set/way operations. | |
165 | System caches which respect the architected cache maintenance by VA | |
166 | operations must be configured and may be enabled. | |
167 | System caches which do not respect architected cache maintenance by VA | |
168 | operations (not recommended) must be configured and disabled. | |
9703d9d7 CM |
169 | |
170 | - Architected timers | |
4fcd6e14 MR |
171 | CNTFRQ must be programmed with the timer frequency and CNTVOFF must |
172 | be programmed with a consistent value on all CPUs. If entering the | |
173 | kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where | |
174 | available. | |
9703d9d7 CM |
175 | |
176 | - Coherency | |
177 | All CPUs to be booted by the kernel must be part of the same coherency | |
178 | domain on entry to the kernel. This may require IMPLEMENTATION DEFINED | |
179 | initialisation to enable the receiving of maintenance operations on | |
180 | each CPU. | |
181 | ||
182 | - System registers | |
183 | All writable architected system registers at the exception level where | |
184 | the kernel image will be entered must be initialised by software at a | |
185 | higher exception level to prevent execution in an UNKNOWN state. | |
186 | ||
6d32ab2d | 187 | For systems with a GICv3 interrupt controller to be used in v3 mode: |
63f8344c MZ |
188 | - If EL3 is present: |
189 | ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1. | |
190 | ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1. | |
191 | - If the kernel is entered at EL1: | |
192 | ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1 | |
193 | ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1. | |
6d32ab2d MZ |
194 | - The DT or ACPI tables must describe a GICv3 interrupt controller. |
195 | ||
196 | For systems with a GICv3 interrupt controller to be used in | |
197 | compatibility (v2) mode: | |
198 | - If EL3 is present: | |
199 | ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b0. | |
200 | - If the kernel is entered at EL1: | |
201 | ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b0. | |
202 | - The DT or ACPI tables must describe a GICv2 interrupt controller. | |
63f8344c | 203 | |
4fcd6e14 MR |
204 | The requirements described above for CPU mode, caches, MMUs, architected |
205 | timers, coherency and system registers apply to all CPUs. All CPUs must | |
206 | enter the kernel in the same exception level. | |
207 | ||
9703d9d7 CM |
208 | The boot loader is expected to enter the kernel on each CPU in the |
209 | following manner: | |
210 | ||
211 | - The primary CPU must jump directly to the first instruction of the | |
212 | kernel image. The device tree blob passed by this CPU must contain | |
4fcd6e14 MR |
213 | an 'enable-method' property for each cpu node. The supported |
214 | enable-methods are described below. | |
9703d9d7 CM |
215 | |
216 | It is expected that the bootloader will generate these device tree | |
217 | properties and insert them into the blob prior to kernel entry. | |
218 | ||
4fcd6e14 MR |
219 | - CPUs with a "spin-table" enable-method must have a 'cpu-release-addr' |
220 | property in their cpu node. This property identifies a | |
221 | naturally-aligned 64-bit zero-initalised memory location. | |
222 | ||
223 | These CPUs should spin outside of the kernel in a reserved area of | |
224 | memory (communicated to the kernel by a /memreserve/ region in the | |
9703d9d7 CM |
225 | device tree) polling their cpu-release-addr location, which must be |
226 | contained in the reserved region. A wfe instruction may be inserted | |
227 | to reduce the overhead of the busy-loop and a sev will be issued by | |
228 | the primary CPU. When a read of the location pointed to by the | |
4fcd6e14 MR |
229 | cpu-release-addr returns a non-zero value, the CPU must jump to this |
230 | value. The value will be written as a single 64-bit little-endian | |
231 | value, so CPUs must convert the read value to their native endianness | |
232 | before jumping to it. | |
233 | ||
234 | - CPUs with a "psci" enable method should remain outside of | |
235 | the kernel (i.e. outside of the regions of memory described to the | |
236 | kernel in the memory node, or in a reserved area of memory described | |
237 | to the kernel by a /memreserve/ region in the device tree). The | |
238 | kernel will issue CPU_ON calls as described in ARM document number ARM | |
239 | DEN 0022A ("Power State Coordination Interface System Software on ARM | |
240 | processors") to bring CPUs into the kernel. | |
241 | ||
242 | The device tree should contain a 'psci' node, as described in | |
243 | Documentation/devicetree/bindings/arm/psci.txt. | |
9703d9d7 CM |
244 | |
245 | - Secondary CPU general-purpose register settings | |
246 | x0 = 0 (reserved for future use) | |
247 | x1 = 0 (reserved for future use) | |
248 | x2 = 0 (reserved for future use) | |
249 | x3 = 0 (reserved for future use) |