source: rtems/cpukit/score/cpu/or32/rtems/score/cpu.h @ 3b1c100

4.104.114.84.95
Last change on this file since 3b1c100 was 3b1c100, checked in by Joel Sherrill <joel.sherrill@…>, on Sep 26, 2003 at 9:56:41 PM

2003-09-26 Joel Sherrill <joel@…>

  • rtems/score/cpu.h: Obsoleting HP PA-RISC port and removing all references.
  • Property mode set to 100644
File size: 33.7 KB
Line 
1/*  cpu.h
2 *
3 *  This include file contains macros pertaining to the Opencores
4 *  or1k processor family.
5 *
6 *  COPYRIGHT (c) 1989-1999.
7 *  On-Line Applications Research Corporation (OAR).
8 *
9 *  The license and distribution terms for this file may be
10 *  found in the file LICENSE in this distribution or at
11 *  http://www.rtems.com/license/LICENSE.
12 *
13 *  This file adapted from no_cpu example of the RTEMS distribution.
14 *  The body has been modified for the Opencores Or1k implementation by
15 *  Chris Ziomkowski. <chris@asics.ws>
16 *
17 */
18
19#ifndef _OR1K_CPU_h
20#define _OR1K_CPU_h
21
22#ifdef __cplusplus
23extern "C" {
24#endif
25
26#include "rtems/score/or32.h"            /* pick up machine definitions */
27#ifndef ASM
28#include "rtems/score/types.h"
29#endif
30
31/* conditional compilation parameters */
32
33/*
34 *  Should the calls to _Thread_Enable_dispatch be inlined?
35 *
36 *  If TRUE, then they are inlined.
37 *  If FALSE, then a subroutine call is made.
38 *
39 *  Basically this is an example of the classic trade-off of size
40 *  versus speed.  Inlining the call (TRUE) typically increases the
41 *  size of RTEMS while speeding up the enabling of dispatching.
42 *  [NOTE: In general, the _Thread_Dispatch_disable_level will
43 *  only be 0 or 1 unless you are in an interrupt handler and that
44 *  interrupt handler invokes the executive.]  When not inlined
45 *  something calls _Thread_Enable_dispatch which in turns calls
46 *  _Thread_Dispatch.  If the enable dispatch is inlined, then
47 *  one subroutine call is avoided entirely.]
48 *
49 */
50
51#define CPU_INLINE_ENABLE_DISPATCH       FALSE
52
53/*
54 *  Should the body of the search loops in _Thread_queue_Enqueue_priority
55 *  be unrolled one time?  In unrolled each iteration of the loop examines
56 *  two "nodes" on the chain being searched.  Otherwise, only one node
57 *  is examined per iteration.
58 *
59 *  If TRUE, then the loops are unrolled.
60 *  If FALSE, then the loops are not unrolled.
61 *
62 *  The primary factor in making this decision is the cost of disabling
63 *  and enabling interrupts (_ISR_Flash) versus the cost of rest of the
64 *  body of the loop.  On some CPUs, the flash is more expensive than
65 *  one iteration of the loop body.  In this case, it might be desirable
66 *  to unroll the loop.  It is important to note that on some CPUs, this
67 *  code is the longest interrupt disable period in RTEMS.  So it is
68 *  necessary to strike a balance when setting this parameter.
69 *
70 */
71
72#define CPU_UNROLL_ENQUEUE_PRIORITY      TRUE
73
74/*
75 *  Does RTEMS manage a dedicated interrupt stack in software?
76 *
77 *  If TRUE, then a stack is allocated in _ISR_Handler_initialization.
78 *  If FALSE, nothing is done.
79 *
80 *  If the CPU supports a dedicated interrupt stack in hardware,
81 *  then it is generally the responsibility of the BSP to allocate it
82 *  and set it up.
83 *
84 *  If the CPU does not support a dedicated interrupt stack, then
85 *  the porter has two options: (1) execute interrupts on the
86 *  stack of the interrupted task, and (2) have RTEMS manage a dedicated
87 *  interrupt stack.
88 *
89 *  If this is TRUE, CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
90 *
91 *  Only one of CPU_HAS_SOFTWARE_INTERRUPT_STACK and
92 *  CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE.  It is
93 *  possible that both are FALSE for a particular CPU.  Although it
94 *  is unclear what that would imply about the interrupt processing
95 *  procedure on that CPU.
96 *
97 *  For the first cut of an Or1k implementation, let's not worry
98 *  about this, and assume that our C code will autoperform any
99 *  frame/stack allocation for us when the procedure is entered.
100 *  If we write assembly code, we may have to deal with this manually.
101 *  This can be changed later if we find it is impossible. This
102 *  behavior is desireable as it allows us to work in low memory
103 *  environments where we don't have room for a dedicated stack.
104 */
105
106#define CPU_HAS_SOFTWARE_INTERRUPT_STACK FALSE
107
108/*
109 *  Does this CPU have hardware support for a dedicated interrupt stack?
110 *
111 *  If TRUE, then it must be installed during initialization.
112 *  If FALSE, then no installation is performed.
113 *
114 *  If this is TRUE, CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
115 *
116 *  Only one of CPU_HAS_SOFTWARE_INTERRUPT_STACK and
117 *  CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE.  It is
118 *  possible that both are FALSE for a particular CPU.  Although it
119 *  is unclear what that would imply about the interrupt processing
120 *  procedure on that CPU.
121 *
122 */
123
124#define CPU_HAS_HARDWARE_INTERRUPT_STACK FALSE
125
126/*
127 *  Does RTEMS allocate a dedicated interrupt stack in the Interrupt Manager?
128 *
129 *  If TRUE, then the memory is allocated during initialization.
130 *  If FALSE, then the memory is allocated during initialization.
131 *
132 *  This should be TRUE is CPU_HAS_SOFTWARE_INTERRUPT_STACK is TRUE
133 *  or CPU_INSTALL_HARDWARE_INTERRUPT_STACK is TRUE.
134 *
135 */
136
137#define CPU_ALLOCATE_INTERRUPT_STACK FALSE
138
139/*
140 *  Does the RTEMS invoke the user's ISR with the vector number and
141 *  a pointer to the saved interrupt frame (1) or just the vector
142 *  number (0)?
143 *
144 */
145
146#define CPU_ISR_PASSES_FRAME_POINTER 0
147
148/*
149 *  Does the CPU have hardware floating point?
150 *
151 *  If TRUE, then the RTEMS_FLOATING_POINT task attribute is supported.
152 *  If FALSE, then the RTEMS_FLOATING_POINT task attribute is ignored.
153 *
154 *  If there is a FP coprocessor such as the i387 or mc68881, then
155 *  the answer is TRUE.
156 *
157 *  The macro name "OR1K_HAS_FPU" should be made CPU specific.
158 *  It indicates whether or not this CPU model has FP support.  For
159 *  example, it would be possible to have an i386_nofp CPU model
160 *  which set this to false to indicate that you have an i386 without
161 *  an i387 and wish to leave floating point support out of RTEMS.
162 *
163 *  The CPU_SOFTWARE_FP is used to indicate whether or not there
164 *  is software implemented floating point that must be context
165 *  switched.  The determination of whether or not this applies
166 *  is very tool specific and the state saved/restored is also
167 *  compiler specific.
168 *
169 *  Or1k Specific Information:
170 *
171 *  At this time there are no implementations of Or1k that are
172 *  expected to implement floating point. More importantly, the
173 *  floating point architecture is expected to change significantly
174 *  before such chips are fabricated.
175 */
176
177#if ( OR1K_HAS_FPU == 1 )
178#define CPU_HARDWARE_FP     TRUE
179#define CPU_SOFTWARE_FP     FALSE
180#else
181#define CPU_HARDWARE_FP     FALSE
182#define CPU_SOFTWARE_FP     TRUE
183#endif
184
185
186/*
187 *  Are all tasks RTEMS_FLOATING_POINT tasks implicitly?
188 *
189 *  If TRUE, then the RTEMS_FLOATING_POINT task attribute is assumed.
190 *  If FALSE, then the RTEMS_FLOATING_POINT task attribute is followed.
191 *
192 *  If CPU_HARDWARE_FP is FALSE, then this should be FALSE as well.
193 *
194 */
195
196#define CPU_ALL_TASKS_ARE_FP     FALSE
197
198/*
199 *  Should the IDLE task have a floating point context?
200 *
201 *  If TRUE, then the IDLE task is created as a RTEMS_FLOATING_POINT task
202 *  and it has a floating point context which is switched in and out.
203 *  If FALSE, then the IDLE task does not have a floating point context.
204 *
205 *  Setting this to TRUE negatively impacts the time required to preempt
206 *  the IDLE task from an interrupt because the floating point context
207 *  must be saved as part of the preemption.
208 *
209 */
210
211#define CPU_IDLE_TASK_IS_FP      FALSE
212
213/*
214 *  Should the saving of the floating point registers be deferred
215 *  until a context switch is made to another different floating point
216 *  task?
217 *
218 *  If TRUE, then the floating point context will not be stored until
219 *  necessary.  It will remain in the floating point registers and not
220 *  disturned until another floating point task is switched to.
221 *
222 *  If FALSE, then the floating point context is saved when a floating
223 *  point task is switched out and restored when the next floating point
224 *  task is restored.  The state of the floating point registers between
225 *  those two operations is not specified.
226 *
227 *  If the floating point context does NOT have to be saved as part of
228 *  interrupt dispatching, then it should be safe to set this to TRUE.
229 *
230 *  Setting this flag to TRUE results in using a different algorithm
231 *  for deciding when to save and restore the floating point context.
232 *  The deferred FP switch algorithm minimizes the number of times
233 *  the FP context is saved and restored.  The FP context is not saved
234 *  until a context switch is made to another, different FP task.
235 *  Thus in a system with only one FP task, the FP context will never
236 *  be saved or restored.
237 *
238 */
239
240#define CPU_USE_DEFERRED_FP_SWITCH       TRUE
241
242/*
243 *  Does this port provide a CPU dependent IDLE task implementation?
244 *
245 *  If TRUE, then the routine _CPU_Thread_Idle_body
246 *  must be provided and is the default IDLE thread body instead of
247 *  _CPU_Thread_Idle_body.
248 *
249 *  If FALSE, then use the generic IDLE thread body if the BSP does
250 *  not provide one.
251 *
252 *  This is intended to allow for supporting processors which have
253 *  a low power or idle mode.  When the IDLE thread is executed, then
254 *  the CPU can be powered down.
255 *
256 *  The order of precedence for selecting the IDLE thread body is:
257 *
258 *    1.  BSP provided
259 *    2.  CPU dependent (if provided)
260 *    3.  generic (if no BSP and no CPU dependent)
261 *
262 */
263
264#define CPU_PROVIDES_IDLE_THREAD_BODY    FALSE
265
266/*
267 *  Does the stack grow up (toward higher addresses) or down
268 *  (toward lower addresses)?
269 *
270 *  If TRUE, then the grows upward.
271 *  If FALSE, then the grows toward smaller addresses.
272 *
273 *  Or1k Specific Information:
274 * 
275 *  Previously I had misread the documentation and set this
276 *  to true. Surprisingly, it seemed to work anyway. I'm
277 *  therefore not 100% sure exactly what this does. It should
278 *  be correct as it is now, however.
279 */
280
281#define CPU_STACK_GROWS_UP               FALSE
282
283/*
284 *  The following is the variable attribute used to force alignment
285 *  of critical RTEMS structures.  On some processors it may make
286 *  sense to have these aligned on tighter boundaries than
287 *  the minimum requirements of the compiler in order to have as
288 *  much of the critical data area as possible in a cache line.
289 *
290 *  The placement of this macro in the declaration of the variables
291 *  is based on the syntactically requirements of the GNU C
292 *  "__attribute__" extension.  For example with GNU C, use
293 *  the following to force a structures to a 32 byte boundary.
294 *
295 *      __attribute__ ((aligned (32)))
296 *
297 *  NOTE:  Currently only the Priority Bit Map table uses this feature.
298 *         To benefit from using this, the data must be heavily
299 *         used so it will stay in the cache and used frequently enough
300 *         in the executive to justify turning this on.
301 *
302 */
303
304#define CPU_STRUCTURE_ALIGNMENT __attribute__ ((aligned (32)))
305
306/*
307 *  Define what is required to specify how the network to host conversion
308 *  routines are handled.
309 *
310 *  Or1k Specific Information:
311 *
312 *  This version of RTEMS is designed specifically to run with
313 *  big endian architectures. If you want little endian, you'll
314 *  have to make the appropriate adjustments here and write
315 *  efficient routines for byte swapping. The Or1k architecture
316 *  doesn't do this very well.
317 */
318
319#define CPU_HAS_OWN_HOST_TO_NETWORK_ROUTINES     FALSE
320#define CPU_BIG_ENDIAN                           TRUE
321#define CPU_LITTLE_ENDIAN                        FALSE
322
323/*
324 *  The following defines the number of bits actually used in the
325 *  interrupt field of the task mode.  How those bits map to the
326 *  CPU interrupt levels is defined by the routine _CPU_ISR_Set_level().
327 *
328 */
329
330#define CPU_MODES_INTERRUPT_MASK   0x00000001
331
332/*
333 *  Processor defined structures
334 *
335 *  Examples structures include the descriptor tables from the i386
336 *  and the processor control structure on the i960ca.
337 *
338 */
339
340
341/*
342 * Contexts
343 *
344 *  Generally there are 2 types of context to save.
345 *     1. Interrupt registers to save
346 *     2. Task level registers to save
347 *
348 *  This means we have the following 3 context items:
349 *     1. task level context stuff::  Context_Control
350 *     2. floating point task stuff:: Context_Control_fp
351 *     3. special interrupt level context :: Context_Control_interrupt
352 *
353 *  On some processors, it is cost-effective to save only the callee
354 *  preserved registers during a task context switch.  This means
355 *  that the ISR code needs to save those registers which do not
356 *  persist across function calls.  It is not mandatory to make this
357 *  distinctions between the caller/callee saves registers for the
358 *  purpose of minimizing context saved during task switch and on interrupts.
359 *  If the cost of saving extra registers is minimal, simplicity is the
360 *  choice.  Save the same context on interrupt entry as for tasks in
361 *  this case.
362 *
363 *  Additionally, if gdb is to be made aware of RTEMS tasks for this CPU, then
364 *  care should be used in designing the context area.
365 *
366 *  On some CPUs with hardware floating point support, the Context_Control_fp
367 *  structure will not be used or it simply consist of an array of a
368 *  fixed number of bytes.   This is done when the floating point context
369 *  is dumped by a "FP save context" type instruction and the format
370 *  is not really defined by the CPU.  In this case, there is no need
371 *  to figure out the exact format -- only the size.  Of course, although
372 *  this is enough information for RTEMS, it is probably not enough for
373 *  a debugger such as gdb.  But that is another problem.
374 *
375 * 
376 */
377
378#ifdef OR1K_64BIT_ARCH
379#define or1kreg unsigned64
380#else
381#define or1kreg unsigned32
382#endif
383
384/* SR_MASK is the mask of values that will be copied to/from the status
385   register on a context switch. Some values, like the flag state, are
386   specific on the context, while others, such as interrupt enables,
387   are global. The currently defined global bits are:
388
389   0x00001 SUPV:     Supervisor mode
390   0x00002 EXR:      Exceptions on/off
391   0x00004 EIR:      Interrupts enabled/disabled
392   0x00008 DCE:      Data cache enabled/disabled
393   0x00010 ICE:      Instruction cache enabled/disabled
394   0x00020 DME:      Data MMU enabled/disabled
395   0x00040 IME:      Instruction MMU enabled/disabled
396   0x00080 LEE:      Little/Big Endian enable
397   0x00100 CE:       Context ID/shadow regs enabled/disabled
398   0x01000 OVE:      Overflow causes exception
399   0x04000 EP:       Exceptions @ 0x0 or 0xF0000000
400   0x08000 PXR:      Partial exception recognition enabled/disabled
401   0x10000 SUMRA:    SPR's accessible/inaccessible
402
403   The context specific bits are:
404
405   0x00200 F         Branch flag indicator
406   0x00400 CY        Carry flag indicator
407   0x00800 OV        Overflow flag indicator
408   0x02000 DSX       Delay slot exception occurred
409   0xF8000000 CID    Current Context ID
410*/
411
412#define SR_MASK 0xF8002E00
413
414typedef enum {
415  SR_SUPV = 0x00001,
416  SR_EXR = 0x00002,
417  SR_EIR = 0x00004,
418  SR_DCE = 0x00008,
419  SR_ICE = 0x00010,
420  SR_DME = 0x00020,
421  SR_IME = 0x00040,
422  SR_LEE = 0x00080,
423  SR_CE = 0x00100,
424  SR_F = 0x00200,
425  SR_CY = 0x00400,
426  SR_OV = 0x00800,
427  SR_OVE = 0x01000,
428  SR_DSX = 0x02000,
429  SR_EP = 0x04000,
430  SR_PXR = 0x08000,
431  SR_SUMRA = 0x10000,
432  SR_CID = 0xF8000000,
433} StatusRegisterBits;
434
435typedef struct {
436  unsigned32  sr;     /* Current status register non persistent values */
437  unsigned32  esr;    /* Saved exception status register */
438  unsigned32  ear;    /* Saved exception effective address register */
439  unsigned32  epc;    /* Saved exception PC register    */
440  or1kreg     r[31];  /* Registers */
441  or1kreg     pc;     /* Context PC 4 or 8 bytes for 64 bit alignment */
442} Context_Control;
443
444typedef int Context_Control_fp;
445typedef Context_Control CPU_Interrupt_frame;
446#define _CPU_Null_fp_context 0
447#define _CPU_Interrupt_stack_low 0
448#define _CPU_Interrupt_stack_high 0
449
450/*
451 *  The following table contains the information required to configure
452 *  the XXX processor specific parameters.
453 *
454 */
455
456typedef struct {
457  void       (*pretasking_hook)( void );
458  void       (*predriver_hook)( void );
459  void       (*postdriver_hook)( void );
460  void       (*idle_task)( void );
461  boolean      do_zero_of_workspace;
462  unsigned32   idle_task_stack_size;
463  unsigned32   interrupt_stack_size;
464  unsigned32   extra_mpci_receive_server_stack;
465  void *     (*stack_allocate_hook)( unsigned32 );
466  void       (*stack_free_hook)( void* );
467  /* end of fields required on all CPUs */
468}   rtems_cpu_table;
469
470/*
471 *  Macros to access required entires in the CPU Table are in
472 *  the file rtems/system.h.
473 *
474 */
475
476/*
477 *  Macros to access OR1K specific additions to the CPU Table
478 *
479 */
480
481/* There are no CPU specific additions to the CPU Table for this port. */
482
483/*
484 *  This variable is optional.  It is used on CPUs on which it is difficult
485 *  to generate an "uninitialized" FP context.  It is filled in by
486 *  _CPU_Initialize and copied into the task's FP context area during
487 *  _CPU_Context_Initialize.
488 *
489 */
490
491/* SCORE_EXTERN Context_Control_fp  _CPU_Null_fp_context; */
492
493/*
494 *  On some CPUs, RTEMS supports a software managed interrupt stack.
495 *  This stack is allocated by the Interrupt Manager and the switch
496 *  is performed in _ISR_Handler.  These variables contain pointers
497 *  to the lowest and highest addresses in the chunk of memory allocated
498 *  for the interrupt stack.  Since it is unknown whether the stack
499 *  grows up or down (in general), this give the CPU dependent
500 *  code the option of picking the version it wants to use.
501 *
502 *  NOTE: These two variables are required if the macro
503 *        CPU_HAS_SOFTWARE_INTERRUPT_STACK is defined as TRUE.
504 *
505 */
506
507/*
508SCORE_EXTERN void               *_CPU_Interrupt_stack_low;
509SCORE_EXTERN void               *_CPU_Interrupt_stack_high;
510*/
511
512/*
513 *  With some compilation systems, it is difficult if not impossible to
514 *  call a high-level language routine from assembly language.  This
515 *  is especially true of commercial Ada compilers and name mangling
516 *  C++ ones.  This variable can be optionally defined by the CPU porter
517 *  and contains the address of the routine _Thread_Dispatch.  This
518 *  can make it easier to invoke that routine at the end of the interrupt
519 *  sequence (if a dispatch is necessary).
520 *
521 */
522
523SCORE_EXTERN void           (*_CPU_Thread_dispatch_pointer)();
524
525/*
526 *  Nothing prevents the porter from declaring more CPU specific variables.
527 *
528 */
529
530/* XXX: if needed, put more variables here */
531
532/*
533 *  The size of the floating point context area.  On some CPUs this
534 *  will not be a "sizeof" because the format of the floating point
535 *  area is not defined -- only the size is.  This is usually on
536 *  CPUs with a "floating point save context" instruction.
537 *
538 *  Or1k Specific Information:
539 *
540 *  We don't support floating point in this version, so the size is 0
541 */
542
543#define CPU_CONTEXT_FP_SIZE 0
544
545/*
546 *  Amount of extra stack (above minimum stack size) required by
547 *  MPCI receive server thread.  Remember that in a multiprocessor
548 *  system this thread must exist and be able to process all directives.
549 *
550 */
551
552#define CPU_MPCI_RECEIVE_SERVER_EXTRA_STACK 0
553
554/*
555 *  This defines the number of entries in the ISR_Vector_table managed
556 *  by RTEMS.
557 *
558 */
559
560#define CPU_INTERRUPT_NUMBER_OF_VECTORS      16
561#define CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER  (CPU_INTERRUPT_NUMBER_OF_VECTORS - 1)
562
563/*
564 *  Should be large enough to run all RTEMS tests.  This insures
565 *  that a "reasonable" small application should not have any problems.
566 *
567 */
568
569#define CPU_STACK_MINIMUM_SIZE          4096
570
571/*
572 *  CPU's worst alignment requirement for data types on a byte boundary.  This
573 *  alignment does not take into account the requirements for the stack.
574 *
575 */
576
577#define CPU_ALIGNMENT              8
578
579/*
580 *  This number corresponds to the byte alignment requirement for the
581 *  heap handler.  This alignment requirement may be stricter than that
582 *  for the data types alignment specified by CPU_ALIGNMENT.  It is
583 *  common for the heap to follow the same alignment requirement as
584 *  CPU_ALIGNMENT.  If the CPU_ALIGNMENT is strict enough for the heap,
585 *  then this should be set to CPU_ALIGNMENT.
586 *
587 *  NOTE:  This does not have to be a power of 2 although it should be
588 *         a multiple of 2 greater than or equal to 2.  The requirement
589 *         to be a multiple of 2 is because the heap uses the least
590 *         significant field of the front and back flags to indicate
591 *         that a block is in use or free.  So you do not want any odd
592 *         length blocks really putting length data in that bit.
593 *
594 *         On byte oriented architectures, CPU_HEAP_ALIGNMENT normally will
595 *         have to be greater or equal to than CPU_ALIGNMENT to ensure that
596 *         elements allocated from the heap meet all restrictions.
597 *
598 */
599
600#define CPU_HEAP_ALIGNMENT         CPU_ALIGNMENT
601
602/*
603 *  This number corresponds to the byte alignment requirement for memory
604 *  buffers allocated by the partition manager.  This alignment requirement
605 *  may be stricter than that for the data types alignment specified by
606 *  CPU_ALIGNMENT.  It is common for the partition to follow the same
607 *  alignment requirement as CPU_ALIGNMENT.  If the CPU_ALIGNMENT is strict
608 *  enough for the partition, then this should be set to CPU_ALIGNMENT.
609 *
610 *  NOTE:  This does not have to be a power of 2.  It does have to
611 *         be greater or equal to than CPU_ALIGNMENT.
612 *
613 */
614
615#define CPU_PARTITION_ALIGNMENT    CPU_ALIGNMENT
616
617/*
618 *  This number corresponds to the byte alignment requirement for the
619 *  stack.  This alignment requirement may be stricter than that for the
620 *  data types alignment specified by CPU_ALIGNMENT.  If the CPU_ALIGNMENT
621 *  is strict enough for the stack, then this should be set to 0.
622 *
623 *  NOTE:  This must be a power of 2 either 0 or greater than CPU_ALIGNMENT.
624 *
625 */
626
627#define CPU_STACK_ALIGNMENT        0
628
629/* ISR handler macros */
630
631/*
632 *  Support routine to initialize the RTEMS vector table after it is allocated.
633 * 
634 *  NO_CPU Specific Information:
635 *
636 *  XXX document implementation including references if appropriate
637 */
638
639#define _CPU_Initialize_vectors()
640
641
642/*
643 *  Disable all interrupts for an RTEMS critical section.  The previous
644 *  level is returned in _level.
645 *
646 */
647
648#define _CPU_ISR_Disable( _isr_cookie ) \
649  { \
650    (_isr_cookie) = 0;   /* do something to prevent warnings */ \
651  }
652
653/*
654 *  Enable interrupts to the previous level (returned by _CPU_ISR_Disable).
655 *  This indicates the end of an RTEMS critical section.  The parameter
656 *  _level is not modified.
657 *
658 */
659
660#define _CPU_ISR_Enable( _isr_cookie )  \
661  { \
662  }
663
664/*
665 *  This temporarily restores the interrupt to _level before immediately
666 *  disabling them again.  This is used to divide long RTEMS critical
667 *  sections into two or more parts.  The parameter _level is not
668 * modified.
669 *
670 */
671
672#define _CPU_ISR_Flash( _isr_cookie ) \
673  { \
674  }
675
676/*
677 *  Map interrupt level in task mode onto the hardware that the CPU
678 *  actually provides.  Currently, interrupt levels which do not
679 *  map onto the CPU in a generic fashion are undefined.  Someday,
680 *  it would be nice if these were "mapped" by the application
681 *  via a callout.  For example, m68k has 8 levels 0 - 7, levels
682 *  8 - 255 would be available for bsp/application specific meaning.
683 *  This could be used to manage a programmable interrupt controller
684 *  via the rtems_task_mode directive.
685 *
686 *  The get routine usually must be implemented as a subroutine.
687 *
688 */
689
690#define _CPU_ISR_Set_level( new_level ) \
691  { \
692  }
693
694unsigned32 _CPU_ISR_Get_level( void );
695
696/* end of ISR handler macros */
697
698/* Context handler macros */
699
700/*
701 *  Initialize the context to a state suitable for starting a
702 *  task after a context restore operation.  Generally, this
703 *  involves:
704 *
705 *     - setting a starting address
706 *     - preparing the stack
707 *     - preparing the stack and frame pointers
708 *     - setting the proper interrupt level in the context
709 *     - initializing the floating point context
710 *
711 *  This routine generally does not set any unnecessary register
712 *  in the context.  The state of the "general data" registers is
713 *  undefined at task start time.
714 *
715 *  NOTE: This is_fp parameter is TRUE if the thread is to be a floating
716 *        point thread.  This is typically only used on CPUs where the
717 *        FPU may be easily disabled by software such as on the SPARC
718 *        where the PSR contains an enable FPU bit.
719 *
720 */
721
722#define _CPU_Context_Initialize( _the_context, _stack_base, _size, \
723                                 _isr, _entry_point, _is_fp ) \
724  { \
725  memset(_the_context,'\0',sizeof(Context_Control)); \
726  (_the_context)->r[1] = (unsigned32*) ((unsigned32) (_stack_base) + (_size) ); \
727  (_the_context)->r[2] = (unsigned32*) ((unsigned32) (_stack_base)); \
728  (_the_context)->sr  = (_isr) ? 0x0000001B : 0x0000001F; \
729  (_the_context)->pc  = (unsigned32*) _entry_point ; \
730  }
731
732/*
733 *  This routine is responsible for somehow restarting the currently
734 *  executing task.  If you are lucky, then all that is necessary
735 *  is restoring the context.  Otherwise, there will need to be
736 *  a special assembly routine which does something special in this
737 *  case.  Context_Restore should work most of the time.  It will
738 *  not work if restarting self conflicts with the stack frame
739 *  assumptions of restoring a context.
740 *
741 */
742
743#define _CPU_Context_Restart_self( _the_context ) \
744   _CPU_Context_restore( (_the_context) );
745
746/*
747 *  The purpose of this macro is to allow the initial pointer into
748 *  a floating point context area (used to save the floating point
749 *  context) to be at an arbitrary place in the floating point
750 *  context area.
751 *
752 *  This is necessary because some FP units are designed to have
753 *  their context saved as a stack which grows into lower addresses.
754 *  Other FP units can be saved by simply moving registers into offsets
755 *  from the base of the context area.  Finally some FP units provide
756 *  a "dump context" instruction which could fill in from high to low
757 *  or low to high based on the whim of the CPU designers.
758 *
759 */
760
761#define _CPU_Context_Fp_start( _base, _offset ) \
762   ( (void *) _Addresses_Add_offset( (_base), (_offset) ) )
763
764/*
765 *  This routine initializes the FP context area passed to it to.
766 *  There are a few standard ways in which to initialize the
767 *  floating point context.  The code included for this macro assumes
768 *  that this is a CPU in which a "initial" FP context was saved into
769 *  _CPU_Null_fp_context and it simply copies it to the destination
770 *  context passed to it.
771 *
772 *  Other models include (1) not doing anything, and (2) putting
773 *  a "null FP status word" in the correct place in the FP context.
774 *
775 */
776
777#define _CPU_Context_Initialize_fp( _destination ) \
778  { \
779   *((Context_Control_fp *) *((void **) _destination)) = _CPU_Null_fp_context; \
780  }
781
782/* end of Context handler macros */
783
784/* Fatal Error manager macros */
785
786/*
787 *  This routine copies _error into a known place -- typically a stack
788 *  location or a register, optionally disables interrupts, and
789 *  halts/stops the CPU.
790 *
791 */
792
793#define _CPU_Fatal_halt( _error ) \
794  { \
795  }
796
797/* end of Fatal Error manager macros */
798
799/* Bitfield handler macros */
800
801/*
802 *  This routine sets _output to the bit number of the first bit
803 *  set in _value.  _value is of CPU dependent type Priority_Bit_map_control.
804 *  This type may be either 16 or 32 bits wide although only the 16
805 *  least significant bits will be used.
806 *
807 *  There are a number of variables in using a "find first bit" type
808 *  instruction.
809 *
810 *    (1) What happens when run on a value of zero?
811 *    (2) Bits may be numbered from MSB to LSB or vice-versa.
812 *    (3) The numbering may be zero or one based.
813 *    (4) The "find first bit" instruction may search from MSB or LSB.
814 *
815 *  RTEMS guarantees that (1) will never happen so it is not a concern.
816 *  (2),(3), (4) are handled by the macros _CPU_Priority_mask() and
817 *  _CPU_Priority_bits_index().  These three form a set of routines
818 *  which must logically operate together.  Bits in the _value are
819 *  set and cleared based on masks built by _CPU_Priority_mask().
820 *  The basic major and minor values calculated by _Priority_Major()
821 *  and _Priority_Minor() are "massaged" by _CPU_Priority_bits_index()
822 *  to properly range between the values returned by the "find first bit"
823 *  instruction.  This makes it possible for _Priority_Get_highest() to
824 *  calculate the major and directly index into the minor table.
825 *  This mapping is necessary to ensure that 0 (a high priority major/minor)
826 *  is the first bit found.
827 *
828 *  This entire "find first bit" and mapping process depends heavily
829 *  on the manner in which a priority is broken into a major and minor
830 *  components with the major being the 4 MSB of a priority and minor
831 *  the 4 LSB.  Thus (0 << 4) + 0 corresponds to priority 0 -- the highest
832 *  priority.  And (15 << 4) + 14 corresponds to priority 254 -- the next
833 *  to the lowest priority.
834 *
835 *  If your CPU does not have a "find first bit" instruction, then
836 *  there are ways to make do without it.  Here are a handful of ways
837 *  to implement this in software:
838 *
839 *    - a series of 16 bit test instructions
840 *    - a "binary search using if's"
841 *    - _number = 0
842 *      if _value > 0x00ff
843 *        _value >>=8
844 *        _number = 8;
845 *
846 *      if _value > 0x0000f
847 *        _value >=8
848 *        _number += 4
849 *
850 *      _number += bit_set_table[ _value ]
851 *
852 *    where bit_set_table[ 16 ] has values which indicate the first
853 *      bit set
854 *
855 */
856
857  /* #define CPU_USE_GENERIC_BITFIELD_CODE FALSE */
858#define CPU_USE_GENERIC_BITFIELD_CODE TRUE
859#define CPU_USE_GENERIC_BITFIELD_DATA TRUE
860
861#if (CPU_USE_GENERIC_BITFIELD_CODE == FALSE)
862
863  /* Get a value between 0 and N where N is the bit size */
864  /* This routine makes use of the fact that CPUCFGR defines
865     OB32S to have value 32, and OB64S to have value 64. If
866     this ever changes then this routine will fail. */
867#define _CPU_Bitfield_Find_first_bit( _value, _output ) \
868     asm volatile ("l.mfspr %0,r0,0x2   \n\t"\
869                   "l.andi  %0,%0,0x60  \n\t"\
870                   "l.ff1   %1,%1,r0    \n\t"\
871                   "l.sub   %0,%0,%1    \n\t" : "=&r" (_output), "+r" (_value));
872
873#endif
874   
875/* end of Bitfield handler macros */
876
877/*
878 *  This routine builds the mask which corresponds to the bit fields
879 *  as searched by _CPU_Bitfield_Find_first_bit().  See the discussion
880 *  for that routine.
881 *
882 */
883
884#if (CPU_USE_GENERIC_BITFIELD_CODE == FALSE)
885
886#define _CPU_Priority_Mask( _bit_number ) \
887    (1 << _bit_number)
888
889#endif
890
891/*
892 *  This routine translates the bit numbers returned by
893 *  _CPU_Bitfield_Find_first_bit() into something suitable for use as
894 *  a major or minor component of a priority.  See the discussion
895 *  for that routine.
896 *
897 */
898
899#if (CPU_USE_GENERIC_BITFIELD_CODE == FALSE)
900
901#define _CPU_Priority_bits_index( _priority ) \
902  (_priority)
903
904#endif
905
906/* end of Priority handler macros */
907
908/* functions */
909
910/*
911 *  _CPU_Initialize
912 *
913 *  This routine performs CPU dependent initialization.
914 *
915 */
916
917void _CPU_Initialize(
918  rtems_cpu_table  *cpu_table,
919  void      (*thread_dispatch)
920);
921
922/*
923 *  _CPU_ISR_install_raw_handler
924 *
925 *  This routine installs a "raw" interrupt handler directly into the
926 *  processor's vector table.
927 *
928 */
929 
930void _CPU_ISR_install_raw_handler(
931  unsigned32  vector,
932  proc_ptr    new_handler,
933  proc_ptr   *old_handler
934);
935
936/*
937 *  _CPU_ISR_install_vector
938 *
939 *  This routine installs an interrupt vector.
940 *
941 *  NO_CPU Specific Information:
942 *
943 *  XXX document implementation including references if appropriate
944 */
945
946void _CPU_ISR_install_vector(
947  unsigned32  vector,
948  proc_ptr    new_handler,
949  proc_ptr   *old_handler
950);
951
952/*
953 *  _CPU_Install_interrupt_stack
954 *
955 *  This routine installs the hardware interrupt stack pointer.
956 *
957 *  NOTE:  It need only be provided if CPU_HAS_HARDWARE_INTERRUPT_STACK
958 *         is TRUE.
959 *
960 */
961
962void _CPU_Install_interrupt_stack( void );
963
964/*
965 *  _CPU_Thread_Idle_body
966 *
967 *  This routine is the CPU dependent IDLE thread body.
968 *
969 *  NOTE:  It need only be provided if CPU_PROVIDES_IDLE_THREAD_BODY
970 *         is TRUE.
971 *
972 */
973
974void _CPU_Thread_Idle_body( void );
975
976/*
977 *  _CPU_Context_switch
978 *
979 *  This routine switches from the run context to the heir context.
980 *
981 *  Or1k Specific Information:
982 *
983 *  Please see the comments in the .c file for a description of how
984 *  this function works. There are several things to be aware of.
985 */
986
987void _CPU_Context_switch(
988  Context_Control  *run,
989  Context_Control  *heir
990);
991
992/*
993 *  _CPU_Context_restore
994 *
995 *  This routine is generally used only to restart self in an
996 *  efficient manner.  It may simply be a label in _CPU_Context_switch.
997 *
998 *  NOTE: May be unnecessary to reload some registers.
999 *
1000 */
1001
1002void _CPU_Context_restore(
1003  Context_Control *new_context
1004);
1005
1006/*
1007 *  _CPU_Context_save_fp
1008 *
1009 *  This routine saves the floating point context passed to it.
1010 *
1011 */
1012
1013void _CPU_Context_save_fp(
1014  void **fp_context_ptr
1015);
1016
1017/*
1018 *  _CPU_Context_restore_fp
1019 *
1020 *  This routine restores the floating point context passed to it.
1021 *
1022 */
1023
1024void _CPU_Context_restore_fp(
1025  void **fp_context_ptr
1026);
1027
1028/*  The following routine swaps the endian format of an unsigned int.
1029 *  It must be static because it is referenced indirectly.
1030 *
1031 *  This version will work on any processor, but if there is a better
1032 *  way for your CPU PLEASE use it.  The most common way to do this is to:
1033 *
1034 *     swap least significant two bytes with 16-bit rotate
1035 *     swap upper and lower 16-bits
1036 *     swap most significant two bytes with 16-bit rotate
1037 *
1038 *  Some CPUs have special instructions which swap a 32-bit quantity in
1039 *  a single instruction (e.g. i486).  It is probably best to avoid
1040 *  an "endian swapping control bit" in the CPU.  One good reason is
1041 *  that interrupts would probably have to be disabled to insure that
1042 *  an interrupt does not try to access the same "chunk" with the wrong
1043 *  endian.  Another good reason is that on some CPUs, the endian bit
1044 *  endianness for ALL fetches -- both code and data -- so the code
1045 *  will be fetched incorrectly.
1046 *
1047 */
1048 
1049static inline unsigned int CPU_swap_u32(
1050  unsigned int value
1051)
1052{
1053  unsigned32 byte1, byte2, byte3, byte4, swapped;
1054 
1055  byte4 = (value >> 24) & 0xff;
1056  byte3 = (value >> 16) & 0xff;
1057  byte2 = (value >> 8)  & 0xff;
1058  byte1 =  value        & 0xff;
1059 
1060  swapped = (byte1 << 24) | (byte2 << 16) | (byte3 << 8) | byte4;
1061  return( swapped );
1062}
1063
1064#define CPU_swap_u16( value ) \
1065  (((value&0xff) << 8) | ((value >> 8)&0xff))
1066
1067#ifdef __cplusplus
1068}
1069#endif
1070
1071#endif
Note: See TracBrowser for help on using the repository browser.