diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2012-10-01 14:51:57 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2012-10-01 14:51:57 -0400 |
commit | 81f56e5375e84689b891e0e6c5a02ec12a1f18d9 (patch) | |
tree | a1e128a71ff24fc705428df86a858076cfe4bc13 /Documentation/arm64/booting.txt | |
parent | 6c09931b3f987898f5c581d267ef269f5e2e9575 (diff) | |
parent | 27aa55c5e5123fa8b8ad0156559d34d7edff58ca (diff) |
Merge tag 'arm64-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64
Pull arm64 support from Catalin Marinas:
"Linux support for the 64-bit ARM architecture (AArch64)
Features currently supported:
- 39-bit address space for user and kernel (each)
- 4KB and 64KB page configurations
- Compat (32-bit) user applications (ARMv7, EABI only)
- Flattened Device Tree (mandated for all AArch64 platforms)
- ARM generic timers"
* tag 'arm64-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64: (35 commits)
arm64: ptrace: remove obsolete ptrace request numbers from user headers
arm64: Do not set the SMP/nAMP processor bit
arm64: MAINTAINERS update
arm64: Build infrastructure
arm64: Miscellaneous header files
arm64: Generic timers support
arm64: Loadable modules
arm64: Miscellaneous library functions
arm64: Performance counters support
arm64: Add support for /proc/sys/debug/exception-trace
arm64: Debugging support
arm64: Floating point and SIMD
arm64: 32-bit (compat) applications support
arm64: User access library functions
arm64: Signal handling support
arm64: VDSO support
arm64: System calls handling
arm64: ELF definitions
arm64: SMP support
arm64: DMA mapping API
...
Diffstat (limited to 'Documentation/arm64/booting.txt')
-rw-r--r-- | Documentation/arm64/booting.txt | 152 |
1 files changed, 152 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) | ||