source: rtems/doc/cpu_supplement/arm.t @ 42cf7c7

4.104.114.95
Last change on this file since 42cf7c7 was 42cf7c7, checked in by Joel Sherrill <joel.sherrill@…>, on 06/02/08 at 16:09:56

2008-06-02 Joel Sherrill <joel.sherrill@…>

  • cpu_supplement/.cvsignore, cpu_supplement/Makefile.am, cpu_supplement/arm.t, cpu_supplement/bfin.t, cpu_supplement/cpu_supplement.texi, cpu_supplement/i386.t, cpu_supplement/m68k.t, cpu_supplement/mips.t, cpu_supplement/powerpc.t, cpu_supplement/preface.texi, cpu_supplement/sh.t: Remove duplicated text from each CPU specific chapter. This text was necessary when each CPU was a separate manual but now only needs to be one place and that is in an introductory chapter.
  • cpu_supplement/general.t: New file.
  • Property mode set to 100644
File size: 7.3 KB
Line 
1@c
2@c  COPYRIGHT (c) 1988-2002.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
5@c
6@c  $Id$
7@c
8
9@ifinfo
10@end ifinfo
11@chapter ARM Specific Information
12
13This chapter discusses the ARM architecture dependencies
14in this port of RTEMS.  The ARM family has a wide variety
15of implementations by a wide range of vendors.  Consequently,
16there are many, many CPU models within it.
17
18@subheading Architecture Documents
19
20For information on the ARM architecture, refer to the following documents
21available from Arm, Limited (@file{http//www.arm.com/}).  There does
22not appear to be an electronic version of a manual on the architecture
23in general on that site.  The following book is a good resource:
24
25@itemize @bullet
26@item @cite{David Seal. "ARM Architecture Reference Manual."
27Addison-Wesley. @b{ISBN 0-201-73719-1}. 2001.}
28
29@end itemize
30
31
32@c
33@c
34@c
35
36@section CPU Model Dependent Features
37
38This section presents the set of features which vary
39across ARM implementations and are of importance to RTEMS.
40The set of CPU model feature macros are defined in the file
41@code{cpukit/score/cpu/arm/rtems/score/arm.h} based upon the particular CPU
42model flags specified on the compilation command line.
43
44@subsection CPU Model Name
45
46The macro @code{CPU_MODEL_NAME} is a string which designates
47the architectural level of this CPU model.  The following is
48a list of the settings for this string based upon @code{gcc}
49CPU model predefines:
50
51@example
52__ARM_ARCH4__   "ARMv4"
53__ARM_ARCH4T__  "ARMv4T"
54__ARM_ARCH5__   "ARMv5"
55__ARM_ARCH5T__  "ARMv5T"
56__ARM_ARCH5E__  "ARMv5E"
57__ARM_ARCH5TE__ "ARMv5TE"
58@end example
59
60@subsection Count Leading Zeroes Instruction
61
62The ARMv5 and later has the count leading zeroes (@code{clz})
63instruction which could be used to speed up the find first bit
64operation.  The use of this instruction should significantly speed up
65the scheduling associated with a thread blocking.
66
67@subsection Floating Point Unit
68
69The macro ARM_HAS_FPU is set to 1 to indicate that
70this CPU model has a hardware floating point unit and 0
71otherwise.  It does not matter whether the hardware floating
72point support is incorporated on-chip or is an external
73coprocessor.
74
75@c
76@c
77@c
78@section Calling Conventions
79
80The ARM architecture supports a simple yet effective call and
81return mechanism.  A subroutine is invoked via the branch and link
82(@code{bl}) instruction.  This instruction saves the return address
83in the @code{lr} register.  Returning from a subroutine only requires
84that the return address be moved into the program counter (@code{pc}),
85possibly with an offset.  It is is important to note that the @code{bl}
86instruction does not automatically save or restore any registers.
87It is the responsibility of the high-level language compiler to define
88the register preservation and usage convention.
89
90@subsection Calling Mechanism
91
92All RTEMS directives are invoked using the @code{bl} instruction and
93return to the user application via the mechanism described above.
94
95@subsection Register Usage
96
97As discussed above, the ARM's call and return mechanism dos
98not automatically save any registers.  RTEMS uses the registers
99@code{r0}, @code{r1}, @code{r2}, and @code{r3} as scratch registers and
100per ARM calling convention, the @code{lr} register is altered
101as well.  These registers are not preserved by RTEMS directives
102therefore, the contents of these registers should not be assumed
103upon return from any RTEMS directive.
104
105@subsection Parameter Passing
106
107RTEMS assumes that ARM calling conventions are followed and that
108the first four arguments are placed in registers @code{r0} through
109@code{r3}.  If there are more arguments, than that, then they
110are place on the stack.
111
112@c
113@c
114@c
115
116@section Memory Model
117
118@subsection Flat Memory Model
119
120Members of the ARM family newer than Version 3 support a flat 32-bit
121address space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
122gigabytes).  Each address is represented by a 32-bit value and is byte
123addressable.  The address may be used to reference a single byte, word
124(2-bytes), or long word (4 bytes).  Memory accesses within this address
125space are performed in the endian mode that the processor is configured
126for.   In general, ARM processors are used in little endian mode.
127
128Some of the ARM family members such as the 920 and 720 include an MMU
129and thus support virtual memory and segmentation.  RTEMS does not support
130virtual memory or segmentation on any of the ARM family members.
131
132@c
133@c
134@c
135@section Interrupt Processing
136
137Although RTEMS hides many of the processor dependent
138details of interrupt processing, it is important to understand
139how the RTEMS interrupt manager is mapped onto the processor's
140unique architecture. Discussed in this chapter are the ARM's
141interrupt response and control mechanisms as they pertain to
142RTEMS.
143
144The ARM has 7 exception types:
145
146@itemize @bullet
147
148@item Reset
149@item Undefined instruction
150@item Software interrupt (SWI)
151@item Prefetch Abort
152@item Data Abort
153@item Interrupt (IRQ)
154@item Fast Interrupt (FIQ)
155
156@end itemize
157
158Of these types, only IRQ and FIQ are handled through RTEMS's interrupt
159vectoring.
160
161@subsection Vectoring of an Interrupt Handler
162
163Unlike many other architectures, the ARM has seperate stacks for each
164interrupt. When the CPU receives an interrupt, it:
165
166@itemize @bullet
167@item switches to the exception mode corresponding to the interrupt,
168
169@item saves the Current Processor Status Register (CPSR) to the
170exception mode's Saved Processor Status Register (SPSR),
171
172@item masks off the IRQ and if the interrupt source was FIQ, the FIQ
173is masked off as well,
174
175@item saves the Program Counter (PC) to the exception mode's Link
176Register (LR - same as R14),
177 
178@item and sets the PC to the exception's vector address.
179
180@end itemize
181
182The vectors for both IRQ and FIQ point to the _ISR_Handler function.
183_ISR_Handler() calls the BSP specific handler, ExecuteITHandler(). Before
184calling ExecuteITHandler(), registers R0-R3, R12, and R14(LR) are saved so
185that it is safe to call C functions. Even ExecuteITHandler() can be written
186in C.
187
188@subsection Interrupt Levels
189
190The ARM architecture supports two external interrupts - IRQ and FIQ. FIQ
191has a higher priority than IRQ, and has its own version of register R8 - R14,
192however RTEMS does not take advantage of them. Both interrupts are enabled
193through the CPSR.
194
195The RTEMS interrupt level mapping scheme for the AEM is not a numeric level
196as on most RTEMS ports. It is a bit mapping that corresponds the enable
197bits's postions in the CPSR:
198
199@table @b
200@item FIQ
201Setting bit 6 (0 is least significant bit) disables the FIQ.
202
203@item IRQ
204Setting bit 7 (0 is least significant bit) disables the IRQ.
205 
206@end table
207 
208@subsection Interrupt Stack
209
210RTEMS expects the interrupt stacks to be set up in bsp_start(). The memory
211for the stacks is reserved in the linker script.
212
213@c
214@c
215@c
216@section Default Fatal Error Processing
217
218The default fatal error handler for this architecture performs the
219following actions:
220
221@itemize @bullet
222@item disables processor interrupts,
223@item places the error code in @b{r0}, and
224@item executes an infinite loop (@code{while(0);} to
225simulate a halt processor instruction.
226@end itemize
227
228@c
229@c
230@c
231@section Board Support Packages
232
233@subsection System Reset
234
235An RTEMS based application is initiated or re-initiated when the processor
236is reset.  When the processor is reset, the processor performs the
237following actions:
238
239@itemize @bullet
240@item TBD
241
242@end itemize
243
244@subsection Processor Initialization
245
246TBD
Note: See TracBrowser for help on using the repository browser.