[RTEMS Project] #3459: Rework initialization and interrupt stack support

[RTEMS trac]

#3459: Rework initialization and interrupt stack support
------------------------------+-----------------------------
  Reporter:  Sebastian Huber  |      Owner:  Sebastian Huber
      Type:  enhancement      |     Status:  assigned
  Priority:  normal           |  Milestone:  5.1
 Component:  score            |    Version:  5
  Severity:  normal           |   Keywords:
Blocked By:                   |   Blocking:
------------------------------+-----------------------------
 We need an initialization stack to run the sequential system
 initialization before multitasking is enabled. The system initialization
 is done with interrupts disabled.

 We need an interrupt stack for interrupt processing. This helps to avoid a
 per thread stack overhead for interrupt processing. The size for interrupt
 stack is application dependent, e.g. maximum interrupt nest level, stack
 demands of interrupt handlers.

 The initialization and interrupt stacks are needed for each processor in
 the system.

 Since interrupts are disabled during the sequential system initialization
 we can re-use the interrupt stack for the initialization stack. This is
 important for low end targets, with very limited RAM sizes. We need the
 initialization stack before a proper C run-time environment is set up e.g.
 we cannot assume that the access to global data is available. The stack
 memory area begin and size should be available via global symbols (named
 addresses). On some BSPs, e.g. ARM, this is done via the linker command
 file.

 It should be possible to set the stack size via the
 CONFIGURE_INTERRUPT_STACK_SIZE configuration option and not via some magic
 stuff in linker command files.

 Many BSPs set the BSS area to zero during system initialization. Thus, the
 initialization stack must not be contained in the BSS area.

 The interrupt stack implementation is currently controlled by the
 following CPU port defines:
 {{{
 /**
  * Does RTEMS manage a dedicated interrupt stack in software?
  *
  * If TRUE, then a stack is allocated in @ref _ISR_Handler_initialization.
  * If FALSE, nothing is done.
  *
  * If the CPU supports a dedicated interrupt stack in hardware,
  * then it is generally the responsibility of the BSP to allocate it
  * and set it up.
  *
  * If the CPU does not support a dedicated interrupt stack, then
  * the porter has two options: (1) execute interrupts on the
  * stack of the interrupted task, and (2) have RTEMS manage a dedicated
  * interrupt stack.
  *
  * If this is TRUE, @ref CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
  *
  * Only one of @ref CPU_HAS_SOFTWARE_INTERRUPT_STACK and
  * @ref CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE.  It is
  * possible that both are FALSE for a particular CPU.  Although it
  * is unclear what that would imply about the interrupt processing
  * procedure on that CPU.
  *
  * Port Specific Information:
  *
  * XXX document implementation including references if appropriate
  */
 #define CPU_HAS_SOFTWARE_INTERRUPT_STACK FALSE

 /**
  * Does this CPU have hardware support for a dedicated interrupt stack?
  *
  * If TRUE, then it must be installed during initialization.
  * If FALSE, then no installation is performed.
  *
  * If this is TRUE, @ref CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
  *
  * Only one of @ref CPU_HAS_SOFTWARE_INTERRUPT_STACK and
  * @ref CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE.  It is
  * possible that both are FALSE for a particular CPU.  Although it
  * is unclear what that would imply about the interrupt processing
  * procedure on that CPU.
  *
  * Port Specific Information:
  *
  * XXX document implementation including references if appropriate
  */
 #define CPU_HAS_HARDWARE_INTERRUPT_STACK TRUE

 /**
  * Does RTEMS allocate a dedicated interrupt stack in the Interrupt
 Manager?
  *
  * If TRUE, then the memory is allocated during initialization.
  * If FALSE, then the memory is allocated during initialization.
  *
  * This should be TRUE is CPU_HAS_SOFTWARE_INTERRUPT_STACK is TRUE.
  *
  * Port Specific Information:
  *
  * XXX document implementation including references if appropriate
  */
 #define CPU_ALLOCATE_INTERRUPT_STACK TRUE
 }}}
 Do the following steps to unify and simplify the initialization and
 interrupt stack support.
 1. Add RTEMS_DECLARE_GLOBAL_SYMBOL() and RTEMS_DEFINE_GLOBAL_SYMBOL()
 macros to basedefs.h, to allow a global symbol definition via C code, e.g.
 in confdefs.h, to make the interrupt stack size available to the low level
 initialization code.

 2. Add a special input section ".rtemsstack" to the linker command files
 to allow a placement of the interrupt stacks. The BSPs can provide the
 optimal memory location for this section, e.g. on-chip RAM, tightly-
 coupled memory.

 This makes the CPU_HAS_SOFTWARE_INTERRUPT_STACK and
 CPU_HAS_HARDWARE_INTERRUPT_STACK CPU port defines superfluous, since the
 low level initialization code has all information available via global
 symbols.

 This makes the CPU_ALLOCATE_INTERRUPT_STACK CPU port define superfluous,
 since the interrupt stacks are allocated by confdefs.h for all
 architectures.  There is no need for BSP-specific linker command file
 magic.

 The optional _CPU_Interrupt_stack_setup() is still useful to customize the
 registration of the interrupt stack area in the per-CPU information.

--
Ticket URL: <http://devel.rtems.org/ticket/3459>
RTEMS Project <http://www.rtems.org/>
RTEMS Project