📄 cpu.h
字号:
* persist across function calls. It is not mandatory to make this * distinctions between the caller/callee saves registers for the * purpose of minimizing context saved during task switch and on interrupts. * If the cost of saving extra registers is minimal, simplicity is the * choice. Save the same context on interrupt entry as for tasks in * this case. * * Additionally, if gdb is to be made aware of RTEMS tasks for this CPU, then * care should be used in designing the context area. * * On some CPUs with hardware floating point support, the Context_Control_fp * structure will not be used or it simply consist of an array of a * fixed number of bytes. This is done when the floating point context * is dumped by a "FP save context" type instruction and the format * is not really defined by the CPU. In this case, there is no need * to figure out the exact format -- only the size. Of course, although * this is enough information for RTEMS, it is probably not enough for * a debugger such as gdb. But that is another problem. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */typedef struct { unsigned32 some_integer_register; unsigned32 some_system_register;} Context_Control;typedef struct { double some_float_register;} Context_Control_fp;typedef struct { unsigned32 special_interrupt_register;} CPU_Interrupt_frame;/* * The following table contains the information required to configure * the XXX processor specific parameters. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */typedef struct { void (*pretasking_hook)( void ); void (*predriver_hook)( void ); void (*postdriver_hook)( void ); void (*idle_task)( void ); boolean do_zero_of_workspace; unsigned32 idle_task_stack_size; unsigned32 interrupt_stack_size; unsigned32 extra_mpci_receive_server_stack; void * (*stack_allocate_hook)( unsigned32 ); void (*stack_free_hook)( void* ); /* end of fields required on all CPUs */} rtems_cpu_table;/* * Macros to access required entires in the CPU Table are in * the file rtems/system.h. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate *//* * Macros to access NO_CPU specific additions to the CPU Table * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate *//* There are no CPU specific additions to the CPU Table for this port. *//* * This variable is optional. It is used on CPUs on which it is difficult * to generate an "uninitialized" FP context. It is filled in by * _CPU_Initialize and copied into the task's FP context area during * _CPU_Context_Initialize. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */SCORE_EXTERN Context_Control_fp _CPU_Null_fp_context;/* * On some CPUs, RTEMS supports a software managed interrupt stack. * This stack is allocated by the Interrupt Manager and the switch * is performed in _ISR_Handler. These variables contain pointers * to the lowest and highest addresses in the chunk of memory allocated * for the interrupt stack. Since it is unknown whether the stack * grows up or down (in general), this give the CPU dependent * code the option of picking the version it wants to use. * * NOTE: These two variables are required if the macro * CPU_HAS_SOFTWARE_INTERRUPT_STACK is defined as TRUE. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */SCORE_EXTERN void *_CPU_Interrupt_stack_low;SCORE_EXTERN void *_CPU_Interrupt_stack_high;/* * With some compilation systems, it is difficult if not impossible to * call a high-level language routine from assembly language. This * is especially true of commercial Ada compilers and name mangling * C++ ones. This variable can be optionally defined by the CPU porter * and contains the address of the routine _Thread_Dispatch. This * can make it easier to invoke that routine at the end of the interrupt * sequence (if a dispatch is necessary). * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */SCORE_EXTERN void (*_CPU_Thread_dispatch_pointer)();/* * Nothing prevents the porter from declaring more CPU specific variables. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate *//* XXX: if needed, put more variables here *//* * The size of the floating point context area. On some CPUs this * will not be a "sizeof" because the format of the floating point * area is not defined -- only the size is. This is usually on * CPUs with a "floating point save context" instruction. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define CPU_CONTEXT_FP_SIZE sizeof( Context_Control_fp )/* * Amount of extra stack (above minimum stack size) required by * MPCI receive server thread. Remember that in a multiprocessor * system this thread must exist and be able to process all directives. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define CPU_MPCI_RECEIVE_SERVER_EXTRA_STACK 0/* * This defines the number of entries in the ISR_Vector_table managed * by RTEMS. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define CPU_INTERRUPT_NUMBER_OF_VECTORS 32#define CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER (CPU_INTERRUPT_NUMBER_OF_VECTORS - 1)/* * This is defined if the port has a special way to report the ISR nesting * level. Most ports maintain the variable _ISR_Nest_level. */#define CPU_PROVIDES_ISR_IS_IN_PROGRESS FALSE/* * Should be large enough to run all RTEMS tests. This insures * that a "reasonable" small application should not have any problems. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define CPU_STACK_MINIMUM_SIZE (1024*4)/* * CPU's worst alignment requirement for data types on a byte boundary. This * alignment does not take into account the requirements for the stack. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define CPU_ALIGNMENT 8/* * This number corresponds to the byte alignment requirement for the * heap handler. This alignment requirement may be stricter than that * for the data types alignment specified by CPU_ALIGNMENT. It is * common for the heap to follow the same alignment requirement as * CPU_ALIGNMENT. If the CPU_ALIGNMENT is strict enough for the heap, * then this should be set to CPU_ALIGNMENT. * * NOTE: This does not have to be a power of 2 although it should be * a multiple of 2 greater than or equal to 2. The requirement * to be a multiple of 2 is because the heap uses the least * significant field of the front and back flags to indicate * that a block is in use or free. So you do not want any odd * length blocks really putting length data in that bit. * * On byte oriented architectures, CPU_HEAP_ALIGNMENT normally will * have to be greater or equal to than CPU_ALIGNMENT to ensure that * elements allocated from the heap meet all restrictions. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define CPU_HEAP_ALIGNMENT CPU_ALIGNMENT/* * This number corresponds to the byte alignment requirement for memory * buffers allocated by the partition manager. This alignment requirement * may be stricter than that for the data types alignment specified by * CPU_ALIGNMENT. It is common for the partition to follow the same * alignment requirement as CPU_ALIGNMENT. If the CPU_ALIGNMENT is strict * enough for the partition, then this should be set to CPU_ALIGNMENT. * * NOTE: This does not have to be a power of 2. It does have to * be greater or equal to than CPU_ALIGNMENT. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define CPU_PARTITION_ALIGNMENT CPU_ALIGNMENT/* * This number corresponds to the byte alignment requirement for the * stack. This alignment requirement may be stricter than that for the * data types alignment specified by CPU_ALIGNMENT. If the CPU_ALIGNMENT * is strict enough for the stack, then this should be set to 0. * * NOTE: This must be a power of 2 either 0 or greater than CPU_ALIGNMENT. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define CPU_STACK_ALIGNMENT 0/* * ISR handler macros *//* * Support routine to initialize the RTEMS vector table after it is allocated. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define _CPU_Initialize_vectors()/* * Disable all interrupts for an RTEMS critical section. The previous * level is returned in _level. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define _CPU_ISR_Disable( _isr_cookie ) \ { \ (_isr_cookie) = 0; /* do something to prevent warnings */ \ }/* * Enable interrupts to the previous level (returned by _CPU_ISR_Disable). * This indicates the end of an RTEMS critical section. The parameter * _level is not modified. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define _CPU_ISR_Enable( _isr_cookie ) \ { \ }/* * This temporarily restores the interrupt to _level before immediately * disabling them again. This is used to divide long RTEMS critical * sections into two or more parts. The parameter _level is not * modified. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define _CPU_ISR_Flash( _isr_cookie ) \ { \ }/* * Map interrupt level in task mode onto the hardware that the CPU * actually provides. Currently, interrupt levels which do not * map onto the CPU in a generic fashion are undefined. Someday, * it would be nice if these were "mapped" by the application * via a callout. For example, m68k has 8 levels 0 - 7, levels * 8 - 255 would be available for bsp/application specific meaning. * This could be used to manage a programmable interrupt controller * via the rtems_task_mode directive. * * The get routine usually must be implemented as a subroutine. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define _CPU_ISR_Set_level( new_level ) \ { \ }unsigned32 _CPU_ISR_Get_level( void );/* end of ISR handler macros *//* Context handler macros *//* * Initialize the context to a state suitable for starting a * task after a context restore operation. Generally, this * involves: * * - setting a starting address * - preparing the stack * - preparing the stack and frame pointers * - setting the proper interrupt level in the context * - initializing the floating point context * * This routine generally does not set any unnecessary register * in the context. The state of the "general data" registers is * undefined at task start time. * * NOTE: This is_fp parameter is TRUE if the thread is to be a floating * point thread. This is typically only used on CPUs where the * FPU may be easily disabled by software such as on the SPARC * where the PSR contains an enable FPU bit. * * NO_CPU Specific Information: * * XXX document implementation including references if appropriate */#define _CPU_Context_Initialize( _the_context, _stack_base, _size, \ _isr, _entry_point, _is_fp ) \ { \ }/*
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -