diff options
Diffstat (limited to 'Documentation/arm64')
-rw-r--r-- | Documentation/arm64/booting.txt | 152 | ||||
-rw-r--r-- | Documentation/arm64/memory.txt | 73 |
2 files changed, 225 insertions, 0 deletions
diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt new file mode 100644 index 000000000000..9c4d388daddc --- /dev/null +++ b/Documentation/arm64/booting.txt | |||
@@ -0,0 +1,152 @@ | |||
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) | ||
diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt new file mode 100644 index 000000000000..dbbdcbba75a3 --- /dev/null +++ b/Documentation/arm64/memory.txt | |||
@@ -0,0 +1,73 @@ | |||
1 | Memory Layout on AArch64 Linux | ||
2 | ============================== | ||
3 | |||
4 | Author: Catalin Marinas <catalin.marinas@arm.com> | ||
5 | Date : 20 February 2012 | ||
6 | |||
7 | This document describes the virtual memory layout used by the AArch64 | ||
8 | Linux kernel. The architecture allows up to 4 levels of translation | ||
9 | tables with a 4KB page size and up to 3 levels with a 64KB page size. | ||
10 | |||
11 | AArch64 Linux uses 3 levels of translation tables with the 4KB page | ||
12 | configuration, allowing 39-bit (512GB) virtual addresses for both user | ||
13 | and kernel. With 64KB pages, only 2 levels of translation tables are | ||
14 | used but the memory layout is the same. | ||
15 | |||
16 | User addresses have bits 63:39 set to 0 while the kernel addresses have | ||
17 | the same bits set to 1. TTBRx selection is given by bit 63 of the | ||
18 | virtual address. The swapper_pg_dir contains only kernel (global) | ||
19 | mappings while the user pgd contains only user (non-global) mappings. | ||
20 | The swapper_pgd_dir address is written to TTBR1 and never written to | ||
21 | TTBR0. | ||
22 | |||
23 | |||
24 | AArch64 Linux memory layout: | ||
25 | |||
26 | Start End Size Use | ||
27 | ----------------------------------------------------------------------- | ||
28 | 0000000000000000 0000007fffffffff 512GB user | ||
29 | |||
30 | ffffff8000000000 ffffffbbfffcffff ~240GB vmalloc | ||
31 | |||
32 | ffffffbbfffd0000 ffffffbcfffdffff 64KB [guard page] | ||
33 | |||
34 | ffffffbbfffe0000 ffffffbcfffeffff 64KB PCI I/O space | ||
35 | |||
36 | ffffffbbffff0000 ffffffbcffffffff 64KB [guard page] | ||
37 | |||
38 | ffffffbc00000000 ffffffbdffffffff 8GB vmemmap | ||
39 | |||
40 | ffffffbe00000000 ffffffbffbffffff ~8GB [guard, future vmmemap] | ||
41 | |||
42 | ffffffbffc000000 ffffffbfffffffff 64MB modules | ||
43 | |||
44 | ffffffc000000000 ffffffffffffffff 256GB memory | ||
45 | |||
46 | |||
47 | Translation table lookup with 4KB pages: | ||
48 | |||
49 | +--------+--------+--------+--------+--------+--------+--------+--------+ | ||
50 | |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0| | ||
51 | +--------+--------+--------+--------+--------+--------+--------+--------+ | ||
52 | | | | | | | | ||
53 | | | | | | v | ||
54 | | | | | | [11:0] in-page offset | ||
55 | | | | | +-> [20:12] L3 index | ||
56 | | | | +-----------> [29:21] L2 index | ||
57 | | | +---------------------> [38:30] L1 index | ||
58 | | +-------------------------------> [47:39] L0 index (not used) | ||
59 | +-------------------------------------------------> [63] TTBR0/1 | ||
60 | |||
61 | |||
62 | Translation table lookup with 64KB pages: | ||
63 | |||
64 | +--------+--------+--------+--------+--------+--------+--------+--------+ | ||
65 | |63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0| | ||
66 | +--------+--------+--------+--------+--------+--------+--------+--------+ | ||
67 | | | | | | | ||
68 | | | | | v | ||
69 | | | | | [15:0] in-page offset | ||
70 | | | | +----------> [28:16] L3 index | ||
71 | | | +--------------------------> [41:29] L2 index (only 38:29 used) | ||
72 | | +-------------------------------> [47:42] L1 index (not used) | ||
73 | +-------------------------------------------------> [63] TTBR0/1 | ||