source: rtems/cpukit/score/cpu/m32c/rtems/score/cpu.h @ 815994f

4.11
Last change on this file since 815994f was 815994f, checked in by Sebastian Huber <sebastian.huber@…>, on Nov 25, 2012 at 4:48:11 PM

score: Add CPU_Exception_frame

Add CPU port type CPU_Exception_frame and function
_CPU_Exception_frame_print().

The CPU ports of avr, bfin, h8300, lm32, m32c, m32r, m68k, nios2, sh,
sparc64, and v850 use an empty default implementation of
_CPU_Exception_frame_print().

Add rtems_exception_frame and rtems_exception_frame_print().

Add RTEMS_FATAL_SOURCE_EXCEPTION for CPU exceptions. Use rtems_fatal()
with source RTEMS_FATAL_SOURCE_EXCEPTION in CPU ports of i386, powerpc,
and sparc for unexpected exceptions.

Add third parameter to RTEMS_BSP_CLEANUP_OPTIONS() which controls the
BSP_PRINT_EXCEPTION_CONTEXT define used in the default
bsp_fatal_extension().

Add test sptests/spfatal26.

  • Property mode set to 100644
File size: 39.0 KB
Line 
1/**
2 * @file rtems/score/cpu.h
3 */
4
5/*
6 *  This include file contains information pertaining to the XXX
7 *  processor.
8 *
9 *  @note This file is part of a porting template that is intended
10 *  to be used as the starting point when porting RTEMS to a new
11 *  CPU family.  The following needs to be done when using this as
12 *  the starting point for a new port:
13 *
14 *  + Anywhere there is an XXX, it should be replaced
15 *    with information about the CPU family being ported to.
16 *
17 *  + At the end of each comment section, there is a heading which
18 *    says "Port Specific Information:".  When porting to RTEMS,
19 *    add CPU family specific information in this section
20 */
21
22/*
23 *  COPYRIGHT (c) 1989-2008.
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.rtems.com/license/LICENSE.
29 */
30
31#ifndef _RTEMS_SCORE_CPU_H
32#define _RTEMS_SCORE_CPU_H
33
34#ifdef __cplusplus
35extern "C" {
36#endif
37
38#include <rtems/score/types.h>
39#include <rtems/score/m32c.h>
40
41/* conditional compilation parameters */
42
43#define RTEMS_USE_16_BIT_OBJECT
44
45/**
46 *  Should the calls to @ref _Thread_Enable_dispatch be inlined?
47 *
48 *  If TRUE, then they are inlined.
49 *  If FALSE, then a subroutine call is made.
50 *
51 *  This conditional is an example of the classic trade-off of size
52 *  versus speed.  Inlining the call (TRUE) typically increases the
53 *  size of RTEMS while speeding up the enabling of dispatching.
54 *
55 *  @note In general, the @ref _Thread_Dispatch_disable_level will
56 *  only be 0 or 1 unless you are in an interrupt handler and that
57 *  interrupt handler invokes the executive.]  When not inlined
58 *  something calls @ref _Thread_Enable_dispatch which in turns calls
59 *  @ref _Thread_Dispatch.  If the enable dispatch is inlined, then
60 *  one subroutine call is avoided entirely.
61 *
62 *  Port Specific Information:
63 *
64 *  XXX document implementation including references if appropriate
65 */
66#define CPU_INLINE_ENABLE_DISPATCH       FALSE
67
68/**
69 *  Should the body of the search loops in _Thread_queue_Enqueue_priority
70 *  be unrolled one time?  In unrolled each iteration of the loop examines
71 *  two "nodes" on the chain being searched.  Otherwise, only one node
72 *  is examined per iteration.
73 *
74 *  If TRUE, then the loops are unrolled.
75 *  If FALSE, then the loops are not unrolled.
76 *
77 *  The primary factor in making this decision is the cost of disabling
78 *  and enabling interrupts (_ISR_Flash) versus the cost of rest of the
79 *  body of the loop.  On some CPUs, the flash is more expensive than
80 *  one iteration of the loop body.  In this case, it might be desirable
81 *  to unroll the loop.  It is important to note that on some CPUs, this
82 *  code is the longest interrupt disable period in RTEMS.  So it is
83 *  necessary to strike a balance when setting this parameter.
84 *
85 *  Port Specific Information:
86 *
87 *  XXX document implementation including references if appropriate
88 */
89#define CPU_UNROLL_ENQUEUE_PRIORITY      TRUE
90
91/**
92 *  Does RTEMS manage a dedicated interrupt stack in software?
93 *
94 *  If TRUE, then a stack is allocated in @ref _ISR_Handler_initialization.
95 *  If FALSE, nothing is done.
96 *
97 *  If the CPU supports a dedicated interrupt stack in hardware,
98 *  then it is generally the responsibility of the BSP to allocate it
99 *  and set it up.
100 *
101 *  If the CPU does not support a dedicated interrupt stack, then
102 *  the porter has two options: (1) execute interrupts on the
103 *  stack of the interrupted task, and (2) have RTEMS manage a dedicated
104 *  interrupt stack.
105 *
106 *  If this is TRUE, @ref CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
107 *
108 *  Only one of @ref CPU_HAS_SOFTWARE_INTERRUPT_STACK and
109 *  @ref CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE.  It is
110 *  possible that both are FALSE for a particular CPU.  Although it
111 *  is unclear what that would imply about the interrupt processing
112 *  procedure on that CPU.
113 *
114 *  Port Specific Information:
115 *
116 *  XXX document implementation including references if appropriate
117 */
118#define CPU_HAS_SOFTWARE_INTERRUPT_STACK FALSE
119
120/**
121 *  Does the CPU follow the simple vectored interrupt model?
122 *
123 *  If TRUE, then RTEMS allocates the vector table it internally manages.
124 *  If FALSE, then the BSP is assumed to allocate and manage the vector
125 *  table
126 *
127 *  Port Specific Information:
128 *
129 *  XXX document implementation including references if appropriate
130 */
131#define CPU_SIMPLE_VECTORED_INTERRUPTS TRUE
132
133/**
134 *  Does this CPU have hardware support for a dedicated interrupt stack?
135 *
136 *  If TRUE, then it must be installed during initialization.
137 *  If FALSE, then no installation is performed.
138 *
139 *  If this is TRUE, @ref CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
140 *
141 *  Only one of @ref CPU_HAS_SOFTWARE_INTERRUPT_STACK and
142 *  @ref CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE.  It is
143 *  possible that both are FALSE for a particular CPU.  Although it
144 *  is unclear what that would imply about the interrupt processing
145 *  procedure on that CPU.
146 *
147 *  Port Specific Information:
148 *
149 *  XXX document implementation including references if appropriate
150 */
151#define CPU_HAS_HARDWARE_INTERRUPT_STACK TRUE
152
153/**
154 *  Does RTEMS allocate a dedicated interrupt stack in the Interrupt Manager?
155 *
156 *  If TRUE, then the memory is allocated during initialization.
157 *  If FALSE, then the memory is allocated during initialization.
158 *
159 *  This should be TRUE is CPU_HAS_SOFTWARE_INTERRUPT_STACK is TRUE.
160 *
161 *  Port Specific Information:
162 *
163 *  XXX document implementation including references if appropriate
164 */
165#define CPU_ALLOCATE_INTERRUPT_STACK TRUE
166
167/**
168 *  Does the RTEMS invoke the user's ISR with the vector number and
169 *  a pointer to the saved interrupt frame (1) or just the vector
170 *  number (0)?
171 *
172 *  Port Specific Information:
173 *
174 *  XXX document implementation including references if appropriate
175 */
176#define CPU_ISR_PASSES_FRAME_POINTER 0
177
178/**
179 *  @def CPU_HARDWARE_FP
180 *
181 *  Does the CPU have hardware floating point?
182 *
183 *  If TRUE, then the RTEMS_FLOATING_POINT task attribute is supported.
184 *  If FALSE, then the RTEMS_FLOATING_POINT task attribute is ignored.
185 *
186 *  If there is a FP coprocessor such as the i387 or mc68881, then
187 *  the answer is TRUE.
188 *
189 *  The macro name "M32C_HAS_FPU" should be made CPU specific.
190 *  It indicates whether or not this CPU model has FP support.  For
191 *  example, it would be possible to have an i386_nofp CPU model
192 *  which set this to false to indicate that you have an i386 without
193 *  an i387 and wish to leave floating point support out of RTEMS.
194 */
195
196/**
197 *  @def CPU_SOFTWARE_FP
198 *
199 *  Does the CPU have no hardware floating point and GCC provides a
200 *  software floating point implementation which must be context
201 *  switched?
202 *
203 *  This feature conditional is used to indicate whether or not there
204 *  is software implemented floating point that must be context
205 *  switched.  The determination of whether or not this applies
206 *  is very tool specific and the state saved/restored is also
207 *  compiler specific.
208 *
209 *  Port Specific Information:
210 *
211 *  XXX document implementation including references if appropriate
212 */
213#if ( M32C_HAS_FPU == 1 )
214#define CPU_HARDWARE_FP     TRUE
215#else
216#define CPU_HARDWARE_FP     FALSE
217#endif
218#define CPU_SOFTWARE_FP     FALSE
219
220#define CPU_CONTEXT_FP_SIZE 0
221
222/**
223 *  Are all tasks RTEMS_FLOATING_POINT tasks implicitly?
224 *
225 *  If TRUE, then the RTEMS_FLOATING_POINT task attribute is assumed.
226 *  If FALSE, then the RTEMS_FLOATING_POINT task attribute is followed.
227 *
228 *  So far, the only CPUs in which this option has been used are the
229 *  HP PA-RISC and PowerPC.  On the PA-RISC, The HP C compiler and
230 *  gcc both implicitly used the floating point registers to perform
231 *  integer multiplies.  Similarly, the PowerPC port of gcc has been
232 *  seen to allocate floating point local variables and touch the FPU
233 *  even when the flow through a subroutine (like vfprintf()) might
234 *  not use floating point formats.
235 *
236 *  If a function which you would not think utilize the FP unit DOES,
237 *  then one can not easily predict which tasks will use the FP hardware.
238 *  In this case, this option should be TRUE.
239 *
240 *  If @ref CPU_HARDWARE_FP is FALSE, then this should be FALSE as well.
241 *
242 *  Port Specific Information:
243 *
244 *  XXX document implementation including references if appropriate
245 */
246#define CPU_ALL_TASKS_ARE_FP     TRUE
247
248/**
249 *  Should the IDLE task have a floating point context?
250 *
251 *  If TRUE, then the IDLE task is created as a RTEMS_FLOATING_POINT task
252 *  and it has a floating point context which is switched in and out.
253 *  If FALSE, then the IDLE task does not have a floating point context.
254 *
255 *  Setting this to TRUE negatively impacts the time required to preempt
256 *  the IDLE task from an interrupt because the floating point context
257 *  must be saved as part of the preemption.
258 *
259 *  Port Specific Information:
260 *
261 *  XXX document implementation including references if appropriate
262 */
263#define CPU_IDLE_TASK_IS_FP      FALSE
264
265/**
266 *  Should the saving of the floating point registers be deferred
267 *  until a context switch is made to another different floating point
268 *  task?
269 *
270 *  If TRUE, then the floating point context will not be stored until
271 *  necessary.  It will remain in the floating point registers and not
272 *  disturned until another floating point task is switched to.
273 *
274 *  If FALSE, then the floating point context is saved when a floating
275 *  point task is switched out and restored when the next floating point
276 *  task is restored.  The state of the floating point registers between
277 *  those two operations is not specified.
278 *
279 *  If the floating point context does NOT have to be saved as part of
280 *  interrupt dispatching, then it should be safe to set this to TRUE.
281 *
282 *  Setting this flag to TRUE results in using a different algorithm
283 *  for deciding when to save and restore the floating point context.
284 *  The deferred FP switch algorithm minimizes the number of times
285 *  the FP context is saved and restored.  The FP context is not saved
286 *  until a context switch is made to another, different FP task.
287 *  Thus in a system with only one FP task, the FP context will never
288 *  be saved or restored.
289 *
290 *  Port Specific Information:
291 *
292 *  XXX document implementation including references if appropriate
293 */
294#define CPU_USE_DEFERRED_FP_SWITCH       TRUE
295
296/**
297 *  Does this port provide a CPU dependent IDLE task implementation?
298 *
299 *  If TRUE, then the routine @ref _CPU_Thread_Idle_body
300 *  must be provided and is the default IDLE thread body instead of
301 *  @ref _CPU_Thread_Idle_body.
302 *
303 *  If FALSE, then use the generic IDLE thread body if the BSP does
304 *  not provide one.
305 *
306 *  This is intended to allow for supporting processors which have
307 *  a low power or idle mode.  When the IDLE thread is executed, then
308 *  the CPU can be powered down.
309 *
310 *  The order of precedence for selecting the IDLE thread body is:
311 *
312 *    -#  BSP provided
313 *    -#  CPU dependent (if provided)
314 *    -#  generic (if no BSP and no CPU dependent)
315 *
316 *  Port Specific Information:
317 *
318 *  XXX document implementation including references if appropriate
319 */
320#define CPU_PROVIDES_IDLE_THREAD_BODY    TRUE
321
322/**
323 *  Does the stack grow up (toward higher addresses) or down
324 *  (toward lower addresses)?
325 *
326 *  If TRUE, then the grows upward.
327 *  If FALSE, then the grows toward smaller addresses.
328 *
329 *  Port Specific Information:
330 *
331 *  XXX document implementation including references if appropriate
332 */
333#define CPU_STACK_GROWS_UP               TRUE
334
335/**
336 *  The following is the variable attribute used to force alignment
337 *  of critical RTEMS structures.  On some processors it may make
338 *  sense to have these aligned on tighter boundaries than
339 *  the minimum requirements of the compiler in order to have as
340 *  much of the critical data area as possible in a cache line.
341 *
342 *  The placement of this macro in the declaration of the variables
343 *  is based on the syntactically requirements of the GNU C
344 *  "__attribute__" extension.  For example with GNU C, use
345 *  the following to force a structures to a 32 byte boundary.
346 *
347 *      __attribute__ ((aligned (32)))
348 *
349 *  @note Currently only the Priority Bit Map table uses this feature.
350 *        To benefit from using this, the data must be heavily
351 *        used so it will stay in the cache and used frequently enough
352 *        in the executive to justify turning this on.
353 *
354 *  Port Specific Information:
355 *
356 *  XXX document implementation including references if appropriate
357 */
358#define CPU_STRUCTURE_ALIGNMENT          __attribute__ ((aligned (2)))
359
360#define CPU_TIMESTAMP_USE_STRUCT_TIMESPEC TRUE
361
362/**
363 *  @defgroup CPUEndian Processor Dependent Endianness Support
364 *
365 *  This group assists in issues related to processor endianness.
366 */
367
368/**
369 *  @ingroup CPUEndian
370 *  Define what is required to specify how the network to host conversion
371 *  routines are handled.
372 *
373 *  @note @a CPU_BIG_ENDIAN and @a CPU_LITTLE_ENDIAN should NOT have the
374 *  same values.
375 *
376 *  @see CPU_LITTLE_ENDIAN
377 *
378 *  Port Specific Information:
379 *
380 *  XXX document implementation including references if appropriate
381 */
382#define CPU_BIG_ENDIAN                           TRUE
383
384/**
385 *  @ingroup CPUEndian
386 *  Define what is required to specify how the network to host conversion
387 *  routines are handled.
388 *
389 *  @note @ref CPU_BIG_ENDIAN and @ref CPU_LITTLE_ENDIAN should NOT have the
390 *  same values.
391 *
392 *  @see CPU_BIG_ENDIAN
393 *
394 *  Port Specific Information:
395 *
396 *  XXX document implementation including references if appropriate
397 */
398#define CPU_LITTLE_ENDIAN                        FALSE
399
400/**
401 *  @ingroup CPUInterrupt
402 *  The following defines the number of bits actually used in the
403 *  interrupt field of the task mode.  How those bits map to the
404 *  CPU interrupt levels is defined by the routine @ref _CPU_ISR_Set_level.
405 *
406 *  Port Specific Information:
407 *
408 *  XXX document implementation including references if appropriate
409 */
410#define CPU_MODES_INTERRUPT_MASK   0x00000001
411
412/*
413 *  Processor defined structures required for cpukit/score.
414 *
415 *  Port Specific Information:
416 *
417 *  XXX document implementation including references if appropriate
418 */
419
420/* may need to put some structures here.  */
421
422/**
423 * @defgroup CPUContext Processor Dependent Context Management
424 *
425 *  From the highest level viewpoint, there are 2 types of context to save.
426 *
427 *     -# Interrupt registers to save
428 *     -# Task level registers to save
429 *
430 *  Since RTEMS handles integer and floating point contexts separately, this
431 *  means we have the following 3 context items:
432 *
433 *     -# task level context stuff::  Context_Control
434 *     -# floating point task stuff:: Context_Control_fp
435 *     -# special interrupt level context :: CPU_Interrupt_frame
436 *
437 *  On some processors, it is cost-effective to save only the callee
438 *  preserved registers during a task context switch.  This means
439 *  that the ISR code needs to save those registers which do not
440 *  persist across function calls.  It is not mandatory to make this
441 *  distinctions between the caller/callee saves registers for the
442 *  purpose of minimizing context saved during task switch and on interrupts.
443 *  If the cost of saving extra registers is minimal, simplicity is the
444 *  choice.  Save the same context on interrupt entry as for tasks in
445 *  this case.
446 *
447 *  Additionally, if gdb is to be made aware of RTEMS tasks for this CPU, then
448 *  care should be used in designing the context area.
449 *
450 *  On some CPUs with hardware floating point support, the Context_Control_fp
451 *  structure will not be used or it simply consist of an array of a
452 *  fixed number of bytes.   This is done when the floating point context
453 *  is dumped by a "FP save context" type instruction and the format
454 *  is not really defined by the CPU.  In this case, there is no need
455 *  to figure out the exact format -- only the size.  Of course, although
456 *  this is enough information for RTEMS, it is probably not enough for
457 *  a debugger such as gdb.  But that is another problem.
458 *
459 *  Port Specific Information:
460 *
461 *  XXX document implementation including references if appropriate
462 */
463
464/**
465 *  @ingroup CPUContext Management
466 *  This defines the minimal set of integer and processor state registers
467 *  that must be saved during a voluntary context switch from one thread
468 *  to another.
469 */
470typedef struct {
471  /** This will contain the stack pointer. */
472  uint32_t sp;
473  /** This will contain the frame base pointer. */
474  uint32_t fb;
475} Context_Control;
476
477/**
478 *  @ingroup CPUContext Management
479 *
480 *  This macro returns the stack pointer associated with @a _context.
481 *
482 *  @param[in] _context is the thread context area to access
483 *
484 *  @return This method returns the stack pointer.
485 */
486#define _CPU_Context_Get_SP( _context ) \
487  (_context)->sp
488
489/**
490 *  @ingroup CPUContext Management
491 *  This defines the set of integer and processor state registers that must
492 *  be saved during an interrupt.  This set does not include any which are
493 *  in @ref Context_Control.
494 */
495typedef struct {
496    /** This field is a hint that a port will have a number of integer
497     *  registers that need to be saved when an interrupt occurs or
498     *  when a context switch occurs at the end of an ISR.
499     */
500    uint32_t   special_interrupt_register;
501} CPU_Interrupt_frame;
502
503/**
504 *  @defgroup CPUInterrupt Processor Dependent Interrupt Management
505 *
506 *  On some CPUs, RTEMS supports a software managed interrupt stack.
507 *  This stack is allocated by the Interrupt Manager and the switch
508 *  is performed in @ref _ISR_Handler.  These variables contain pointers
509 *  to the lowest and highest addresses in the chunk of memory allocated
510 *  for the interrupt stack.  Since it is unknown whether the stack
511 *  grows up or down (in general), this give the CPU dependent
512 *  code the option of picking the version it wants to use.
513 *
514 *  @note These two variables are required if the macro
515 *        @ref CPU_HAS_SOFTWARE_INTERRUPT_STACK is defined as TRUE.
516 *
517 *  Port Specific Information:
518 *
519 *  XXX document implementation including references if appropriate
520 */
521
522/*
523 *  Nothing prevents the porter from declaring more CPU specific variables.
524 *
525 *  Port Specific Information:
526 *
527 *  XXX document implementation including references if appropriate
528 */
529
530/* XXX: if needed, put more variables here */
531
532/**
533 *  Amount of extra stack (above minimum stack size) required by
534 *  MPCI receive server thread.  Remember that in a multiprocessor
535 *  system this thread must exist and be able to process all directives.
536 *
537 *  Port Specific Information:
538 *
539 *  XXX document implementation including references if appropriate
540 */
541#define CPU_MPCI_RECEIVE_SERVER_EXTRA_STACK 0
542
543/**
544 *  @ingroup CPUInterrupt
545 *  This defines the number of entries in the @ref _ISR_Vector_table managed
546 *  by RTEMS.
547 *
548 *  Port Specific Information:
549 *
550 *  XXX document implementation including references if appropriate
551 */
552#define CPU_INTERRUPT_NUMBER_OF_VECTORS      32
553
554/**
555 *  @ingroup CPUInterrupt
556 *  This defines the highest interrupt vector number for this port.
557 */
558#define CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER  (CPU_INTERRUPT_NUMBER_OF_VECTORS - 1)
559
560/**
561 *  @ingroup CPUInterrupt
562 *  This is defined if the port has a special way to report the ISR nesting
563 *  level.  Most ports maintain the variable @a _ISR_Nest_level.
564 */
565#define CPU_PROVIDES_ISR_IS_IN_PROGRESS FALSE
566
567/**
568 *  @ingroup CPUContext
569 *  Should be large enough to run all RTEMS tests.  This ensures
570 *  that a "reasonable" small application should not have any problems.
571 *
572 *  Port Specific Information:
573 *
574 *  XXX document implementation including references if appropriate
575 */
576#define CPU_STACK_MINIMUM_SIZE          (2048L)
577
578#ifdef __m32cm_cpu__
579  #define CPU_SIZEOF_POINTER 4
580#else
581  #define CPU_SIZEOF_POINTER 2
582#endif
583
584/**
585 *  CPU's worst alignment requirement for data types on a byte boundary.  This
586 *  alignment does not take into account the requirements for the stack.
587 *
588 *  Port Specific Information:
589 *
590 *  XXX document implementation including references if appropriate
591 */
592#define CPU_ALIGNMENT              2
593
594/**
595 *  This number corresponds to the byte alignment requirement for the
596 *  heap handler.  This alignment requirement may be stricter than that
597 *  for the data types alignment specified by @ref CPU_ALIGNMENT.  It is
598 *  common for the heap to follow the same alignment requirement as
599 *  @ref CPU_ALIGNMENT.  If the @ref CPU_ALIGNMENT is strict enough for
600 *  the heap, then this should be set to @ref CPU_ALIGNMENT.
601 *
602 *  @note  This does not have to be a power of 2 although it should be
603 *         a multiple of 2 greater than or equal to 2.  The requirement
604 *         to be a multiple of 2 is because the heap uses the least
605 *         significant field of the front and back flags to indicate
606 *         that a block is in use or free.  So you do not want any odd
607 *         length blocks really putting length data in that bit.
608 *
609 *         On byte oriented architectures, @ref CPU_HEAP_ALIGNMENT normally will
610 *         have to be greater or equal to than @ref CPU_ALIGNMENT to ensure that
611 *         elements allocated from the heap meet all restrictions.
612 *
613 *  Port Specific Information:
614 *
615 *  XXX document implementation including references if appropriate
616 */
617#define CPU_HEAP_ALIGNMENT         4
618
619/**
620 *  This number corresponds to the byte alignment requirement for memory
621 *  buffers allocated by the partition manager.  This alignment requirement
622 *  may be stricter than that for the data types alignment specified by
623 *  @ref CPU_ALIGNMENT.  It is common for the partition to follow the same
624 *  alignment requirement as @ref CPU_ALIGNMENT.  If the @ref CPU_ALIGNMENT is
625 *  strict enough for the partition, then this should be set to
626 *  @ref CPU_ALIGNMENT.
627 *
628 *  @note  This does not have to be a power of 2.  It does have to
629 *         be greater or equal to than @ref CPU_ALIGNMENT.
630 *
631 *  Port Specific Information:
632 *
633 *  XXX document implementation including references if appropriate
634 */
635#define CPU_PARTITION_ALIGNMENT    CPU_ALIGNMENT
636
637/**
638 *  This number corresponds to the byte alignment requirement for the
639 *  stack.  This alignment requirement may be stricter than that for the
640 *  data types alignment specified by @ref CPU_ALIGNMENT.  If the
641 *  @ref CPU_ALIGNMENT is strict enough for the stack, then this should be
642 *  set to 0.
643 *
644 *  @note This must be a power of 2 either 0 or greater than @ref CPU_ALIGNMENT.
645 *
646 *  Port Specific Information:
647 *
648 *  XXX document implementation including references if appropriate
649 */
650#define CPU_STACK_ALIGNMENT        0
651
652/*
653 *  ISR handler macros
654 */
655
656/**
657 *  @ingroup CPUInterrupt
658 *  Support routine to initialize the RTEMS vector table after it is allocated.
659 *
660 *  Port Specific Information:
661 *
662 *  XXX document implementation including references if appropriate
663 */
664#define _CPU_Initialize_vectors()
665
666/**
667 *  @ingroup CPUInterrupt
668 *  Disable all interrupts for an RTEMS critical section.  The previous
669 *  level is returned in @a _isr_cookie.
670 *
671 *  @param[out] _isr_cookie will contain the previous level cookie
672 *
673 *  Port Specific Information:
674 *
675 *  XXX document implementation including references if appropriate
676 */
677#define _CPU_ISR_Disable( _isr_cookie ) \
678  do { \
679    int _flg; \
680    m32c_get_flg( _flg ); \
681    _isr_cookie = _flg; \
682    __asm__ volatile( "fclr I" ); \
683  } while(0)
684
685/**
686 *  @ingroup CPUInterrupt
687 *  Enable interrupts to the previous level (returned by _CPU_ISR_Disable).
688 *  This indicates the end of an RTEMS critical section.  The parameter
689 *  @a _isr_cookie is not modified.
690 *
691 *  @param[in] _isr_cookie contain the previous level cookie
692 *
693 *  Port Specific Information:
694 *
695 *  XXX document implementation including references if appropriate
696 */
697#define _CPU_ISR_Enable(_isr_cookie) \
698  do { \
699    int _flg = (int) (_isr_cookie); \
700    m32c_set_flg( _flg ); \
701  } while(0)
702
703/**
704 *  @ingroup CPUInterrupt
705 *  This temporarily restores the interrupt to @a _isr_cookie before immediately
706 *  disabling them again.  This is used to divide long RTEMS critical
707 *  sections into two or more parts.  The parameter @a _isr_cookie is not
708 *  modified.
709 *
710 *  @param[in] _isr_cookie contain the previous level cookie
711 *
712 *  Port Specific Information:
713 *
714 *  XXX document implementation including references if appropriate
715 */
716#define _CPU_ISR_Flash( _isr_cookie ) \
717  do { \
718    int _flg = (int) (_isr_cookie); \
719    m32c_set_flg( _flg ); \
720    __asm__ volatile( "fclr I" ); \
721  } while(0)
722
723/**
724 *  @ingroup CPUInterrupt
725 *
726 *  This routine and @ref _CPU_ISR_Get_level
727 *  Map the interrupt level in task mode onto the hardware that the CPU
728 *  actually provides.  Currently, interrupt levels which do not
729 *  map onto the CPU in a generic fashion are undefined.  Someday,
730 *  it would be nice if these were "mapped" by the application
731 *  via a callout.  For example, m68k has 8 levels 0 - 7, levels
732 *  8 - 255 would be available for bsp/application specific meaning.
733 *  This could be used to manage a programmable interrupt controller
734 *  via the rtems_task_mode directive.
735 *
736 *  Port Specific Information:
737 *
738 *  XXX document implementation including references if appropriate
739 */
740#define _CPU_ISR_Set_level( _new_level ) \
741  do { \
742    if (_new_level) __asm__ volatile( "fclr I" ); \
743    else            __asm__ volatile( "fset I" ); \
744  } while(0)
745
746/**
747 *  @ingroup CPUInterrupt
748 *  Return the current interrupt disable level for this task in
749 *  the format used by the interrupt level portion of the task mode.
750 *
751 *  @note This routine usually must be implemented as a subroutine.
752 *
753 *  Port Specific Information:
754 *
755 *  XXX document implementation including references if appropriate
756 */
757uint32_t   _CPU_ISR_Get_level( void );
758
759/* end of ISR handler macros */
760
761/* Context handler macros */
762
763/**
764 *  @ingroup CPUContext
765 *  Initialize the context to a state suitable for starting a
766 *  task after a context restore operation.  Generally, this
767 *  involves:
768 *
769 *     - setting a starting address
770 *     - preparing the stack
771 *     - preparing the stack and frame pointers
772 *     - setting the proper interrupt level in the context
773 *     - initializing the floating point context
774 *
775 *  This routine generally does not set any unnecessary register
776 *  in the context.  The state of the "general data" registers is
777 *  undefined at task start time.
778 *
779 *  @param[in] _the_context is the context structure to be initialized
780 *  @param[in] _stack_base is the lowest physical address of this task's stack
781 *  @param[in] _size is the size of this task's stack
782 *  @param[in] _isr is the interrupt disable level
783 *  @param[in] _entry_point is the thread's entry point.  This is
784 *         always @a _Thread_Handler
785 *  @param[in] _is_fp is TRUE if the thread is to be a floating
786 *        point thread.  This is typically only used on CPUs where the
787 *        FPU may be easily disabled by software such as on the SPARC
788 *        where the PSR contains an enable FPU bit.
789 *
790 *  Port Specific Information:
791 *
792 *  XXX document implementation including references if appropriate
793 */
794void _CPU_Context_Initialize(
795  Context_Control  *the_context,
796  uint32_t         *stack_base,
797  size_t            size,
798  uint32_t          new_level,
799  void             *entry_point,
800  bool              is_fp
801);
802
803/**
804 *  This routine is responsible for somehow restarting the currently
805 *  executing task.  If you are lucky, then all that is necessary
806 *  is restoring the context.  Otherwise, there will need to be
807 *  a special assembly routine which does something special in this
808 *  case.  For many ports, simply adding a label to the restore path
809 *  of @ref _CPU_Context_switch will work.  On other ports, it may be
810 *  possibly to load a few arguments and jump to the restore path. It will
811 *  not work if restarting self conflicts with the stack frame
812 *  assumptions of restoring a context.
813 *
814 *  Port Specific Information:
815 *
816 *  XXX document implementation including references if appropriate
817 */
818void _CPU_Context_Restart_self(
819  Context_Control  *the_context
820);
821
822/**
823 *  @ingroup CPUContext
824 *  The purpose of this macro is to allow the initial pointer into
825 *  a floating point context area (used to save the floating point
826 *  context) to be at an arbitrary place in the floating point
827 *  context area.
828 *
829 *  This is necessary because some FP units are designed to have
830 *  their context saved as a stack which grows into lower addresses.
831 *  Other FP units can be saved by simply moving registers into offsets
832 *  from the base of the context area.  Finally some FP units provide
833 *  a "dump context" instruction which could fill in from high to low
834 *  or low to high based on the whim of the CPU designers.
835 *
836 *  @param[in] _base is the lowest physical address of the floating point
837 *         context area
838 *  @param[in] _offset is the offset into the floating point area
839 *
840 *  Port Specific Information:
841 *
842 *  XXX document implementation including references if appropriate
843 */
844#define _CPU_Context_Fp_start( _base, _offset ) \
845   ( (void *) _Addresses_Add_offset( (_base), (_offset) ) )
846
847/**
848 *  This routine initializes the FP context area passed to it to.
849 *  There are a few standard ways in which to initialize the
850 *  floating point context.  The code included for this macro assumes
851 *  that this is a CPU in which a "initial" FP context was saved into
852 *  @a _CPU_Null_fp_context and it simply copies it to the destination
853 *  context passed to it.
854 *
855 *  Other floating point context save/restore models include:
856 *    -# not doing anything, and
857 *    -# putting a "null FP status word" in the correct place in the FP context.
858 *
859 *  @param[in] _destination is the floating point context area
860 *
861 *  Port Specific Information:
862 *
863 *  XXX document implementation including references if appropriate
864 */
865#define _CPU_Context_Initialize_fp( _destination ) \
866  { \
867   *(*(_destination)) = _CPU_Null_fp_context; \
868  }
869
870/* end of Context handler macros */
871
872/* Fatal Error manager macros */
873
874/**
875 *  This routine copies _error into a known place -- typically a stack
876 *  location or a register, optionally disables interrupts, and
877 *  halts/stops the CPU.
878 *
879 *  Port Specific Information:
880 *
881 *  XXX document implementation including references if appropriate
882 */
883#define _CPU_Fatal_halt( _error ) \
884  { \
885  }
886
887/* end of Fatal Error manager macros */
888
889/* Bitfield handler macros */
890
891/**
892 *  @defgroup CPUBitfield Processor Dependent Bitfield Manipulation
893 *
894 *  This set of routines are used to implement fast searches for
895 *  the most important ready task.
896 */
897
898/**
899 *  @ingroup CPUBitfield
900 *  This definition is set to TRUE if the port uses the generic bitfield
901 *  manipulation implementation.
902 */
903#define CPU_USE_GENERIC_BITFIELD_CODE TRUE
904
905/**
906 *  @ingroup CPUBitfield
907 *  This definition is set to TRUE if the port uses the data tables provided
908 *  by the generic bitfield manipulation implementation.
909 *  This can occur when actually using the generic bitfield manipulation
910 *  implementation or when implementing the same algorithm in assembly
911 *  language for improved performance.  It is unlikely that a port will use
912 *  the data if it has a bitfield scan instruction.
913 */
914#define CPU_USE_GENERIC_BITFIELD_DATA TRUE
915
916/**
917 *  @ingroup CPUBitfield
918 *  This routine sets @a _output to the bit number of the first bit
919 *  set in @a _value.  @a _value is of CPU dependent type
920 *  @a Priority_bit_map_Control.  This type may be either 16 or 32 bits
921 *  wide although only the 16 least significant bits will be used.
922 *
923 *  There are a number of variables in using a "find first bit" type
924 *  instruction.
925 *
926 *    -# What happens when run on a value of zero?
927 *    -# Bits may be numbered from MSB to LSB or vice-versa.
928 *    -# The numbering may be zero or one based.
929 *    -# The "find first bit" instruction may search from MSB or LSB.
930 *
931 *  RTEMS guarantees that (1) will never happen so it is not a concern.
932 *  (2),(3), (4) are handled by the macros @ref _CPU_Priority_Mask and
933 *  @ref _CPU_Priority_bits_index.  These three form a set of routines
934 *  which must logically operate together.  Bits in the _value are
935 *  set and cleared based on masks built by @ref _CPU_Priority_Mask.
936 *  The basic major and minor values calculated by @ref _Priority_Major
937 *  and @ref _Priority_Minor are "massaged" by @ref _CPU_Priority_bits_index
938 *  to properly range between the values returned by the "find first bit"
939 *  instruction.  This makes it possible for @ref _Priority_Get_highest to
940 *  calculate the major and directly index into the minor table.
941 *  This mapping is necessary to ensure that 0 (a high priority major/minor)
942 *  is the first bit found.
943 *
944 *  This entire "find first bit" and mapping process depends heavily
945 *  on the manner in which a priority is broken into a major and minor
946 *  components with the major being the 4 MSB of a priority and minor
947 *  the 4 LSB.  Thus (0 << 4) + 0 corresponds to priority 0 -- the highest
948 *  priority.  And (15 << 4) + 14 corresponds to priority 254 -- the next
949 *  to the lowest priority.
950 *
951 *  If your CPU does not have a "find first bit" instruction, then
952 *  there are ways to make do without it.  Here are a handful of ways
953 *  to implement this in software:
954 *
955@verbatim
956      - a series of 16 bit test instructions
957      - a "binary search using if's"
958      - _number = 0
959        if _value > 0x00ff
960          _value >>=8
961          _number = 8;
962
963        if _value > 0x0000f
964          _value >=8
965          _number += 4
966
967        _number += bit_set_table[ _value ]
968@endverbatim
969
970 *    where bit_set_table[ 16 ] has values which indicate the first
971 *      bit set
972 *
973 *  @param[in] _value is the value to be scanned
974 *  @param[in] _output is the first bit set
975 *
976 *  Port Specific Information:
977 *
978 *  XXX document implementation including references if appropriate
979 */
980
981#if (CPU_USE_GENERIC_BITFIELD_CODE == FALSE)
982#define _CPU_Bitfield_Find_first_bit( _value, _output ) \
983  { \
984    (_output) = 0;   /* do something to prevent warnings */ \
985  }
986#endif
987
988/* end of Bitfield handler macros */
989
990/**
991 *  This routine builds the mask which corresponds to the bit fields
992 *  as searched by @ref _CPU_Bitfield_Find_first_bit.  See the discussion
993 *  for that routine.
994 *
995 *  Port Specific Information:
996 *
997 *  XXX document implementation including references if appropriate
998 */
999#if (CPU_USE_GENERIC_BITFIELD_CODE == FALSE)
1000
1001#define _CPU_Priority_Mask( _bit_number ) \
1002  ( 1 << (_bit_number) )
1003
1004#endif
1005
1006/**
1007 *  @ingroup CPUBitfield
1008 *  This routine translates the bit numbers returned by
1009 *  @ref _CPU_Bitfield_Find_first_bit into something suitable for use as
1010 *  a major or minor component of a priority.  See the discussion
1011 *  for that routine.
1012 *
1013 *  @param[in] _priority is the major or minor number to translate
1014 *
1015 *  Port Specific Information:
1016 *
1017 *  XXX document implementation including references if appropriate
1018 */
1019#if (CPU_USE_GENERIC_BITFIELD_CODE == FALSE)
1020
1021#define _CPU_Priority_bits_index( _priority ) \
1022  (_priority)
1023
1024#endif
1025
1026/* end of Priority handler macros */
1027
1028/* functions */
1029
1030/**
1031 *  This routine performs CPU dependent initialization.
1032 *
1033 *  Port Specific Information:
1034 *
1035 *  XXX document implementation including references if appropriate
1036 */
1037void _CPU_Initialize(void);
1038
1039/**
1040 *  @ingroup CPUInterrupt
1041 *  This routine installs a "raw" interrupt handler directly into the
1042 *  processor's vector table.
1043 *
1044 *  @param[in] vector is the vector number
1045 *  @param[in] new_handler is the raw ISR handler to install
1046 *  @param[in] old_handler is the previously installed ISR Handler
1047 *
1048 *  Port Specific Information:
1049 *
1050 *  XXX document implementation including references if appropriate
1051 */
1052void _CPU_ISR_install_raw_handler(
1053  uint32_t    vector,
1054  proc_ptr    new_handler,
1055  proc_ptr   *old_handler
1056);
1057
1058/**
1059 *  @ingroup CPUInterrupt
1060 *  This routine installs an interrupt vector.
1061 *
1062 *  @param[in] vector is the vector number
1063 *  @param[in] new_handler is the RTEMS ISR handler to install
1064 *  @param[in] old_handler is the previously installed ISR Handler
1065 *
1066 *  Port Specific Information:
1067 *
1068 *  XXX document implementation including references if appropriate
1069 */
1070void _CPU_ISR_install_vector(
1071  uint32_t    vector,
1072  proc_ptr    new_handler,
1073  proc_ptr   *old_handler
1074);
1075
1076/**
1077 *  @ingroup CPUInterrupt
1078 *  This routine installs the hardware interrupt stack pointer.
1079 *
1080 *  @note  It need only be provided if @ref CPU_HAS_HARDWARE_INTERRUPT_STACK
1081 *         is TRUE.
1082 *
1083 *  Port Specific Information:
1084 *
1085 *  XXX document implementation including references if appropriate
1086 */
1087void _CPU_Install_interrupt_stack( void );
1088
1089/**
1090 *  This routine is the CPU dependent IDLE thread body.
1091 *
1092 *  @note  It need only be provided if @ref CPU_PROVIDES_IDLE_THREAD_BODY
1093 *         is TRUE.
1094 *
1095 *  Port Specific Information:
1096 *
1097 *  XXX document implementation including references if appropriate
1098 */
1099void *_CPU_Thread_Idle_body( uintptr_t ignored );
1100
1101/**
1102 *  @ingroup CPUContext
1103 *  This routine switches from the run context to the heir context.
1104 *
1105 *  @param[in] run points to the context of the currently executing task
1106 *  @param[in] heir points to the context of the heir task
1107 *
1108 *  Port Specific Information:
1109 *
1110 *  XXX document implementation including references if appropriate
1111 */
1112void _CPU_Context_switch(
1113  Context_Control  *run,
1114  Context_Control  *heir
1115);
1116
1117/**
1118 *  @ingroup CPUContext
1119 *  This routine is generally used only to restart self in an
1120 *  efficient manner.  It may simply be a label in @ref _CPU_Context_switch.
1121 *
1122 *  @param[in] new_context points to the context to be restored.
1123 *
1124 *  @note May be unnecessary to reload some registers.
1125 *
1126 *  Port Specific Information:
1127 *
1128 *  XXX document implementation including references if appropriate
1129 */
1130void _CPU_Context_restore(
1131  Context_Control *new_context
1132) RTEMS_COMPILER_NO_RETURN_ATTRIBUTE;
1133
1134/* FIXME */
1135typedef CPU_Interrupt_frame CPU_Exception_frame;
1136
1137void _CPU_Exception_frame_print( const CPU_Exception_frame *frame );
1138
1139/**
1140 *  @ingroup CPUEndian
1141 *  The following routine swaps the endian format of an unsigned int.
1142 *  It must be static because it is referenced indirectly.
1143 *
1144 *  This version will work on any processor, but if there is a better
1145 *  way for your CPU PLEASE use it.  The most common way to do this is to:
1146 *
1147 *     swap least significant two bytes with 16-bit rotate
1148 *     swap upper and lower 16-bits
1149 *     swap most significant two bytes with 16-bit rotate
1150 *
1151 *  Some CPUs have special instructions which swap a 32-bit quantity in
1152 *  a single instruction (e.g. i486).  It is probably best to avoid
1153 *  an "endian swapping control bit" in the CPU.  One good reason is
1154 *  that interrupts would probably have to be disabled to ensure that
1155 *  an interrupt does not try to access the same "chunk" with the wrong
1156 *  endian.  Another good reason is that on some CPUs, the endian bit
1157 *  endianness for ALL fetches -- both code and data -- so the code
1158 *  will be fetched incorrectly.
1159 *
1160 *  @param[in] value is the value to be swapped
1161 *  @return the value after being endian swapped
1162 *
1163 *  Port Specific Information:
1164 *
1165 *  XXX document implementation including references if appropriate
1166 */
1167static inline uint32_t CPU_swap_u32(
1168  uint32_t value
1169)
1170{
1171  uint32_t byte1, byte2, byte3, byte4, swapped;
1172
1173  byte4 = (value >> 24) & 0xff;
1174  byte3 = (value >> 16) & 0xff;
1175  byte2 = (value >> 8)  & 0xff;
1176  byte1 =  value        & 0xff;
1177
1178  swapped = (byte1 << 24) | (byte2 << 16) | (byte3 << 8) | byte4;
1179  return swapped;
1180}
1181
1182/**
1183 *  @ingroup CPUEndian
1184 *  This routine swaps a 16 bir quantity.
1185 *
1186 *  @param[in] value is the value to be swapped
1187 *  @return the value after being endian swapped
1188 */
1189#define CPU_swap_u16( value ) \
1190  (((value&0xff) << 8) | ((value >> 8)&0xff))
1191
1192#ifdef __cplusplus
1193}
1194#endif
1195
1196#endif
Note: See TracBrowser for help on using the repository browser.