diff options
Diffstat (limited to 'Documentation/arm/arm.rst')
-rw-r--r-- | Documentation/arm/arm.rst | 214 |
1 files changed, 214 insertions, 0 deletions
diff --git a/Documentation/arm/arm.rst b/Documentation/arm/arm.rst new file mode 100644 index 000000000000..2edc509df92a --- /dev/null +++ b/Documentation/arm/arm.rst | |||
@@ -0,0 +1,214 @@ | |||
1 | ======================= | ||
2 | ARM Linux 2.6 and upper | ||
3 | ======================= | ||
4 | |||
5 | Please check <ftp://ftp.arm.linux.org.uk/pub/armlinux> for | ||
6 | updates. | ||
7 | |||
8 | Compilation of kernel | ||
9 | --------------------- | ||
10 | |||
11 | In order to compile ARM Linux, you will need a compiler capable of | ||
12 | generating ARM ELF code with GNU extensions. GCC 3.3 is known to be | ||
13 | a good compiler. Fortunately, you needn't guess. The kernel will report | ||
14 | an error if your compiler is a recognized offender. | ||
15 | |||
16 | To build ARM Linux natively, you shouldn't have to alter the ARCH = line | ||
17 | in the top level Makefile. However, if you don't have the ARM Linux ELF | ||
18 | tools installed as default, then you should change the CROSS_COMPILE | ||
19 | line as detailed below. | ||
20 | |||
21 | If you wish to cross-compile, then alter the following lines in the top | ||
22 | level make file:: | ||
23 | |||
24 | ARCH = <whatever> | ||
25 | |||
26 | with:: | ||
27 | |||
28 | ARCH = arm | ||
29 | |||
30 | and:: | ||
31 | |||
32 | CROSS_COMPILE= | ||
33 | |||
34 | to:: | ||
35 | |||
36 | CROSS_COMPILE=<your-path-to-your-compiler-without-gcc> | ||
37 | |||
38 | eg.:: | ||
39 | |||
40 | CROSS_COMPILE=arm-linux- | ||
41 | |||
42 | Do a 'make config', followed by 'make Image' to build the kernel | ||
43 | (arch/arm/boot/Image). A compressed image can be built by doing a | ||
44 | 'make zImage' instead of 'make Image'. | ||
45 | |||
46 | |||
47 | Bug reports etc | ||
48 | --------------- | ||
49 | |||
50 | Please send patches to the patch system. For more information, see | ||
51 | http://www.arm.linux.org.uk/developer/patches/info.php Always include some | ||
52 | explanation as to what the patch does and why it is needed. | ||
53 | |||
54 | Bug reports should be sent to linux-arm-kernel@lists.arm.linux.org.uk, | ||
55 | or submitted through the web form at | ||
56 | http://www.arm.linux.org.uk/developer/ | ||
57 | |||
58 | When sending bug reports, please ensure that they contain all relevant | ||
59 | information, eg. the kernel messages that were printed before/during | ||
60 | the problem, what you were doing, etc. | ||
61 | |||
62 | |||
63 | Include files | ||
64 | ------------- | ||
65 | |||
66 | Several new include directories have been created under include/asm-arm, | ||
67 | which are there to reduce the clutter in the top-level directory. These | ||
68 | directories, and their purpose is listed below: | ||
69 | |||
70 | ============= ========================================================== | ||
71 | `arch-*` machine/platform specific header files | ||
72 | `hardware` driver-internal ARM specific data structures/definitions | ||
73 | `mach` descriptions of generic ARM to specific machine interfaces | ||
74 | `proc-*` processor dependent header files (currently only two | ||
75 | categories) | ||
76 | ============= ========================================================== | ||
77 | |||
78 | |||
79 | Machine/Platform support | ||
80 | ------------------------ | ||
81 | |||
82 | The ARM tree contains support for a lot of different machine types. To | ||
83 | continue supporting these differences, it has become necessary to split | ||
84 | machine-specific parts by directory. For this, the machine category is | ||
85 | used to select which directories and files get included (we will use | ||
86 | $(MACHINE) to refer to the category) | ||
87 | |||
88 | To this end, we now have arch/arm/mach-$(MACHINE) directories which are | ||
89 | designed to house the non-driver files for a particular machine (eg, PCI, | ||
90 | memory management, architecture definitions etc). For all future | ||
91 | machines, there should be a corresponding arch/arm/mach-$(MACHINE)/include/mach | ||
92 | directory. | ||
93 | |||
94 | |||
95 | Modules | ||
96 | ------- | ||
97 | |||
98 | Although modularisation is supported (and required for the FP emulator), | ||
99 | each module on an ARM2/ARM250/ARM3 machine when is loaded will take | ||
100 | memory up to the next 32k boundary due to the size of the pages. | ||
101 | Therefore, is modularisation on these machines really worth it? | ||
102 | |||
103 | However, ARM6 and up machines allow modules to take multiples of 4k, and | ||
104 | as such Acorn RiscPCs and other architectures using these processors can | ||
105 | make good use of modularisation. | ||
106 | |||
107 | |||
108 | ADFS Image files | ||
109 | ---------------- | ||
110 | |||
111 | You can access image files on your ADFS partitions by mounting the ADFS | ||
112 | partition, and then using the loopback device driver. You must have | ||
113 | losetup installed. | ||
114 | |||
115 | Please note that the PCEmulator DOS partitions have a partition table at | ||
116 | the start, and as such, you will have to give '-o offset' to losetup. | ||
117 | |||
118 | |||
119 | Request to developers | ||
120 | --------------------- | ||
121 | |||
122 | When writing device drivers which include a separate assembler file, please | ||
123 | include it in with the C file, and not the arch/arm/lib directory. This | ||
124 | allows the driver to be compiled as a loadable module without requiring | ||
125 | half the code to be compiled into the kernel image. | ||
126 | |||
127 | In general, try to avoid using assembler unless it is really necessary. It | ||
128 | makes drivers far less easy to port to other hardware. | ||
129 | |||
130 | |||
131 | ST506 hard drives | ||
132 | ----------------- | ||
133 | |||
134 | The ST506 hard drive controllers seem to be working fine (if a little | ||
135 | slowly). At the moment they will only work off the controllers on an | ||
136 | A4x0's motherboard, but for it to work off a Podule just requires | ||
137 | someone with a podule to add the addresses for the IRQ mask and the | ||
138 | HDC base to the source. | ||
139 | |||
140 | As of 31/3/96 it works with two drives (you should get the ADFS | ||
141 | `*configure` harddrive set to 2). I've got an internal 20MB and a great | ||
142 | big external 5.25" FH 64MB drive (who could ever want more :-) ). | ||
143 | |||
144 | I've just got 240K/s off it (a dd with bs=128k); thats about half of what | ||
145 | RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting | ||
146 | last week :-) | ||
147 | |||
148 | Known bug: Drive data errors can cause a hang; including cases where | ||
149 | the controller has fixed the error using ECC. (Possibly ONLY | ||
150 | in that case...hmm). | ||
151 | |||
152 | |||
153 | 1772 Floppy | ||
154 | ----------- | ||
155 | This also seems to work OK, but hasn't been stressed much lately. It | ||
156 | hasn't got any code for disc change detection in there at the moment which | ||
157 | could be a bit of a problem! Suggestions on the correct way to do this | ||
158 | are welcome. | ||
159 | |||
160 | |||
161 | `CONFIG_MACH_` and `CONFIG_ARCH_` | ||
162 | --------------------------------- | ||
163 | A change was made in 2003 to the macro names for new machines. | ||
164 | Historically, `CONFIG_ARCH_` was used for the bonafide architecture, | ||
165 | e.g. SA1100, as well as implementations of the architecture, | ||
166 | e.g. Assabet. It was decided to change the implementation macros | ||
167 | to read `CONFIG_MACH_` for clarity. Moreover, a retroactive fixup has | ||
168 | not been made because it would complicate patching. | ||
169 | |||
170 | Previous registrations may be found online. | ||
171 | |||
172 | <http://www.arm.linux.org.uk/developer/machines/> | ||
173 | |||
174 | Kernel entry (head.S) | ||
175 | --------------------- | ||
176 | The initial entry into the kernel is via head.S, which uses machine | ||
177 | independent code. The machine is selected by the value of 'r1' on | ||
178 | entry, which must be kept unique. | ||
179 | |||
180 | Due to the large number of machines which the ARM port of Linux provides | ||
181 | for, we have a method to manage this which ensures that we don't end up | ||
182 | duplicating large amounts of code. | ||
183 | |||
184 | We group machine (or platform) support code into machine classes. A | ||
185 | class typically based around one or more system on a chip devices, and | ||
186 | acts as a natural container around the actual implementations. These | ||
187 | classes are given directories - arch/arm/mach-<class> and | ||
188 | arch/arm/mach-<class> - which contain the source files to/include/mach | ||
189 | support the machine class. This directories also contain any machine | ||
190 | specific supporting code. | ||
191 | |||
192 | For example, the SA1100 class is based upon the SA1100 and SA1110 SoC | ||
193 | devices, and contains the code to support the way the on-board and off- | ||
194 | board devices are used, or the device is setup, and provides that | ||
195 | machine specific "personality." | ||
196 | |||
197 | For platforms that support device tree (DT), the machine selection is | ||
198 | controlled at runtime by passing the device tree blob to the kernel. At | ||
199 | compile-time, support for the machine type must be selected. This allows for | ||
200 | a single multiplatform kernel build to be used for several machine types. | ||
201 | |||
202 | For platforms that do not use device tree, this machine selection is | ||
203 | controlled by the machine type ID, which acts both as a run-time and a | ||
204 | compile-time code selection method. You can register a new machine via the | ||
205 | web site at: | ||
206 | |||
207 | <http://www.arm.linux.org.uk/developer/machines/> | ||
208 | |||
209 | Note: Please do not register a machine type for DT-only platforms. If your | ||
210 | platform is DT-only, you do not need a registered machine type. | ||
211 | |||
212 | --- | ||
213 | |||
214 | Russell King (15/03/2004) | ||