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