1 |
30 |
unneback |
/* cpu.h
|
2 |
|
|
*
|
3 |
|
|
* This include file contains information pertaining to the AMD 29K
|
4 |
|
|
* processor.
|
5 |
|
|
*
|
6 |
|
|
* Author: Craig Lebakken <craigl@transition.com>
|
7 |
|
|
*
|
8 |
|
|
* COPYRIGHT (c) 1996 by Transition Networks Inc.
|
9 |
|
|
*
|
10 |
|
|
* To anyone who acknowledges that this file is provided "AS IS"
|
11 |
|
|
* without any express or implied warranty:
|
12 |
|
|
* permission to use, copy, modify, and distribute this file
|
13 |
|
|
* for any purpose is hereby granted without fee, provided that
|
14 |
|
|
* the above copyright notice and this notice appears in all
|
15 |
|
|
* copies, and that the name of Transition Networks not be used in
|
16 |
|
|
* advertising or publicity pertaining to distribution of the
|
17 |
|
|
* software without specific, written prior permission.
|
18 |
|
|
* Transition Networks makes no representations about the suitability
|
19 |
|
|
* of this software for any purpose.
|
20 |
|
|
*
|
21 |
|
|
* Derived from c/src/exec/score/cpu/no_cpu/cpu_asm.c:
|
22 |
|
|
*
|
23 |
|
|
* COPYRIGHT (c) 1989-1999.
|
24 |
|
|
* On-Line Applications Research Corporation (OAR).
|
25 |
|
|
*
|
26 |
|
|
* The license and distribution terms for this file may be
|
27 |
|
|
* found in the file LICENSE in this distribution or at
|
28 |
|
|
* http://www.OARcorp.com/rtems/license.html.
|
29 |
|
|
*
|
30 |
|
|
* $Id: cpu.h,v 1.2 2001-09-27 11:59:24 chris Exp $
|
31 |
|
|
*/
|
32 |
|
|
/* @(#)cpu.h 10/21/96 1.11 */
|
33 |
|
|
|
34 |
|
|
#ifndef __CPU_h
|
35 |
|
|
#define __CPU_h
|
36 |
|
|
|
37 |
|
|
#ifdef __cplusplus
|
38 |
|
|
extern "C" {
|
39 |
|
|
#endif
|
40 |
|
|
|
41 |
|
|
#include <rtems/score/a29k.h> /* pick up machine definitions */
|
42 |
|
|
#ifndef ASM
|
43 |
|
|
#include <rtems/score/a29ktypes.h>
|
44 |
|
|
#endif
|
45 |
|
|
|
46 |
|
|
extern unsigned int a29k_disable( void );
|
47 |
|
|
extern void a29k_enable( unsigned int cookie );
|
48 |
|
|
extern unsigned int a29k_getops( void );
|
49 |
|
|
extern void a29k_getops_sup( void );
|
50 |
|
|
extern void a29k_disable_sup( void );
|
51 |
|
|
extern void a29k_enable_sup( void );
|
52 |
|
|
extern void a29k_disable_all( void );
|
53 |
|
|
extern void a29k_disable_all_sup( void );
|
54 |
|
|
extern void a29k_enable_all( void );
|
55 |
|
|
extern void a29k_enable_all_sup( void );
|
56 |
|
|
extern void a29k_halt( void );
|
57 |
|
|
extern void a29k_fatal_error( unsigned32 error );
|
58 |
|
|
extern void a29k_as70( void );
|
59 |
|
|
extern void a29k_super_mode( void );
|
60 |
|
|
extern void a29k_context_switch_sup(void);
|
61 |
|
|
extern void a29k_context_restore_sup(void);
|
62 |
|
|
extern void a29k_context_save_sup(void);
|
63 |
|
|
extern void a29k_sigdfl_sup(void);
|
64 |
|
|
|
65 |
|
|
/* conditional compilation parameters */
|
66 |
|
|
|
67 |
|
|
/*
|
68 |
|
|
* Should the calls to _Thread_Enable_dispatch be inlined?
|
69 |
|
|
*
|
70 |
|
|
* If TRUE, then they are inlined.
|
71 |
|
|
* If FALSE, then a subroutine call is made.
|
72 |
|
|
*
|
73 |
|
|
* Basically this is an example of the classic trade-off of size
|
74 |
|
|
* versus speed. Inlining the call (TRUE) typically increases the
|
75 |
|
|
* size of RTEMS while speeding up the enabling of dispatching.
|
76 |
|
|
* [NOTE: In general, the _Thread_Dispatch_disable_level will
|
77 |
|
|
* only be 0 or 1 unless you are in an interrupt handler and that
|
78 |
|
|
* interrupt handler invokes the executive.] When not inlined
|
79 |
|
|
* something calls _Thread_Enable_dispatch which in turns calls
|
80 |
|
|
* _Thread_Dispatch. If the enable dispatch is inlined, then
|
81 |
|
|
* one subroutine call is avoided entirely.]
|
82 |
|
|
*/
|
83 |
|
|
|
84 |
|
|
#define CPU_INLINE_ENABLE_DISPATCH TRUE
|
85 |
|
|
|
86 |
|
|
/*
|
87 |
|
|
* Should the body of the search loops in _Thread_queue_Enqueue_priority
|
88 |
|
|
* be unrolled one time? In unrolled each iteration of the loop examines
|
89 |
|
|
* two "nodes" on the chain being searched. Otherwise, only one node
|
90 |
|
|
* is examined per iteration.
|
91 |
|
|
*
|
92 |
|
|
* If TRUE, then the loops are unrolled.
|
93 |
|
|
* If FALSE, then the loops are not unrolled.
|
94 |
|
|
*
|
95 |
|
|
* The primary factor in making this decision is the cost of disabling
|
96 |
|
|
* and enabling interrupts (_ISR_Flash) versus the cost of rest of the
|
97 |
|
|
* body of the loop. On some CPUs, the flash is more expensive than
|
98 |
|
|
* one iteration of the loop body. In this case, it might be desirable
|
99 |
|
|
* to unroll the loop. It is important to note that on some CPUs, this
|
100 |
|
|
* code is the longest interrupt disable period in RTEMS. So it is
|
101 |
|
|
* necessary to strike a balance when setting this parameter.
|
102 |
|
|
*/
|
103 |
|
|
|
104 |
|
|
#define CPU_UNROLL_ENQUEUE_PRIORITY TRUE
|
105 |
|
|
|
106 |
|
|
/*
|
107 |
|
|
* Does RTEMS manage a dedicated interrupt stack in software?
|
108 |
|
|
*
|
109 |
|
|
* If TRUE, then a stack is allocated in _ISR_Handler_initialization.
|
110 |
|
|
* If FALSE, nothing is done.
|
111 |
|
|
*
|
112 |
|
|
* If the CPU supports a dedicated interrupt stack in hardware,
|
113 |
|
|
* then it is generally the responsibility of the BSP to allocate it
|
114 |
|
|
* and set it up.
|
115 |
|
|
*
|
116 |
|
|
* If the CPU does not support a dedicated interrupt stack, then
|
117 |
|
|
* the porter has two options: (1) execute interrupts on the
|
118 |
|
|
* stack of the interrupted task, and (2) have RTEMS manage a dedicated
|
119 |
|
|
* interrupt stack.
|
120 |
|
|
*
|
121 |
|
|
* If this is TRUE, CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
|
122 |
|
|
*
|
123 |
|
|
* Only one of CPU_HAS_SOFTWARE_INTERRUPT_STACK and
|
124 |
|
|
* CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE. It is
|
125 |
|
|
* possible that both are FALSE for a particular CPU. Although it
|
126 |
|
|
* is unclear what that would imply about the interrupt processing
|
127 |
|
|
* procedure on that CPU.
|
128 |
|
|
*/
|
129 |
|
|
|
130 |
|
|
#define CPU_HAS_SOFTWARE_INTERRUPT_STACK FALSE
|
131 |
|
|
|
132 |
|
|
/*
|
133 |
|
|
* Does this CPU have hardware support for a dedicated interrupt stack?
|
134 |
|
|
*
|
135 |
|
|
* If TRUE, then it must be installed during initialization.
|
136 |
|
|
* If FALSE, then no installation is performed.
|
137 |
|
|
*
|
138 |
|
|
* If this is TRUE, CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
|
139 |
|
|
*
|
140 |
|
|
* Only one of CPU_HAS_SOFTWARE_INTERRUPT_STACK and
|
141 |
|
|
* CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE. It is
|
142 |
|
|
* possible that both are FALSE for a particular CPU. Although it
|
143 |
|
|
* is unclear what that would imply about the interrupt processing
|
144 |
|
|
* procedure on that CPU.
|
145 |
|
|
*/
|
146 |
|
|
|
147 |
|
|
#define CPU_HAS_HARDWARE_INTERRUPT_STACK FALSE
|
148 |
|
|
|
149 |
|
|
/*
|
150 |
|
|
* Does RTEMS allocate a dedicated interrupt stack in the Interrupt Manager?
|
151 |
|
|
*
|
152 |
|
|
* If TRUE, then the memory is allocated during initialization.
|
153 |
|
|
* If FALSE, then the memory is allocated during initialization.
|
154 |
|
|
*
|
155 |
|
|
* This should be TRUE is CPU_HAS_SOFTWARE_INTERRUPT_STACK is TRUE
|
156 |
|
|
* or CPU_INSTALL_HARDWARE_INTERRUPT_STACK is TRUE.
|
157 |
|
|
*/
|
158 |
|
|
|
159 |
|
|
#define CPU_ALLOCATE_INTERRUPT_STACK FALSE
|
160 |
|
|
|
161 |
|
|
/*
|
162 |
|
|
* Does the RTEMS invoke the user's ISR with the vector number and
|
163 |
|
|
* a pointer to the saved interrupt frame (1) or just the vector
|
164 |
|
|
* number (0)?
|
165 |
|
|
*/
|
166 |
|
|
|
167 |
|
|
#define CPU_ISR_PASSES_FRAME_POINTER 0
|
168 |
|
|
|
169 |
|
|
/*
|
170 |
|
|
* Does the CPU have hardware floating point?
|
171 |
|
|
*
|
172 |
|
|
* If TRUE, then the RTEMS_FLOATING_POINT task attribute is supported.
|
173 |
|
|
* If FALSE, then the RTEMS_FLOATING_POINT task attribute is ignored.
|
174 |
|
|
*
|
175 |
|
|
* If there is a FP coprocessor such as the i387 or mc68881, then
|
176 |
|
|
* the answer is TRUE.
|
177 |
|
|
*
|
178 |
|
|
* The macro name "NO_CPU_HAS_FPU" should be made CPU specific.
|
179 |
|
|
* It indicates whether or not this CPU model has FP support. For
|
180 |
|
|
* example, it would be possible to have an i386_nofp CPU model
|
181 |
|
|
* which set this to false to indicate that you have an i386 without
|
182 |
|
|
* an i387 and wish to leave floating point support out of RTEMS.
|
183 |
|
|
*/
|
184 |
|
|
|
185 |
|
|
#if ( A29K_HAS_FPU == 1 )
|
186 |
|
|
#define CPU_HARDWARE_FP TRUE
|
187 |
|
|
#else
|
188 |
|
|
#define CPU_HARDWARE_FP FALSE
|
189 |
|
|
#endif
|
190 |
|
|
|
191 |
|
|
/*
|
192 |
|
|
* Are all tasks RTEMS_FLOATING_POINT tasks implicitly?
|
193 |
|
|
*
|
194 |
|
|
* If TRUE, then the RTEMS_FLOATING_POINT task attribute is assumed.
|
195 |
|
|
* If FALSE, then the RTEMS_FLOATING_POINT task attribute is followed.
|
196 |
|
|
*
|
197 |
|
|
* So far, the only CPU in which this option has been used is the
|
198 |
|
|
* HP PA-RISC. The HP C compiler and gcc both implicitly use the
|
199 |
|
|
* floating point registers to perform integer multiplies. If
|
200 |
|
|
* a function which you would not think utilize the FP unit DOES,
|
201 |
|
|
* then one can not easily predict which tasks will use the FP hardware.
|
202 |
|
|
* In this case, this option should be TRUE.
|
203 |
|
|
*
|
204 |
|
|
* If CPU_HARDWARE_FP is FALSE, then this should be FALSE as well.
|
205 |
|
|
*/
|
206 |
|
|
|
207 |
|
|
#define CPU_ALL_TASKS_ARE_FP FALSE
|
208 |
|
|
|
209 |
|
|
/*
|
210 |
|
|
* Should the IDLE task have a floating point context?
|
211 |
|
|
*
|
212 |
|
|
* If TRUE, then the IDLE task is created as a RTEMS_FLOATING_POINT task
|
213 |
|
|
* and it has a floating point context which is switched in and out.
|
214 |
|
|
* If FALSE, then the IDLE task does not have a floating point context.
|
215 |
|
|
*
|
216 |
|
|
* Setting this to TRUE negatively impacts the time required to preempt
|
217 |
|
|
* the IDLE task from an interrupt because the floating point context
|
218 |
|
|
* must be saved as part of the preemption.
|
219 |
|
|
*/
|
220 |
|
|
|
221 |
|
|
#define CPU_IDLE_TASK_IS_FP FALSE
|
222 |
|
|
|
223 |
|
|
/*
|
224 |
|
|
* Should the saving of the floating point registers be deferred
|
225 |
|
|
* until a context switch is made to another different floating point
|
226 |
|
|
* task?
|
227 |
|
|
*
|
228 |
|
|
* If TRUE, then the floating point context will not be stored until
|
229 |
|
|
* necessary. It will remain in the floating point registers and not
|
230 |
|
|
* disturned until another floating point task is switched to.
|
231 |
|
|
*
|
232 |
|
|
* If FALSE, then the floating point context is saved when a floating
|
233 |
|
|
* point task is switched out and restored when the next floating point
|
234 |
|
|
* task is restored. The state of the floating point registers between
|
235 |
|
|
* those two operations is not specified.
|
236 |
|
|
*
|
237 |
|
|
* If the floating point context does NOT have to be saved as part of
|
238 |
|
|
* interrupt dispatching, then it should be safe to set this to TRUE.
|
239 |
|
|
*
|
240 |
|
|
* Setting this flag to TRUE results in using a different algorithm
|
241 |
|
|
* for deciding when to save and restore the floating point context.
|
242 |
|
|
* The deferred FP switch algorithm minimizes the number of times
|
243 |
|
|
* the FP context is saved and restored. The FP context is not saved
|
244 |
|
|
* until a context switch is made to another, different FP task.
|
245 |
|
|
* Thus in a system with only one FP task, the FP context will never
|
246 |
|
|
* be saved or restored.
|
247 |
|
|
*/
|
248 |
|
|
|
249 |
|
|
#define CPU_USE_DEFERRED_FP_SWITCH TRUE
|
250 |
|
|
|
251 |
|
|
/*
|
252 |
|
|
* Does this port provide a CPU dependent IDLE task implementation?
|
253 |
|
|
*
|
254 |
|
|
* If TRUE, then the routine _CPU_Internal_threads_Idle_thread_body
|
255 |
|
|
* must be provided and is the default IDLE thread body instead of
|
256 |
|
|
* _Internal_threads_Idle_thread_body.
|
257 |
|
|
*
|
258 |
|
|
* If FALSE, then use the generic IDLE thread body if the BSP does
|
259 |
|
|
* not provide one.
|
260 |
|
|
*
|
261 |
|
|
* This is intended to allow for supporting processors which have
|
262 |
|
|
* a low power or idle mode. When the IDLE thread is executed, then
|
263 |
|
|
* the CPU can be powered down.
|
264 |
|
|
*
|
265 |
|
|
* The order of precedence for selecting the IDLE thread body is:
|
266 |
|
|
*
|
267 |
|
|
* 1. BSP provided
|
268 |
|
|
* 2. CPU dependent (if provided)
|
269 |
|
|
* 3. generic (if no BSP and no CPU dependent)
|
270 |
|
|
*/
|
271 |
|
|
|
272 |
|
|
#define CPU_PROVIDES_IDLE_THREAD_BODY TRUE
|
273 |
|
|
|
274 |
|
|
/*
|
275 |
|
|
* Does the stack grow up (toward higher addresses) or down
|
276 |
|
|
* (toward lower addresses)?
|
277 |
|
|
*
|
278 |
|
|
* If TRUE, then the grows upward.
|
279 |
|
|
* If FALSE, then the grows toward smaller addresses.
|
280 |
|
|
*/
|
281 |
|
|
|
282 |
|
|
#define CPU_STACK_GROWS_UP FALSE
|
283 |
|
|
|
284 |
|
|
/*
|
285 |
|
|
* The following is the variable attribute used to force alignment
|
286 |
|
|
* of critical RTEMS structures. On some processors it may make
|
287 |
|
|
* sense to have these aligned on tighter boundaries than
|
288 |
|
|
* the minimum requirements of the compiler in order to have as
|
289 |
|
|
* much of the critical data area as possible in a cache line.
|
290 |
|
|
*
|
291 |
|
|
* The placement of this macro in the declaration of the variables
|
292 |
|
|
* is based on the syntactically requirements of the GNU C
|
293 |
|
|
* "__attribute__" extension. For example with GNU C, use
|
294 |
|
|
* the following to force a structures to a 32 byte boundary.
|
295 |
|
|
*
|
296 |
|
|
* __attribute__ ((aligned (32)))
|
297 |
|
|
*
|
298 |
|
|
* NOTE: Currently only the Priority Bit Map table uses this feature.
|
299 |
|
|
* To benefit from using this, the data must be heavily
|
300 |
|
|
* used so it will stay in the cache and used frequently enough
|
301 |
|
|
* in the executive to justify turning this on.
|
302 |
|
|
*/
|
303 |
|
|
|
304 |
|
|
#define CPU_STRUCTURE_ALIGNMENT
|
305 |
|
|
|
306 |
|
|
/*
|
307 |
|
|
* Define what is required to specify how the network to host conversion
|
308 |
|
|
* routines are handled.
|
309 |
|
|
*
|
310 |
|
|
*/
|
311 |
|
|
|
312 |
|
|
#error "Check these definitions!!!"
|
313 |
|
|
|
314 |
|
|
#define CPU_HAS_OWN_HOST_TO_NETWORK_ROUTINES FALSE
|
315 |
|
|
#define CPU_BIG_ENDIAN TRUE
|
316 |
|
|
#define CPU_LITTLE_ENDIAN FALSE
|
317 |
|
|
|
318 |
|
|
/*
|
319 |
|
|
* The following defines the number of bits actually used in the
|
320 |
|
|
* interrupt field of the task mode. How those bits map to the
|
321 |
|
|
* CPU interrupt levels is defined by the routine _CPU_ISR_Set_level().
|
322 |
|
|
*/
|
323 |
|
|
|
324 |
|
|
#define CPU_MODES_INTERRUPT_MASK 0x00000001
|
325 |
|
|
|
326 |
|
|
/*
|
327 |
|
|
* Processor defined structures
|
328 |
|
|
*
|
329 |
|
|
* Examples structures include the descriptor tables from the i386
|
330 |
|
|
* and the processor control structure on the i960ca.
|
331 |
|
|
*/
|
332 |
|
|
|
333 |
|
|
/* may need to put some structures here. */
|
334 |
|
|
|
335 |
|
|
/*
|
336 |
|
|
* Contexts
|
337 |
|
|
*
|
338 |
|
|
* Generally there are 2 types of context to save.
|
339 |
|
|
* 1. Interrupt registers to save
|
340 |
|
|
* 2. Task level registers to save
|
341 |
|
|
*
|
342 |
|
|
* This means we have the following 3 context items:
|
343 |
|
|
* 1. task level context stuff:: Context_Control
|
344 |
|
|
* 2. floating point task stuff:: Context_Control_fp
|
345 |
|
|
* 3. special interrupt level context :: Context_Control_interrupt
|
346 |
|
|
*
|
347 |
|
|
* On some processors, it is cost-effective to save only the callee
|
348 |
|
|
* preserved registers during a task context switch. This means
|
349 |
|
|
* that the ISR code needs to save those registers which do not
|
350 |
|
|
* persist across function calls. It is not mandatory to make this
|
351 |
|
|
* distinctions between the caller/callee saves registers for the
|
352 |
|
|
* purpose of minimizing context saved during task switch and on interrupts.
|
353 |
|
|
* If the cost of saving extra registers is minimal, simplicity is the
|
354 |
|
|
* choice. Save the same context on interrupt entry as for tasks in
|
355 |
|
|
* this case.
|
356 |
|
|
*
|
357 |
|
|
* Additionally, if gdb is to be made aware of RTEMS tasks for this CPU, then
|
358 |
|
|
* care should be used in designing the context area.
|
359 |
|
|
*
|
360 |
|
|
* On some CPUs with hardware floating point support, the Context_Control_fp
|
361 |
|
|
* structure will not be used or it simply consist of an array of a
|
362 |
|
|
* fixed number of bytes. This is done when the floating point context
|
363 |
|
|
* is dumped by a "FP save context" type instruction and the format
|
364 |
|
|
* is not really defined by the CPU. In this case, there is no need
|
365 |
|
|
* to figure out the exact format -- only the size. Of course, although
|
366 |
|
|
* this is enough information for RTEMS, it is probably not enough for
|
367 |
|
|
* a debugger such as gdb. But that is another problem.
|
368 |
|
|
*/
|
369 |
|
|
|
370 |
|
|
typedef struct {
|
371 |
|
|
unsigned32 signal;
|
372 |
|
|
unsigned32 gr1;
|
373 |
|
|
unsigned32 rab;
|
374 |
|
|
unsigned32 PC0;
|
375 |
|
|
unsigned32 PC1;
|
376 |
|
|
unsigned32 PC2;
|
377 |
|
|
unsigned32 CHA;
|
378 |
|
|
unsigned32 CHD;
|
379 |
|
|
unsigned32 CHC;
|
380 |
|
|
unsigned32 ALU;
|
381 |
|
|
unsigned32 OPS;
|
382 |
|
|
unsigned32 tav;
|
383 |
|
|
unsigned32 lr1;
|
384 |
|
|
unsigned32 rfb;
|
385 |
|
|
unsigned32 msp;
|
386 |
|
|
|
387 |
|
|
unsigned32 FPStat0;
|
388 |
|
|
unsigned32 FPStat1;
|
389 |
|
|
unsigned32 FPStat2;
|
390 |
|
|
unsigned32 IPA;
|
391 |
|
|
unsigned32 IPB;
|
392 |
|
|
unsigned32 IPC;
|
393 |
|
|
unsigned32 Q;
|
394 |
|
|
|
395 |
|
|
unsigned32 gr96;
|
396 |
|
|
unsigned32 gr97;
|
397 |
|
|
unsigned32 gr98;
|
398 |
|
|
unsigned32 gr99;
|
399 |
|
|
unsigned32 gr100;
|
400 |
|
|
unsigned32 gr101;
|
401 |
|
|
unsigned32 gr102;
|
402 |
|
|
unsigned32 gr103;
|
403 |
|
|
unsigned32 gr104;
|
404 |
|
|
unsigned32 gr105;
|
405 |
|
|
unsigned32 gr106;
|
406 |
|
|
unsigned32 gr107;
|
407 |
|
|
unsigned32 gr108;
|
408 |
|
|
unsigned32 gr109;
|
409 |
|
|
unsigned32 gr110;
|
410 |
|
|
unsigned32 gr111;
|
411 |
|
|
|
412 |
|
|
unsigned32 gr112;
|
413 |
|
|
unsigned32 gr113;
|
414 |
|
|
unsigned32 gr114;
|
415 |
|
|
unsigned32 gr115;
|
416 |
|
|
|
417 |
|
|
unsigned32 gr116;
|
418 |
|
|
unsigned32 gr117;
|
419 |
|
|
unsigned32 gr118;
|
420 |
|
|
unsigned32 gr119;
|
421 |
|
|
unsigned32 gr120;
|
422 |
|
|
unsigned32 gr121;
|
423 |
|
|
unsigned32 gr122;
|
424 |
|
|
unsigned32 gr123;
|
425 |
|
|
unsigned32 gr124;
|
426 |
|
|
|
427 |
|
|
unsigned32 local_count;
|
428 |
|
|
|
429 |
|
|
unsigned32 locals[128];
|
430 |
|
|
} Context_Control;
|
431 |
|
|
|
432 |
|
|
typedef struct {
|
433 |
|
|
double some_float_register;
|
434 |
|
|
} Context_Control_fp;
|
435 |
|
|
|
436 |
|
|
typedef struct {
|
437 |
|
|
unsigned32 special_interrupt_register;
|
438 |
|
|
} CPU_Interrupt_frame;
|
439 |
|
|
|
440 |
|
|
|
441 |
|
|
/*
|
442 |
|
|
* The following table contains the information required to configure
|
443 |
|
|
* the XXX processor specific parameters.
|
444 |
|
|
*
|
445 |
|
|
* NOTE: The interrupt_stack_size field is required if
|
446 |
|
|
* CPU_ALLOCATE_INTERRUPT_STACK is defined as TRUE.
|
447 |
|
|
*
|
448 |
|
|
* The pretasking_hook, predriver_hook, and postdriver_hook,
|
449 |
|
|
* and the do_zero_of_workspace fields are required on ALL CPUs.
|
450 |
|
|
*/
|
451 |
|
|
|
452 |
|
|
typedef struct {
|
453 |
|
|
void (*pretasking_hook)( void );
|
454 |
|
|
void (*predriver_hook)( void );
|
455 |
|
|
void (*postdriver_hook)( void );
|
456 |
|
|
void (*idle_task)( void );
|
457 |
|
|
boolean do_zero_of_workspace;
|
458 |
|
|
unsigned32 idle_task_stack_size;
|
459 |
|
|
unsigned32 interrupt_stack_size;
|
460 |
|
|
unsigned32 extra_system_initialization_stack;
|
461 |
|
|
} rtems_cpu_table;
|
462 |
|
|
|
463 |
|
|
/*
|
464 |
|
|
* Macros to access required entires in the CPU Table are in
|
465 |
|
|
* the file rtems/system.h.
|
466 |
|
|
*/
|
467 |
|
|
|
468 |
|
|
/*
|
469 |
|
|
* Macros to access AMD A29K specific additions to the CPU Table
|
470 |
|
|
*/
|
471 |
|
|
|
472 |
|
|
/* There are no CPU specific additions to the CPU Table for this port. */
|
473 |
|
|
|
474 |
|
|
/*
|
475 |
|
|
* This variable is optional. It is used on CPUs on which it is difficult
|
476 |
|
|
* to generate an "uninitialized" FP context. It is filled in by
|
477 |
|
|
* _CPU_Initialize and copied into the task's FP context area during
|
478 |
|
|
* _CPU_Context_Initialize.
|
479 |
|
|
*/
|
480 |
|
|
|
481 |
|
|
EXTERN Context_Control_fp _CPU_Null_fp_context;
|
482 |
|
|
|
483 |
|
|
/*
|
484 |
|
|
* On some CPUs, RTEMS supports a software managed interrupt stack.
|
485 |
|
|
* This stack is allocated by the Interrupt Manager and the switch
|
486 |
|
|
* is performed in _ISR_Handler. These variables contain pointers
|
487 |
|
|
* to the lowest and highest addresses in the chunk of memory allocated
|
488 |
|
|
* for the interrupt stack. Since it is unknown whether the stack
|
489 |
|
|
* grows up or down (in general), this give the CPU dependent
|
490 |
|
|
* code the option of picking the version it wants to use.
|
491 |
|
|
*
|
492 |
|
|
* NOTE: These two variables are required if the macro
|
493 |
|
|
* CPU_HAS_SOFTWARE_INTERRUPT_STACK is defined as TRUE.
|
494 |
|
|
*/
|
495 |
|
|
|
496 |
|
|
EXTERN void *_CPU_Interrupt_stack_low;
|
497 |
|
|
EXTERN void *_CPU_Interrupt_stack_high;
|
498 |
|
|
|
499 |
|
|
/*
|
500 |
|
|
* With some compilation systems, it is difficult if not impossible to
|
501 |
|
|
* call a high-level language routine from assembly language. This
|
502 |
|
|
* is especially true of commercial Ada compilers and name mangling
|
503 |
|
|
* C++ ones. This variable can be optionally defined by the CPU porter
|
504 |
|
|
* and contains the address of the routine _Thread_Dispatch. This
|
505 |
|
|
* can make it easier to invoke that routine at the end of the interrupt
|
506 |
|
|
* sequence (if a dispatch is necessary).
|
507 |
|
|
*/
|
508 |
|
|
|
509 |
|
|
EXTERN void (*_CPU_Thread_dispatch_pointer)();
|
510 |
|
|
|
511 |
|
|
/*
|
512 |
|
|
* Nothing prevents the porter from declaring more CPU specific variables.
|
513 |
|
|
*/
|
514 |
|
|
|
515 |
|
|
/* XXX: if needed, put more variables here */
|
516 |
|
|
|
517 |
|
|
/*
|
518 |
|
|
* The size of the floating point context area. On some CPUs this
|
519 |
|
|
* will not be a "sizeof" because the format of the floating point
|
520 |
|
|
* area is not defined -- only the size is. This is usually on
|
521 |
|
|
* CPUs with a "floating point save context" instruction.
|
522 |
|
|
*/
|
523 |
|
|
|
524 |
|
|
#define CPU_CONTEXT_FP_SIZE sizeof( Context_Control_fp )
|
525 |
|
|
|
526 |
|
|
/*
|
527 |
|
|
* Amount of extra stack (above minimum stack size) required by
|
528 |
|
|
* system initialization thread. Remember that in a multiprocessor
|
529 |
|
|
* system the system intialization thread becomes the MP server thread.
|
530 |
|
|
*/
|
531 |
|
|
|
532 |
|
|
#define CPU_SYSTEM_INITIALIZATION_THREAD_EXTRA_STACK 0
|
533 |
|
|
|
534 |
|
|
/*
|
535 |
|
|
* This defines the number of entries in the ISR_Vector_table managed
|
536 |
|
|
* by RTEMS.
|
537 |
|
|
*/
|
538 |
|
|
|
539 |
|
|
#define CPU_INTERRUPT_NUMBER_OF_VECTORS 256
|
540 |
|
|
#define CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER (CPU_INTERRUPT_NUMBER_OF_VECTORS - 1)
|
541 |
|
|
|
542 |
|
|
/*
|
543 |
|
|
* Should be large enough to run all RTEMS tests. This insures
|
544 |
|
|
* that a "reasonable" small application should not have any problems.
|
545 |
|
|
*/
|
546 |
|
|
|
547 |
|
|
#define CPU_STACK_MINIMUM_SIZE (8192)
|
548 |
|
|
|
549 |
|
|
/*
|
550 |
|
|
* CPU's worst alignment requirement for data types on a byte boundary. This
|
551 |
|
|
* alignment does not take into account the requirements for the stack.
|
552 |
|
|
*/
|
553 |
|
|
|
554 |
|
|
#define CPU_ALIGNMENT 4
|
555 |
|
|
|
556 |
|
|
/*
|
557 |
|
|
* This number corresponds to the byte alignment requirement for the
|
558 |
|
|
* heap handler. This alignment requirement may be stricter than that
|
559 |
|
|
* for the data types alignment specified by CPU_ALIGNMENT. It is
|
560 |
|
|
* common for the heap to follow the same alignment requirement as
|
561 |
|
|
* CPU_ALIGNMENT. If the CPU_ALIGNMENT is strict enough for the heap,
|
562 |
|
|
* then this should be set to CPU_ALIGNMENT.
|
563 |
|
|
*
|
564 |
|
|
* NOTE: This does not have to be a power of 2. It does have to
|
565 |
|
|
* be greater or equal to than CPU_ALIGNMENT.
|
566 |
|
|
*/
|
567 |
|
|
|
568 |
|
|
#define CPU_HEAP_ALIGNMENT CPU_ALIGNMENT
|
569 |
|
|
|
570 |
|
|
/*
|
571 |
|
|
* This number corresponds to the byte alignment requirement for memory
|
572 |
|
|
* buffers allocated by the partition manager. This alignment requirement
|
573 |
|
|
* may be stricter than that for the data types alignment specified by
|
574 |
|
|
* CPU_ALIGNMENT. It is common for the partition to follow the same
|
575 |
|
|
* alignment requirement as CPU_ALIGNMENT. If the CPU_ALIGNMENT is strict
|
576 |
|
|
* enough for the partition, then this should be set to CPU_ALIGNMENT.
|
577 |
|
|
*
|
578 |
|
|
* NOTE: This does not have to be a power of 2. It does have to
|
579 |
|
|
* be greater or equal to than CPU_ALIGNMENT.
|
580 |
|
|
*/
|
581 |
|
|
|
582 |
|
|
#define CPU_PARTITION_ALIGNMENT CPU_ALIGNMENT
|
583 |
|
|
|
584 |
|
|
/*
|
585 |
|
|
* This number corresponds to the byte alignment requirement for the
|
586 |
|
|
* stack. This alignment requirement may be stricter than that for the
|
587 |
|
|
* data types alignment specified by CPU_ALIGNMENT. If the CPU_ALIGNMENT
|
588 |
|
|
* is strict enough for the stack, then this should be set to 0.
|
589 |
|
|
*
|
590 |
|
|
* NOTE: This must be a power of 2 either 0 or greater than CPU_ALIGNMENT.
|
591 |
|
|
*/
|
592 |
|
|
|
593 |
|
|
#define CPU_STACK_ALIGNMENT 0
|
594 |
|
|
|
595 |
|
|
/* ISR handler macros */
|
596 |
|
|
|
597 |
|
|
/*
|
598 |
|
|
* Disable all interrupts for an RTEMS critical section. The previous
|
599 |
|
|
* level is returned in _level.
|
600 |
|
|
*/
|
601 |
|
|
|
602 |
|
|
#define _CPU_ISR_Disable( _isr_cookie ) \
|
603 |
|
|
do{ _isr_cookie = a29k_disable(); }while(0)
|
604 |
|
|
|
605 |
|
|
/*
|
606 |
|
|
* Enable interrupts to the previous level (returned by _CPU_ISR_Disable).
|
607 |
|
|
* This indicates the end of an RTEMS critical section. The parameter
|
608 |
|
|
* _level is not modified.
|
609 |
|
|
*/
|
610 |
|
|
|
611 |
|
|
#define _CPU_ISR_Enable( _isr_cookie ) \
|
612 |
|
|
do{ a29k_enable(_isr_cookie) ; }while(0)
|
613 |
|
|
|
614 |
|
|
/*
|
615 |
|
|
* This temporarily restores the interrupt to _level before immediately
|
616 |
|
|
* disabling them again. This is used to divide long RTEMS critical
|
617 |
|
|
* sections into two or more parts. The parameter _level is not
|
618 |
|
|
* modified.
|
619 |
|
|
*/
|
620 |
|
|
|
621 |
|
|
#define _CPU_ISR_Flash( _isr_cookie ) \
|
622 |
|
|
do{ \
|
623 |
|
|
_CPU_ISR_Enable( _isr_cookie ); \
|
624 |
|
|
_CPU_ISR_Disable( _isr_cookie ); \
|
625 |
|
|
}while(0)
|
626 |
|
|
|
627 |
|
|
/*
|
628 |
|
|
* Map interrupt level in task mode onto the hardware that the CPU
|
629 |
|
|
* actually provides. Currently, interrupt levels which do not
|
630 |
|
|
* map onto the CPU in a generic fashion are undefined. Someday,
|
631 |
|
|
* it would be nice if these were "mapped" by the application
|
632 |
|
|
* via a callout. For example, m68k has 8 levels 0 - 7, levels
|
633 |
|
|
* 8 - 255 would be available for bsp/application specific meaning.
|
634 |
|
|
* This could be used to manage a programmable interrupt controller
|
635 |
|
|
* via the rtems_task_mode directive.
|
636 |
|
|
*/
|
637 |
|
|
|
638 |
|
|
#define _CPU_ISR_Set_level( new_level ) \
|
639 |
|
|
do{ \
|
640 |
|
|
if ( new_level ) a29k_disable_all(); \
|
641 |
|
|
else a29k_enable_all(); \
|
642 |
|
|
}while(0);
|
643 |
|
|
|
644 |
|
|
/* end of ISR handler macros */
|
645 |
|
|
|
646 |
|
|
/* Context handler macros */
|
647 |
|
|
|
648 |
|
|
extern void _CPU_Context_save(
|
649 |
|
|
Context_Control *new_context
|
650 |
|
|
);
|
651 |
|
|
|
652 |
|
|
/*
|
653 |
|
|
* Initialize the context to a state suitable for starting a
|
654 |
|
|
* task after a context restore operation. Generally, this
|
655 |
|
|
* involves:
|
656 |
|
|
*
|
657 |
|
|
* - setting a starting address
|
658 |
|
|
* - preparing the stack
|
659 |
|
|
* - preparing the stack and frame pointers
|
660 |
|
|
* - setting the proper interrupt level in the context
|
661 |
|
|
* - initializing the floating point context
|
662 |
|
|
*
|
663 |
|
|
* This routine generally does not set any unnecessary register
|
664 |
|
|
* in the context. The state of the "general data" registers is
|
665 |
|
|
* undefined at task start time.
|
666 |
|
|
*
|
667 |
|
|
* NOTE: This is_fp parameter is TRUE if the thread is to be a floating
|
668 |
|
|
* point thread. This is typically only used on CPUs where the
|
669 |
|
|
* FPU may be easily disabled by software such as on the SPARC
|
670 |
|
|
* where the PSR contains an enable FPU bit.
|
671 |
|
|
*/
|
672 |
|
|
|
673 |
|
|
#define _CPU_Context_Initialize( _the_context, _stack_base, _size, \
|
674 |
|
|
_isr, _entry_point, _is_fp ) \
|
675 |
|
|
do{ /* allocate 1/4 of stack for memory stack, 3/4 of stack for register stack */ \
|
676 |
|
|
unsigned32 _mem_stack_tmp = (unsigned32)(_stack_base) + (_size); \
|
677 |
|
|
unsigned32 _reg_stack_tmp = (unsigned32)(_stack_base) + (((_size)*3)/4); \
|
678 |
|
|
_mem_stack_tmp &= ~(CPU_ALIGNMENT-1); \
|
679 |
|
|
_reg_stack_tmp &= ~(CPU_ALIGNMENT-1); \
|
680 |
|
|
_CPU_Context_save(_the_context); \
|
681 |
|
|
(_the_context)->msp = _mem_stack_tmp; /* gr125 */ \
|
682 |
|
|
(_the_context)->lr1 = \
|
683 |
|
|
(_the_context)->locals[1] = \
|
684 |
|
|
(_the_context)->rfb = _reg_stack_tmp; /* gr127 */ \
|
685 |
|
|
(_the_context)->gr1 = _reg_stack_tmp - 4 * 4; \
|
686 |
|
|
(_the_context)->rab = _reg_stack_tmp - 128 * 4; /* gr126 */ \
|
687 |
|
|
(_the_context)->local_count = 1-1; \
|
688 |
|
|
(_the_context)->PC1 = _entry_point; \
|
689 |
|
|
(_the_context)->PC0 = (unsigned32)((char *)_entry_point + 4); \
|
690 |
|
|
if (_isr) { (_the_context)->OPS |= (TD | DI); } \
|
691 |
|
|
else \
|
692 |
|
|
{ (_the_context)->OPS &= ~(TD | DI); } \
|
693 |
|
|
}while(0)
|
694 |
|
|
|
695 |
|
|
/*
|
696 |
|
|
* This routine is responsible for somehow restarting the currently
|
697 |
|
|
* executing task. If you are lucky, then all that is necessary
|
698 |
|
|
* is restoring the context. Otherwise, there will need to be
|
699 |
|
|
* a special assembly routine which does something special in this
|
700 |
|
|
* case. Context_Restore should work most of the time. It will
|
701 |
|
|
* not work if restarting self conflicts with the stack frame
|
702 |
|
|
* assumptions of restoring a context.
|
703 |
|
|
*/
|
704 |
|
|
|
705 |
|
|
#define _CPU_Context_Restart_self( _the_context ) \
|
706 |
|
|
_CPU_Context_restore( (_the_context) )
|
707 |
|
|
|
708 |
|
|
/*
|
709 |
|
|
* The purpose of this macro is to allow the initial pointer into
|
710 |
|
|
* a floating point context area (used to save the floating point
|
711 |
|
|
* context) to be at an arbitrary place in the floating point
|
712 |
|
|
* context area.
|
713 |
|
|
*
|
714 |
|
|
* This is necessary because some FP units are designed to have
|
715 |
|
|
* their context saved as a stack which grows into lower addresses.
|
716 |
|
|
* Other FP units can be saved by simply moving registers into offsets
|
717 |
|
|
* from the base of the context area. Finally some FP units provide
|
718 |
|
|
* a "dump context" instruction which could fill in from high to low
|
719 |
|
|
* or low to high based on the whim of the CPU designers.
|
720 |
|
|
*/
|
721 |
|
|
|
722 |
|
|
#define _CPU_Context_Fp_start( _base, _offset ) \
|
723 |
|
|
( (char *) (_base) + (_offset) )
|
724 |
|
|
|
725 |
|
|
/*
|
726 |
|
|
* This routine initializes the FP context area passed to it to.
|
727 |
|
|
* There are a few standard ways in which to initialize the
|
728 |
|
|
* floating point context. The code included for this macro assumes
|
729 |
|
|
* that this is a CPU in which a "initial" FP context was saved into
|
730 |
|
|
* _CPU_Null_fp_context and it simply copies it to the destination
|
731 |
|
|
* context passed to it.
|
732 |
|
|
*
|
733 |
|
|
* Other models include (1) not doing anything, and (2) putting
|
734 |
|
|
* a "null FP status word" in the correct place in the FP context.
|
735 |
|
|
*/
|
736 |
|
|
|
737 |
|
|
#define _CPU_Context_Initialize_fp( _destination ) \
|
738 |
|
|
do { \
|
739 |
|
|
*((Context_Control_fp *) *((void **) _destination)) = _CPU_Null_fp_context; \
|
740 |
|
|
} while(0)
|
741 |
|
|
|
742 |
|
|
/* end of Context handler macros */
|
743 |
|
|
|
744 |
|
|
/* Fatal Error manager macros */
|
745 |
|
|
|
746 |
|
|
/*
|
747 |
|
|
* This routine copies _error into a known place -- typically a stack
|
748 |
|
|
* location or a register, optionally disables interrupts, and
|
749 |
|
|
* halts/stops the CPU.
|
750 |
|
|
*/
|
751 |
|
|
|
752 |
|
|
#define _CPU_Fatal_halt( _error ) \
|
753 |
|
|
a29k_fatal_error(_error)
|
754 |
|
|
|
755 |
|
|
/* end of Fatal Error manager macros */
|
756 |
|
|
|
757 |
|
|
/* Bitfield handler macros */
|
758 |
|
|
|
759 |
|
|
/*
|
760 |
|
|
* This routine sets _output to the bit number of the first bit
|
761 |
|
|
* set in _value. _value is of CPU dependent type Priority_Bit_map_control.
|
762 |
|
|
* This type may be either 16 or 32 bits wide although only the 16
|
763 |
|
|
* least significant bits will be used.
|
764 |
|
|
*
|
765 |
|
|
* There are a number of variables in using a "find first bit" type
|
766 |
|
|
* instruction.
|
767 |
|
|
*
|
768 |
|
|
* (1) What happens when run on a value of zero?
|
769 |
|
|
* (2) Bits may be numbered from MSB to LSB or vice-versa.
|
770 |
|
|
* (3) The numbering may be zero or one based.
|
771 |
|
|
* (4) The "find first bit" instruction may search from MSB or LSB.
|
772 |
|
|
*
|
773 |
|
|
* RTEMS guarantees that (1) will never happen so it is not a concern.
|
774 |
|
|
* (2),(3), (4) are handled by the macros _CPU_Priority_mask() and
|
775 |
|
|
* _CPU_Priority_bits_index(). These three form a set of routines
|
776 |
|
|
* which must logically operate together. Bits in the _value are
|
777 |
|
|
* set and cleared based on masks built by _CPU_Priority_mask().
|
778 |
|
|
* The basic major and minor values calculated by _Priority_Major()
|
779 |
|
|
* and _Priority_Minor() are "massaged" by _CPU_Priority_bits_index()
|
780 |
|
|
* to properly range between the values returned by the "find first bit"
|
781 |
|
|
* instruction. This makes it possible for _Priority_Get_highest() to
|
782 |
|
|
* calculate the major and directly index into the minor table.
|
783 |
|
|
* This mapping is necessary to ensure that 0 (a high priority major/minor)
|
784 |
|
|
* is the first bit found.
|
785 |
|
|
*
|
786 |
|
|
* This entire "find first bit" and mapping process depends heavily
|
787 |
|
|
* on the manner in which a priority is broken into a major and minor
|
788 |
|
|
* components with the major being the 4 MSB of a priority and minor
|
789 |
|
|
* the 4 LSB. Thus (0 << 4) + 0 corresponds to priority 0 -- the highest
|
790 |
|
|
* priority. And (15 << 4) + 14 corresponds to priority 254 -- the next
|
791 |
|
|
* to the lowest priority.
|
792 |
|
|
*
|
793 |
|
|
* If your CPU does not have a "find first bit" instruction, then
|
794 |
|
|
* there are ways to make do without it. Here are a handful of ways
|
795 |
|
|
* to implement this in software:
|
796 |
|
|
*
|
797 |
|
|
* - a series of 16 bit test instructions
|
798 |
|
|
* - a "binary search using if's"
|
799 |
|
|
* - _number = 0
|
800 |
|
|
* if _value > 0x00ff
|
801 |
|
|
* _value >>=8
|
802 |
|
|
* _number = 8;
|
803 |
|
|
*
|
804 |
|
|
* if _value > 0x0000f
|
805 |
|
|
* _value >=8
|
806 |
|
|
* _number += 4
|
807 |
|
|
*
|
808 |
|
|
* _number += bit_set_table[ _value ]
|
809 |
|
|
*
|
810 |
|
|
* where bit_set_table[ 16 ] has values which indicate the first
|
811 |
|
|
* bit set
|
812 |
|
|
*/
|
813 |
|
|
|
814 |
|
|
#define CPU_USE_GENERIC_BITFIELD_CODE TRUE
|
815 |
|
|
#define CPU_USE_GENERIC_BITFIELD_DATA TRUE
|
816 |
|
|
|
817 |
|
|
#if (CPU_USE_GENERIC_BITFIELD_CODE == FALSE)
|
818 |
|
|
|
819 |
|
|
#define _CPU_Bitfield_Find_first_bit( _value, _output ) \
|
820 |
|
|
{ \
|
821 |
|
|
(_output) = 0; /* do something to prevent warnings */ \
|
822 |
|
|
}
|
823 |
|
|
|
824 |
|
|
#endif
|
825 |
|
|
|
826 |
|
|
/* end of Bitfield handler macros */
|
827 |
|
|
|
828 |
|
|
/*
|
829 |
|
|
* This routine builds the mask which corresponds to the bit fields
|
830 |
|
|
* as searched by _CPU_Bitfield_Find_first_bit(). See the discussion
|
831 |
|
|
* for that routine.
|
832 |
|
|
*/
|
833 |
|
|
|
834 |
|
|
#if (CPU_USE_GENERIC_BITFIELD_CODE == FALSE)
|
835 |
|
|
|
836 |
|
|
#define _CPU_Priority_Mask( _bit_number ) \
|
837 |
|
|
( 1 << (_bit_number) )
|
838 |
|
|
|
839 |
|
|
#endif
|
840 |
|
|
|
841 |
|
|
/*
|
842 |
|
|
* This routine translates the bit numbers returned by
|
843 |
|
|
* _CPU_Bitfield_Find_first_bit() into something suitable for use as
|
844 |
|
|
* a major or minor component of a priority. See the discussion
|
845 |
|
|
* for that routine.
|
846 |
|
|
*/
|
847 |
|
|
|
848 |
|
|
#if (CPU_USE_GENERIC_BITFIELD_CODE == FALSE)
|
849 |
|
|
|
850 |
|
|
#define _CPU_Priority_bits_index( _priority ) \
|
851 |
|
|
(_priority)
|
852 |
|
|
|
853 |
|
|
#endif
|
854 |
|
|
|
855 |
|
|
/* end of Priority handler macros */
|
856 |
|
|
|
857 |
|
|
/* functions */
|
858 |
|
|
|
859 |
|
|
/*
|
860 |
|
|
* _CPU_Initialize
|
861 |
|
|
*
|
862 |
|
|
* This routine performs CPU dependent initialization.
|
863 |
|
|
*/
|
864 |
|
|
|
865 |
|
|
void _CPU_Initialize(
|
866 |
|
|
rtems_cpu_table *cpu_table,
|
867 |
|
|
void (*thread_dispatch)()
|
868 |
|
|
);
|
869 |
|
|
|
870 |
|
|
/*
|
871 |
|
|
* _CPU_ISR_install_raw_handler
|
872 |
|
|
*
|
873 |
|
|
* This routine installs a "raw" interrupt handler directly into the
|
874 |
|
|
* processor's vector table.
|
875 |
|
|
*/
|
876 |
|
|
|
877 |
|
|
void _CPU_ISR_install_raw_handler(
|
878 |
|
|
unsigned32 vector,
|
879 |
|
|
proc_ptr new_handler,
|
880 |
|
|
proc_ptr *old_handler
|
881 |
|
|
);
|
882 |
|
|
|
883 |
|
|
/*
|
884 |
|
|
* _CPU_ISR_install_vector
|
885 |
|
|
*
|
886 |
|
|
* This routine installs an interrupt vector.
|
887 |
|
|
*/
|
888 |
|
|
|
889 |
|
|
void _CPU_ISR_install_vector(
|
890 |
|
|
unsigned32 vector,
|
891 |
|
|
proc_ptr new_handler,
|
892 |
|
|
proc_ptr *old_handler
|
893 |
|
|
);
|
894 |
|
|
|
895 |
|
|
/*
|
896 |
|
|
* _CPU_Install_interrupt_stack
|
897 |
|
|
*
|
898 |
|
|
* This routine installs the hardware interrupt stack pointer.
|
899 |
|
|
*
|
900 |
|
|
* NOTE: It need only be provided if CPU_HAS_HARDWARE_INTERRUPT_STACK
|
901 |
|
|
* is TRUE.
|
902 |
|
|
*/
|
903 |
|
|
|
904 |
|
|
void _CPU_Install_interrupt_stack( void );
|
905 |
|
|
|
906 |
|
|
/*
|
907 |
|
|
* _CPU_Internal_threads_Idle_thread_body
|
908 |
|
|
*
|
909 |
|
|
* This routine is the CPU dependent IDLE thread body.
|
910 |
|
|
*
|
911 |
|
|
* NOTE: It need only be provided if CPU_PROVIDES_IDLE_THREAD_BODY
|
912 |
|
|
* is TRUE.
|
913 |
|
|
*/
|
914 |
|
|
|
915 |
|
|
void _CPU_Internal_threads_Idle_thread_body( void );
|
916 |
|
|
|
917 |
|
|
/*
|
918 |
|
|
* _CPU_Context_switch
|
919 |
|
|
*
|
920 |
|
|
* This routine switches from the run context to the heir context.
|
921 |
|
|
*/
|
922 |
|
|
|
923 |
|
|
void _CPU_Context_switch(
|
924 |
|
|
Context_Control *run,
|
925 |
|
|
Context_Control *heir
|
926 |
|
|
);
|
927 |
|
|
|
928 |
|
|
/*
|
929 |
|
|
* _CPU_Context_restore
|
930 |
|
|
*
|
931 |
|
|
* This routine is generally used only to restart self in an
|
932 |
|
|
* efficient manner. It may simply be a label in _CPU_Context_switch.
|
933 |
|
|
*
|
934 |
|
|
* NOTE: May be unnecessary to reload some registers.
|
935 |
|
|
*/
|
936 |
|
|
|
937 |
|
|
void _CPU_Context_restore(
|
938 |
|
|
Context_Control *new_context
|
939 |
|
|
);
|
940 |
|
|
|
941 |
|
|
/*
|
942 |
|
|
* _CPU_Context_save_fp
|
943 |
|
|
*
|
944 |
|
|
* This routine saves the floating point context passed to it.
|
945 |
|
|
*/
|
946 |
|
|
|
947 |
|
|
void _CPU_Context_save_fp(
|
948 |
|
|
void **fp_context_ptr
|
949 |
|
|
);
|
950 |
|
|
|
951 |
|
|
/*
|
952 |
|
|
* _CPU_Context_restore_fp
|
953 |
|
|
*
|
954 |
|
|
* This routine restores the floating point context passed to it.
|
955 |
|
|
*/
|
956 |
|
|
|
957 |
|
|
void _CPU_Context_restore_fp(
|
958 |
|
|
void **fp_context_ptr
|
959 |
|
|
);
|
960 |
|
|
|
961 |
|
|
/* The following routine swaps the endian format of an unsigned int.
|
962 |
|
|
* It must be static because it is referenced indirectly.
|
963 |
|
|
*
|
964 |
|
|
* This version will work on any processor, but if there is a better
|
965 |
|
|
* way for your CPU PLEASE use it. The most common way to do this is to:
|
966 |
|
|
*
|
967 |
|
|
* swap least significant two bytes with 16-bit rotate
|
968 |
|
|
* swap upper and lower 16-bits
|
969 |
|
|
* swap most significant two bytes with 16-bit rotate
|
970 |
|
|
*
|
971 |
|
|
* Some CPUs have special instructions which swap a 32-bit quantity in
|
972 |
|
|
* a single instruction (e.g. i486). It is probably best to avoid
|
973 |
|
|
* an "endian swapping control bit" in the CPU. One good reason is
|
974 |
|
|
* that interrupts would probably have to be disabled to insure that
|
975 |
|
|
* an interrupt does not try to access the same "chunk" with the wrong
|
976 |
|
|
* endian. Another good reason is that on some CPUs, the endian bit
|
977 |
|
|
* endianness for ALL fetches -- both code and data -- so the code
|
978 |
|
|
* will be fetched incorrectly.
|
979 |
|
|
*/
|
980 |
|
|
|
981 |
|
|
#define CPU_swap_u32( value ) \
|
982 |
|
|
((value&0xff) << 24) | (((value >> 8)&0xff) << 16) | \
|
983 |
|
|
(((value >> 16)&0xff) << 8) | ((value>>24)&0xff)
|
984 |
|
|
|
985 |
|
|
#define CPU_swap_u16( value ) \
|
986 |
|
|
(((value&0xff) << 8) | ((value >> 8)&0xff))
|
987 |
|
|
|
988 |
|
|
#ifdef __cplusplus
|
989 |
|
|
}
|
990 |
|
|
#endif
|
991 |
|
|
|
992 |
|
|
#endif
|