]>
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 | ||
48 | The device tree blob (dtb) must be no bigger than 2 megabytes in size | |
49 | and placed at a 2-megabyte boundary within the first 512 megabytes from | |
50 | the start of the kernel image. This is to allow the kernel to map the | |
51 | blob using a single section mapping in the initial page tables. | |
52 | ||
53 | ||
54 | 3. Decompress the kernel image | |
55 | ------------------------------ | |
56 | ||
57 | Requirement: OPTIONAL | |
58 | ||
59 | The AArch64 kernel does not currently provide a decompressor and | |
60 | therefore requires decompression (gzip etc.) to be performed by the boot | |
61 | loader if a compressed Image target (e.g. Image.gz) is used. For | |
62 | bootloaders that do not implement this requirement, the uncompressed | |
63 | Image target is available instead. | |
64 | ||
65 | ||
66 | 4. Call the kernel image | |
67 | ------------------------ | |
68 | ||
69 | Requirement: MANDATORY | |
70 | ||
71 | The decompressed kernel image contains a 32-byte header as follows: | |
72 | ||
73 | u32 magic = 0x14000008; /* branch to stext, little-endian */ | |
74 | u32 res0 = 0; /* reserved */ | |
75 | u64 text_offset; /* Image load offset */ | |
76 | u64 res1 = 0; /* reserved */ | |
77 | u64 res2 = 0; /* reserved */ | |
78 | ||
79 | The image must be placed at the specified offset (currently 0x80000) | |
80 | from the start of the system RAM and called there. The start of the | |
81 | system RAM must be aligned to 2MB. | |
82 | ||
83 | Before jumping into the kernel, the following conditions must be met: | |
84 | ||
85 | - Quiesce all DMA capable devices so that memory does not get | |
86 | corrupted by bogus network packets or disk data. This will save | |
87 | you many hours of debug. | |
88 | ||
89 | - Primary CPU general-purpose register settings | |
90 | x0 = physical address of device tree blob (dtb) in system RAM. | |
91 | x1 = 0 (reserved for future use) | |
92 | x2 = 0 (reserved for future use) | |
93 | x3 = 0 (reserved for future use) | |
94 | ||
95 | - CPU mode | |
96 | All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, | |
97 | IRQ and FIQ). | |
98 | The CPU must be in either EL2 (RECOMMENDED in order to have access to | |
99 | the virtualisation extensions) or non-secure EL1. | |
100 | ||
101 | - Caches, MMUs | |
102 | The MMU must be off. | |
103 | Instruction cache may be on or off. | |
104 | Data cache must be off and invalidated. | |
105 | External caches (if present) must be configured and disabled. | |
106 | ||
107 | - Architected timers | |
108 | CNTFRQ must be programmed with the timer frequency. | |
109 | If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) | |
110 | set where available. | |
111 | ||
112 | - Coherency | |
113 | All CPUs to be booted by the kernel must be part of the same coherency | |
114 | domain on entry to the kernel. This may require IMPLEMENTATION DEFINED | |
115 | initialisation to enable the receiving of maintenance operations on | |
116 | each CPU. | |
117 | ||
118 | - System registers | |
119 | All writable architected system registers at the exception level where | |
120 | the kernel image will be entered must be initialised by software at a | |
121 | higher exception level to prevent execution in an UNKNOWN state. | |
122 | ||
123 | The boot loader is expected to enter the kernel on each CPU in the | |
124 | following manner: | |
125 | ||
126 | - The primary CPU must jump directly to the first instruction of the | |
127 | kernel image. The device tree blob passed by this CPU must contain | |
128 | for each CPU node: | |
129 | ||
130 | 1. An 'enable-method' property. Currently, the only supported value | |
131 | for this field is the string "spin-table". | |
132 | ||
133 | 2. A 'cpu-release-addr' property identifying a 64-bit, | |
134 | zero-initialised memory location. | |
135 | ||
136 | It is expected that the bootloader will generate these device tree | |
137 | properties and insert them into the blob prior to kernel entry. | |
138 | ||
139 | - Any secondary CPUs must spin outside of the kernel in a reserved area | |
140 | of memory (communicated to the kernel by a /memreserve/ region in the | |
141 | device tree) polling their cpu-release-addr location, which must be | |
142 | contained in the reserved region. A wfe instruction may be inserted | |
143 | to reduce the overhead of the busy-loop and a sev will be issued by | |
144 | the primary CPU. When a read of the location pointed to by the | |
145 | cpu-release-addr returns a non-zero value, the CPU must jump directly | |
146 | to this value. | |
147 | ||
148 | - Secondary CPU general-purpose register settings | |
149 | x0 = 0 (reserved for future use) | |
150 | x1 = 0 (reserved for future use) | |
151 | x2 = 0 (reserved for future use) | |
152 | x3 = 0 (reserved for future use) |