source: rtems/cpukit/score/cpu/m32c/include/rtems/score/cpu.h @ d8de6b9

5
Last change on this file since d8de6b9 was 2afb22b, checked in by Chris Johns <chrisj@…>, on 12/23/17 at 07:18:56

Remove make preinstall

A speciality of the RTEMS build system was the make preinstall step. It
copied header files from arbitrary locations into the build tree. The
header files were included via the -Bsome/build/tree/path GCC command
line option.

This has at least seven problems:

  • The make preinstall step itself needs time and disk space.
  • Errors in header files show up in the build tree copy. This makes it hard for editors to open the right file to fix the error.
  • There is no clear relationship between source and build tree header files. This makes an audit of the build process difficult.
  • The visibility of all header files in the build tree makes it difficult to enforce API barriers. For example it is discouraged to use BSP-specifics in the cpukit.
  • An introduction of a new build system is difficult.
  • Include paths specified by the -B option are system headers. This may suppress warnings.
  • The parallel build had sporadic failures on some hosts.

This patch removes the make preinstall step. All installed header
files are moved to dedicated include directories in the source tree.
Let @RTEMS_CPU@ be the target architecture, e.g. arm, powerpc, sparc,
etc. Let @RTEMS_BSP_FAMILIY@ be a BSP family base directory, e.g.
erc32, imx, qoriq, etc.

The new cpukit include directories are:

  • cpukit/include
  • cpukit/score/cpu/@RTEMS_CPU@/include
  • cpukit/libnetworking

The new BSP include directories are:

  • bsps/include
  • bsps/@RTEMS_CPU@/include
  • bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILIY@/include

There are build tree include directories for generated files.

The include directory order favours the most general header file, e.g.
it is not possible to override general header files via the include path
order.

The "bootstrap -p" option was removed. The new "bootstrap -H" option
should be used to regenerate the "headers.am" files.

Update #3254.

  • Property mode set to 100644
File size: 30.0 KB
Line 
1/**
2 * @file
3 *
4 * @brief M32C CPU Dependent Source
5 */
6
7/*
8 *  This include file contains information pertaining to the XXX
9 *  processor.
10 *
11 *  @note This file is part of a porting template that is intended
12 *  to be used as the starting point when porting RTEMS to a new
13 *  CPU family.  The following needs to be done when using this as
14 *  the starting point for a new port:
15 *
16 *  + Anywhere there is an XXX, it should be replaced
17 *    with information about the CPU family being ported to.
18 *
19 *  + At the end of each comment section, there is a heading which
20 *    says "Port Specific Information:".  When porting to RTEMS,
21 *    add CPU family specific information in this section
22 */
23
24/*
25 *  COPYRIGHT (c) 1989-2008.
26 *  On-Line Applications Research Corporation (OAR).
27 *
28 *  The license and distribution terms for this file may be
29 *  found in the file LICENSE in this distribution or at
30 *  http://www.rtems.org/license/LICENSE.
31 */
32
33#ifndef _RTEMS_SCORE_CPU_H
34#define _RTEMS_SCORE_CPU_H
35
36#ifdef __cplusplus
37extern "C" {
38#endif
39
40#include <rtems/score/types.h>
41#include <rtems/score/m32c.h>
42
43/* conditional compilation parameters */
44
45#define RTEMS_USE_16_BIT_OBJECT
46
47/**
48 * Does RTEMS manage a dedicated interrupt stack in software?
49 *
50 * If TRUE, then a stack is allocated in @ref _ISR_Handler_initialization.
51 * If FALSE, nothing is done.
52 *
53 * If the CPU supports a dedicated interrupt stack in hardware,
54 * then it is generally the responsibility of the BSP to allocate it
55 * and set it up.
56 *
57 * If the CPU does not support a dedicated interrupt stack, then
58 * the porter has two options: (1) execute interrupts on the
59 * stack of the interrupted task, and (2) have RTEMS manage a dedicated
60 * interrupt stack.
61 *
62 * If this is TRUE, @ref CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
63 *
64 * Only one of @ref CPU_HAS_SOFTWARE_INTERRUPT_STACK and
65 * @ref CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE.  It is
66 * possible that both are FALSE for a particular CPU.  Although it
67 * is unclear what that would imply about the interrupt processing
68 * procedure on that CPU.
69 *
70 * Port Specific Information:
71 *
72 * XXX document implementation including references if appropriate
73 */
74#define CPU_HAS_SOFTWARE_INTERRUPT_STACK FALSE
75
76/**
77 * Does the CPU follow the simple vectored interrupt model?
78 *
79 * If TRUE, then RTEMS allocates the vector table it internally manages.
80 * If FALSE, then the BSP is assumed to allocate and manage the vector
81 * table
82 *
83 * Port Specific Information:
84 *
85 * XXX document implementation including references if appropriate
86 */
87#define CPU_SIMPLE_VECTORED_INTERRUPTS TRUE
88
89/**
90 * Does this CPU have hardware support for a dedicated interrupt stack?
91 *
92 * If TRUE, then it must be installed during initialization.
93 * If FALSE, then no installation is performed.
94 *
95 * If this is TRUE, @ref CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
96 *
97 * Only one of @ref CPU_HAS_SOFTWARE_INTERRUPT_STACK and
98 * @ref CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE.  It is
99 * possible that both are FALSE for a particular CPU.  Although it
100 * is unclear what that would imply about the interrupt processing
101 * procedure on that CPU.
102 *
103 * Port Specific Information:
104 *
105 * XXX document implementation including references if appropriate
106 */
107#define CPU_HAS_HARDWARE_INTERRUPT_STACK TRUE
108
109/**
110 * Does RTEMS allocate a dedicated interrupt stack in the Interrupt Manager?
111 *
112 * If TRUE, then the memory is allocated during initialization.
113 * If FALSE, then the memory is allocated during initialization.
114 *
115 * This should be TRUE is CPU_HAS_SOFTWARE_INTERRUPT_STACK is TRUE.
116 *
117 * Port Specific Information:
118 *
119 * XXX document implementation including references if appropriate
120 */
121#define CPU_ALLOCATE_INTERRUPT_STACK TRUE
122
123/**
124 * Does the RTEMS invoke the user's ISR with the vector number and
125 * a pointer to the saved interrupt frame (1) or just the vector
126 * number (0)?
127 *
128 * Port Specific Information:
129 *
130 * XXX document implementation including references if appropriate
131 */
132#define CPU_ISR_PASSES_FRAME_POINTER FALSE
133
134/**
135 * @def CPU_HARDWARE_FP
136 *
137 * Does the CPU have hardware floating point?
138 *
139 * If TRUE, then the RTEMS_FLOATING_POINT task attribute is supported.
140 * If FALSE, then the RTEMS_FLOATING_POINT task attribute is ignored.
141 *
142 * If there is a FP coprocessor such as the i387 or mc68881, then
143 * the answer is TRUE.
144 *
145 * The macro name "M32C_HAS_FPU" should be made CPU specific.
146 * It indicates whether or not this CPU model has FP support.  For
147 * example, it would be possible to have an i386_nofp CPU model
148 * which set this to false to indicate that you have an i386 without
149 * an i387 and wish to leave floating point support out of RTEMS.
150 */
151
152/**
153 * @def CPU_SOFTWARE_FP
154 *
155 * Does the CPU have no hardware floating point and GCC provides a
156 * software floating point implementation which must be context
157 * switched?
158 *
159 * This feature conditional is used to indicate whether or not there
160 * is software implemented floating point that must be context
161 * switched.  The determination of whether or not this applies
162 * is very tool specific and the state saved/restored is also
163 * compiler specific.
164 *
165 * Port Specific Information:
166 *
167 * XXX document implementation including references if appropriate
168 */
169#if ( M32C_HAS_FPU == 1 )
170#define CPU_HARDWARE_FP     TRUE
171#else
172#define CPU_HARDWARE_FP     FALSE
173#endif
174#define CPU_SOFTWARE_FP     FALSE
175
176#define CPU_CONTEXT_FP_SIZE 0
177
178/**
179 * Are all tasks RTEMS_FLOATING_POINT tasks implicitly?
180 *
181 * If TRUE, then the RTEMS_FLOATING_POINT task attribute is assumed.
182 * If FALSE, then the RTEMS_FLOATING_POINT task attribute is followed.
183 *
184 * So far, the only CPUs in which this option has been used are the
185 * HP PA-RISC and PowerPC.  On the PA-RISC, The HP C compiler and
186 * gcc both implicitly used the floating point registers to perform
187 * integer multiplies.  Similarly, the PowerPC port of gcc has been
188 * seen to allocate floating point local variables and touch the FPU
189 * even when the flow through a subroutine (like vfprintf()) might
190 * not use floating point formats.
191 *
192 * If a function which you would not think utilize the FP unit DOES,
193 * then one can not easily predict which tasks will use the FP hardware.
194 * In this case, this option should be TRUE.
195 *
196 * If @ref CPU_HARDWARE_FP is FALSE, then this should be FALSE as well.
197 *
198 * Port Specific Information:
199 *
200 * XXX document implementation including references if appropriate
201 */
202#define CPU_ALL_TASKS_ARE_FP     TRUE
203
204/**
205 * Should the IDLE task have a floating point context?
206 *
207 * If TRUE, then the IDLE task is created as a RTEMS_FLOATING_POINT task
208 * and it has a floating point context which is switched in and out.
209 * If FALSE, then the IDLE task does not have a floating point context.
210 *
211 * Setting this to TRUE negatively impacts the time required to preempt
212 * the IDLE task from an interrupt because the floating point context
213 * must be saved as part of the preemption.
214 *
215 * Port Specific Information:
216 *
217 * XXX document implementation including references if appropriate
218 */
219#define CPU_IDLE_TASK_IS_FP      FALSE
220
221/**
222 * Should the saving of the floating point registers be deferred
223 * until a context switch is made to another different floating point
224 * task?
225 *
226 * If TRUE, then the floating point context will not be stored until
227 * necessary.  It will remain in the floating point registers and not
228 * disturned until another floating point task is switched to.
229 *
230 * If FALSE, then the floating point context is saved when a floating
231 * point task is switched out and restored when the next floating point
232 * task is restored.  The state of the floating point registers between
233 * those two operations is not specified.
234 *
235 * If the floating point context does NOT have to be saved as part of
236 * interrupt dispatching, then it should be safe to set this to TRUE.
237 *
238 * Setting this flag to TRUE results in using a different algorithm
239 * for deciding when to save and restore the floating point context.
240 * The deferred FP switch algorithm minimizes the number of times
241 * the FP context is saved and restored.  The FP context is not saved
242 * until a context switch is made to another, different FP task.
243 * Thus in a system with only one FP task, the FP context will never
244 * be saved or restored.
245 *
246 * Port Specific Information:
247 *
248 * XXX document implementation including references if appropriate
249 */
250#define CPU_USE_DEFERRED_FP_SWITCH       TRUE
251
252#define CPU_ENABLE_ROBUST_THREAD_DISPATCH FALSE
253
254/**
255 * Does this port provide a CPU dependent IDLE task implementation?
256 *
257 * If TRUE, then the routine @ref _CPU_Thread_Idle_body
258 * must be provided and is the default IDLE thread body instead of
259 * @ref _CPU_Thread_Idle_body.
260 *
261 * If FALSE, then use the generic IDLE thread body if the BSP does
262 * not provide one.
263 *
264 * This is intended to allow for supporting processors which have
265 * a low power or idle mode.  When the IDLE thread is executed, then
266 * the CPU can be powered down.
267 *
268 * The order of precedence for selecting the IDLE thread body is:
269 *
270 *   -#  BSP provided
271 *   -#  CPU dependent (if provided)
272 *   -#  generic (if no BSP and no CPU dependent)
273 *
274 * Port Specific Information:
275 *
276 * XXX document implementation including references if appropriate
277 */
278#define CPU_PROVIDES_IDLE_THREAD_BODY    TRUE
279
280/**
281 * Does the stack grow up (toward higher addresses) or down
282 * (toward lower addresses)?
283 *
284 * If TRUE, then the grows upward.
285 * If FALSE, then the grows toward smaller addresses.
286 *
287 * Port Specific Information:
288 *
289 * XXX document implementation including references if appropriate
290 */
291#define CPU_STACK_GROWS_UP               TRUE
292
293/* FIXME: Is this the right value? */
294#define CPU_CACHE_LINE_BYTES 2
295
296#define CPU_STRUCTURE_ALIGNMENT RTEMS_ALIGNED( CPU_CACHE_LINE_BYTES )
297
298/**
299 * @ingroup CPUInterrupt
300 *
301 * The following defines the number of bits actually used in the
302 * interrupt field of the task mode.  How those bits map to the
303 * CPU interrupt levels is defined by the routine @ref _CPU_ISR_Set_level.
304 *
305 * Port Specific Information:
306 *
307 * XXX document implementation including references if appropriate
308 */
309#define CPU_MODES_INTERRUPT_MASK   0x00000001
310
311#define CPU_MAXIMUM_PROCESSORS 32
312
313/*
314 *  Processor defined structures required for cpukit/score.
315 *
316 *  Port Specific Information:
317 *
318 *  XXX document implementation including references if appropriate
319 */
320
321/* may need to put some structures here.  */
322
323/**
324 * @defgroup CPUContext Processor Dependent Context Management
325 *
326 * From the highest level viewpoint, there are 2 types of context to save.
327 *
328 *    -# Interrupt registers to save
329 *    -# Task level registers to save
330 *
331 * Since RTEMS handles integer and floating point contexts separately, this
332 * means we have the following 3 context items:
333 *
334 *    -# task level context stuff::  Context_Control
335 *    -# floating point task stuff:: Context_Control_fp
336 *    -# special interrupt level context :: CPU_Interrupt_frame
337 *
338 * On some processors, it is cost-effective to save only the callee
339 * preserved registers during a task context switch.  This means
340 * that the ISR code needs to save those registers which do not
341 * persist across function calls.  It is not mandatory to make this
342 * distinctions between the caller/callee saves registers for the
343 * purpose of minimizing context saved during task switch and on interrupts.
344 * If the cost of saving extra registers is minimal, simplicity is the
345 * choice.  Save the same context on interrupt entry as for tasks in
346 * this case.
347 *
348 * Additionally, if gdb is to be made aware of RTEMS tasks for this CPU, then
349 * care should be used in designing the context area.
350 *
351 * On some CPUs with hardware floating point support, the Context_Control_fp
352 * structure will not be used or it simply consist of an array of a
353 * fixed number of bytes.   This is done when the floating point context
354 * is dumped by a "FP save context" type instruction and the format
355 * is not really defined by the CPU.  In this case, there is no need
356 * to figure out the exact format -- only the size.  Of course, although
357 * this is enough information for RTEMS, it is probably not enough for
358 * a debugger such as gdb.  But that is another problem.
359 *
360 * Port Specific Information:
361 *
362 * XXX document implementation including references if appropriate
363 */
364/**@{**/
365
366/**
367 * @ingroup Management
368 *
369 * This defines the minimal set of integer and processor state registers
370 * that must be saved during a voluntary context switch from one thread
371 * to another.
372 */
373typedef struct {
374  /** This will contain the stack pointer. */
375  uint32_t sp;
376  /** This will contain the frame base pointer. */
377  uint32_t fb;
378} Context_Control;
379
380/**
381 * @ingroup Management
382 *
383 * This macro returns the stack pointer associated with @a _context.
384 *
385 * @param[in] _context is the thread context area to access
386 *
387 * @return This method returns the stack pointer.
388 */
389#define _CPU_Context_Get_SP( _context ) \
390  (_context)->sp
391
392/**
393 * @ingroup Management
394 *
395 * This defines the set of integer and processor state registers that must
396 * be saved during an interrupt.  This set does not include any which are
397 * in @ref Context_Control.
398 */
399typedef struct {
400    /**
401     * This field is a hint that a port will have a number of integer
402     * registers that need to be saved when an interrupt occurs or
403     * when a context switch occurs at the end of an ISR.
404     */
405    uint32_t   special_interrupt_register;
406} CPU_Interrupt_frame;
407
408/** @} */
409
410/**
411 * @defgroup CPUInterrupt Processor Dependent Interrupt Management
412 *
413 * On some CPUs, RTEMS supports a software managed interrupt stack.
414 * This stack is allocated by the Interrupt Manager and the switch
415 * is performed in @ref _ISR_Handler.  These variables contain pointers
416 * to the lowest and highest addresses in the chunk of memory allocated
417 * for the interrupt stack.  Since it is unknown whether the stack
418 * grows up or down (in general), this give the CPU dependent
419 * code the option of picking the version it wants to use.
420 *
421 * NOTE: These two variables are required if the macro
422 *       @ref CPU_HAS_SOFTWARE_INTERRUPT_STACK is defined as TRUE.
423 *
424 * Port Specific Information:
425 *
426 * XXX document implementation including references if appropriate
427 *
428 */
429/**@{**/
430
431/*
432 *  Nothing prevents the porter from declaring more CPU specific variables.
433 *
434 *  Port Specific Information:
435 *
436 *  XXX document implementation including references if appropriate
437 */
438
439/* XXX: if needed, put more variables here */
440
441/**
442 * Amount of extra stack (above minimum stack size) required by
443 * MPCI receive server thread.  Remember that in a multiprocessor
444 * system this thread must exist and be able to process all directives.
445 *
446 * Port Specific Information:
447 *
448 * XXX document implementation including references if appropriate
449 */
450#define CPU_MPCI_RECEIVE_SERVER_EXTRA_STACK 0
451
452/**
453 * This defines the number of entries in the @ref _ISR_Vector_table managed
454 * by RTEMS.
455 *
456 * Port Specific Information:
457 *
458 * XXX document implementation including references if appropriate
459 */
460#define CPU_INTERRUPT_NUMBER_OF_VECTORS      32
461
462/** This defines the highest interrupt vector number for this port. */
463#define CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER  (CPU_INTERRUPT_NUMBER_OF_VECTORS - 1)
464
465/**
466 * This is defined if the port has a special way to report the ISR nesting
467 * level.  Most ports maintain the variable @a _ISR_Nest_level.
468 */
469#define CPU_PROVIDES_ISR_IS_IN_PROGRESS FALSE
470
471/** @} */
472
473/**
474 * @ingroup CPUContext
475 *
476 * Should be large enough to run all RTEMS tests.  This ensures
477 * that a "reasonable" small application should not have any problems.
478 *
479 * Port Specific Information:
480 *
481 * XXX document implementation including references if appropriate
482 */
483#define CPU_STACK_MINIMUM_SIZE          (2048L)
484
485#ifdef __m32cm_cpu__
486  #define CPU_SIZEOF_POINTER 4
487#else
488  #define CPU_SIZEOF_POINTER 2
489#endif
490
491/**
492 * CPU's worst alignment requirement for data types on a byte boundary.  This
493 * alignment does not take into account the requirements for the stack.
494 *
495 * Port Specific Information:
496 *
497 * XXX document implementation including references if appropriate
498 */
499#define CPU_ALIGNMENT              2
500
501/**
502 * This number corresponds to the byte alignment requirement for the
503 * heap handler.  This alignment requirement may be stricter than that
504 * for the data types alignment specified by @ref CPU_ALIGNMENT.  It is
505 * common for the heap to follow the same alignment requirement as
506 * @ref CPU_ALIGNMENT.  If the @ref CPU_ALIGNMENT is strict enough for
507 * the heap, then this should be set to @ref CPU_ALIGNMENT.
508 *
509 * NOTE:  This does not have to be a power of 2 although it should be
510 *        a multiple of 2 greater than or equal to 2.  The requirement
511 *        to be a multiple of 2 is because the heap uses the least
512 *        significant field of the front and back flags to indicate
513 *        that a block is in use or free.  So you do not want any odd
514 *        length blocks really putting length data in that bit.
515 *
516 *        On byte oriented architectures, @ref CPU_HEAP_ALIGNMENT normally will
517 *        have to be greater or equal to than @ref CPU_ALIGNMENT to ensure that
518 *        elements allocated from the heap meet all restrictions.
519 *
520 * Port Specific Information:
521 *
522 * XXX document implementation including references if appropriate
523 */
524#define CPU_HEAP_ALIGNMENT         4
525
526/**
527 * This number corresponds to the byte alignment requirement for memory
528 * buffers allocated by the partition manager.  This alignment requirement
529 * may be stricter than that for the data types alignment specified by
530 * @ref CPU_ALIGNMENT.  It is common for the partition to follow the same
531 * alignment requirement as @ref CPU_ALIGNMENT.  If the @ref CPU_ALIGNMENT is
532 * strict enough for the partition, then this should be set to
533 * @ref CPU_ALIGNMENT.
534 *
535 * NOTE:  This does not have to be a power of 2.  It does have to
536 *        be greater or equal to than @ref CPU_ALIGNMENT.
537 *
538 * Port Specific Information:
539 *
540 * XXX document implementation including references if appropriate
541 */
542#define CPU_PARTITION_ALIGNMENT    CPU_ALIGNMENT
543
544/**
545 * This number corresponds to the byte alignment requirement for the
546 * stack.  This alignment requirement may be stricter than that for the
547 * data types alignment specified by @ref CPU_ALIGNMENT.  If the
548 * @ref CPU_ALIGNMENT is strict enough for the stack, then this should be
549 * set to 0.
550 *
551 * NOTE: This must be a power of 2 either 0 or greater than @ref CPU_ALIGNMENT.
552 *
553 * Port Specific Information:
554 *
555 * XXX document implementation including references if appropriate
556 */
557#define CPU_STACK_ALIGNMENT        0
558
559/*
560 *  ISR handler macros
561 */
562
563/**
564 * @ingroup CPUInterrupt
565 *
566 * Support routine to initialize the RTEMS vector table after it is allocated.
567 *
568 * Port Specific Information:
569 *
570 * XXX document implementation including references if appropriate
571 */
572#define _CPU_Initialize_vectors()
573
574/**
575 * @ingroup CPUInterrupt
576 *
577 * Disable all interrupts for an RTEMS critical section.  The previous
578 * level is returned in @a _isr_cookie.
579 *
580 * @param[out] _isr_cookie will contain the previous level cookie
581 *
582 * Port Specific Information:
583 *
584 * XXX document implementation including references if appropriate
585 */
586#define _CPU_ISR_Disable( _isr_cookie ) \
587  do { \
588    int _flg; \
589    m32c_get_flg( _flg ); \
590    _isr_cookie = _flg; \
591    __asm__ volatile( "fclr I" ); \
592  } while(0)
593
594/**
595 * @ingroup CPUInterrupt
596 *
597 * Enable interrupts to the previous level (returned by _CPU_ISR_Disable).
598 * This indicates the end of an RTEMS critical section.  The parameter
599 * @a _isr_cookie is not modified.
600 *
601 * @param[in] _isr_cookie contain the previous level cookie
602 *
603 * Port Specific Information:
604 *
605 * XXX document implementation including references if appropriate
606 */
607#define _CPU_ISR_Enable(_isr_cookie) \
608  do { \
609    int _flg = (int) (_isr_cookie); \
610    m32c_set_flg( _flg ); \
611  } while(0)
612
613/**
614 * @ingroup CPUInterrupt
615 *
616 * This temporarily restores the interrupt to @a _isr_cookie before immediately
617 * disabling them again.  This is used to divide long RTEMS critical
618 * sections into two or more parts.  The parameter @a _isr_cookie is not
619 * modified.
620 *
621 * @param[in] _isr_cookie contain the previous level cookie
622 *
623 * Port Specific Information:
624 *
625 * XXX document implementation including references if appropriate
626 */
627#define _CPU_ISR_Flash( _isr_cookie ) \
628  do { \
629    int _flg = (int) (_isr_cookie); \
630    m32c_set_flg( _flg ); \
631    __asm__ volatile( "fclr I" ); \
632  } while(0)
633
634RTEMS_INLINE_ROUTINE bool _CPU_ISR_Is_enabled( uint32_t level )
635{
636  return ( level & 0x40 ) != 0;
637}
638
639/**
640 * @ingroup CPUInterrupt
641 *
642 * This routine and @ref _CPU_ISR_Get_level
643 * Map the interrupt level in task mode onto the hardware that the CPU
644 * actually provides.  Currently, interrupt levels which do not
645 * map onto the CPU in a generic fashion are undefined.  Someday,
646 * it would be nice if these were "mapped" by the application
647 * via a callout.  For example, m68k has 8 levels 0 - 7, levels
648 * 8 - 255 would be available for bsp/application specific meaning.
649 *This could be used to manage a programmable interrupt controller
650 * via the rtems_task_mode directive.
651 *
652 * Port Specific Information:
653 *
654 * XXX document implementation including references if appropriate
655 */
656#define _CPU_ISR_Set_level( _new_level ) \
657  do { \
658    if (_new_level) __asm__ volatile( "fclr I" ); \
659    else            __asm__ volatile( "fset I" ); \
660  } while(0)
661
662/**
663 * @ingroup CPUInterrupt
664 *
665 * Return the current interrupt disable level for this task in
666 * the format used by the interrupt level portion of the task mode.
667 *
668 * NOTE: This routine usually must be implemented as a subroutine.
669 *
670 * Port Specific Information:
671 *
672 * XXX document implementation including references if appropriate
673 */
674uint32_t   _CPU_ISR_Get_level( void );
675
676/* end of ISR handler macros */
677
678/* Context handler macros */
679
680/**
681 * @ingroup CPUContext
682 *
683 * Initialize the context to a state suitable for starting a
684 * task after a context restore operation.  Generally, this
685 * involves:
686 *
687 *    - setting a starting address
688 *    - preparing the stack
689 *    - preparing the stack and frame pointers
690 *    - setting the proper interrupt level in the context
691 *    - initializing the floating point context
692 *
693 * This routine generally does not set any unnecessary register
694 * in the context.  The state of the "general data" registers is
695 * undefined at task start time.
696 *
697 * @param[in] _the_context is the context structure to be initialized
698 * @param[in] _stack_base is the lowest physical address of this task's stack
699 * @param[in] _size is the size of this task's stack
700 * @param[in] _isr is the interrupt disable level
701 * @param[in] _entry_point is the thread's entry point.  This is
702 *        always @a _Thread_Handler
703 * @param[in] _is_fp is TRUE if the thread is to be a floating
704 *       point thread.  This is typically only used on CPUs where the
705 *       FPU may be easily disabled by software such as on the SPARC
706 *       where the PSR contains an enable FPU bit.
707 * @param[in] tls_area is the thread-local storage (TLS) area
708 *
709 * Port Specific Information:
710 *
711 * XXX document implementation including references if appropriate
712 */
713void _CPU_Context_Initialize(
714  Context_Control  *the_context,
715  uint32_t         *stack_base,
716  size_t            size,
717  uint32_t          new_level,
718  void             *entry_point,
719  bool              is_fp,
720  void             *tls_area
721);
722
723/**
724 * This routine is responsible for somehow restarting the currently
725 * executing task.  If you are lucky, then all that is necessary
726 * is restoring the context.  Otherwise, there will need to be
727 * a special assembly routine which does something special in this
728 * case.  For many ports, simply adding a label to the restore path
729 * of @ref _CPU_Context_switch will work.  On other ports, it may be
730 * possibly to load a few arguments and jump to the restore path. It will
731 * not work if restarting self conflicts with the stack frame
732 * assumptions of restoring a context.
733 *
734 * Port Specific Information:
735 *
736 * XXX document implementation including references if appropriate
737 */
738void _CPU_Context_Restart_self(
739  Context_Control  *the_context
740) RTEMS_NO_RETURN;
741
742/**
743 * This routine initializes the FP context area passed to it to.
744 * There are a few standard ways in which to initialize the
745 * floating point context.  The code included for this macro assumes
746 * that this is a CPU in which a "initial" FP context was saved into
747 * @a _CPU_Null_fp_context and it simply copies it to the destination
748 * context passed to it.
749 *
750 * Other floating point context save/restore models include:
751 *   -# not doing anything, and
752 *   -# putting a "null FP status word" in the correct place in the FP context.
753 *
754 * @param[in] _destination is the floating point context area
755 *
756 * Port Specific Information:
757 *
758 * XXX document implementation including references if appropriate
759 */
760#define _CPU_Context_Initialize_fp( _destination ) \
761  { \
762   *(*(_destination)) = _CPU_Null_fp_context; \
763  }
764
765/* end of Context handler macros */
766
767/* Fatal Error manager macros */
768
769/**
770 * This routine copies _error into a known place -- typically a stack
771 * location or a register, optionally disables interrupts, and
772 * halts/stops the CPU.
773 *
774 * Port Specific Information:
775 *
776 * XXX document implementation including references if appropriate
777 */
778#define _CPU_Fatal_halt( _source, _error ) \
779  { \
780  }
781
782/* end of Fatal Error manager macros */
783
784#define CPU_USE_GENERIC_BITFIELD_CODE TRUE
785
786/* functions */
787
788/**
789 * This routine performs CPU dependent initialization.
790 *
791 * Port Specific Information:
792 *
793 * XXX document implementation including references if appropriate
794 */
795void _CPU_Initialize(void);
796
797/**
798 * @ingroup CPUInterrupt
799 *
800 * This routine installs a "raw" interrupt handler directly into the
801 * processor's vector table.
802 *
803 * @param[in] vector is the vector number
804 * @param[in] new_handler is the raw ISR handler to install
805 * @param[in] old_handler is the previously installed ISR Handler
806 *
807 * Port Specific Information:
808 *
809 * XXX document implementation including references if appropriate
810 */
811void _CPU_ISR_install_raw_handler(
812  uint32_t    vector,
813  proc_ptr    new_handler,
814  proc_ptr   *old_handler
815);
816
817/**
818 * @ingroup CPUInterrupt
819 *
820 * This routine installs an interrupt vector.
821 *
822 * @param[in] vector is the vector number
823 * @param[in] new_handler is the RTEMS ISR handler to install
824 * @param[in] old_handler is the previously installed ISR Handler
825 *
826 * Port Specific Information:
827 *
828 * XXX document implementation including references if appropriate
829 */
830void _CPU_ISR_install_vector(
831  uint32_t    vector,
832  proc_ptr    new_handler,
833  proc_ptr   *old_handler
834);
835
836/**
837 * @ingroup CPUInterrupt
838 *
839 * This routine installs the hardware interrupt stack pointer.
840 *
841 * NOTE:  It need only be provided if @ref CPU_HAS_HARDWARE_INTERRUPT_STACK
842 *        is TRUE.
843 *
844 * Port Specific Information:
845 *
846 * XXX document implementation including references if appropriate
847 */
848void _CPU_Install_interrupt_stack( void );
849
850/**
851 * This routine is the CPU dependent IDLE thread body.
852 *
853 * NOTE:  It need only be provided if @ref CPU_PROVIDES_IDLE_THREAD_BODY
854 *        is TRUE.
855 *
856 * Port Specific Information:
857 *
858 * XXX document implementation including references if appropriate
859 */
860void *_CPU_Thread_Idle_body( uintptr_t ignored );
861
862/**
863 * @ingroup CPUContext
864 *
865 * This routine switches from the run context to the heir context.
866 *
867 * @param[in] run points to the context of the currently executing task
868 * @param[in] heir points to the context of the heir task
869 *
870 * Port Specific Information:
871 *
872 * XXX document implementation including references if appropriate
873 */
874void _CPU_Context_switch(
875  Context_Control  *run,
876  Context_Control  *heir
877);
878
879/**
880 * @ingroup CPUContext
881 *
882 * This routine is generally used only to restart self in an
883 * efficient manner.  It may simply be a label in @ref _CPU_Context_switch.
884 *
885 * @param[in] new_context points to the context to be restored.
886 *
887 * NOTE: May be unnecessary to reload some registers.
888 *
889 * Port Specific Information:
890 *
891 * XXX document implementation including references if appropriate
892 */
893void _CPU_Context_restore(
894  Context_Control *new_context
895) RTEMS_NO_RETURN;
896
897static inline void _CPU_Context_volatile_clobber( uintptr_t pattern )
898{
899  /* TODO */
900}
901
902static inline void _CPU_Context_validate( uintptr_t pattern )
903{
904  while (1) {
905    /* TODO */
906  }
907}
908
909/* FIXME */
910typedef CPU_Interrupt_frame CPU_Exception_frame;
911
912void _CPU_Exception_frame_print( const CPU_Exception_frame *frame );
913
914/**
915 * @ingroup CPUEndian
916 *
917 * The following routine swaps the endian format of an unsigned int.
918 * It must be static because it is referenced indirectly.
919 *
920 * This version will work on any processor, but if there is a better
921 * way for your CPU PLEASE use it.  The most common way to do this is to:
922 *
923 *    swap least significant two bytes with 16-bit rotate
924 *    swap upper and lower 16-bits
925 *    swap most significant two bytes with 16-bit rotate
926 *
927 * Some CPUs have special instructions which swap a 32-bit quantity in
928 * a single instruction (e.g. i486).  It is probably best to avoid
929 * an "endian swapping control bit" in the CPU.  One good reason is
930 * that interrupts would probably have to be disabled to ensure that
931 * an interrupt does not try to access the same "chunk" with the wrong
932 * endian.  Another good reason is that on some CPUs, the endian bit
933 * endianness for ALL fetches -- both code and data -- so the code
934 * will be fetched incorrectly.
935 *
936 * @param[in] value is the value to be swapped
937 * @return the value after being endian swapped
938 *
939 * Port Specific Information:
940 *
941 * XXX document implementation including references if appropriate
942 */
943static inline uint32_t CPU_swap_u32(
944  uint32_t value
945)
946{
947  uint32_t byte1, byte2, byte3, byte4, swapped;
948
949  byte4 = (value >> 24) & 0xff;
950  byte3 = (value >> 16) & 0xff;
951  byte2 = (value >> 8)  & 0xff;
952  byte1 =  value        & 0xff;
953
954  swapped = (byte1 << 24) | (byte2 << 16) | (byte3 << 8) | byte4;
955  return swapped;
956}
957
958/**
959 * @ingroup CPUEndian
960 *
961 * This routine swaps a 16 bir quantity.
962 *
963 * @param[in] value is the value to be swapped
964 * @return the value after being endian swapped
965 */
966#define CPU_swap_u16( value ) \
967  (((value&0xff) << 8) | ((value >> 8)&0xff))
968
969typedef uint32_t CPU_Counter_ticks;
970
971CPU_Counter_ticks _CPU_Counter_read( void );
972
973static inline CPU_Counter_ticks _CPU_Counter_difference(
974  CPU_Counter_ticks second,
975  CPU_Counter_ticks first
976)
977{
978  return second - first;
979}
980
981#ifdef __cplusplus
982}
983#endif
984
985#endif
Note: See TracBrowser for help on using the repository browser.