From 48bff53b3dec885085b87db413329830110c9bb0 Mon Sep 17 00:00:00 2001 From: Sebastian Huber Date: Thu, 6 Dec 2012 17:47:30 +0100 Subject: score: rtems_initialize_start_multitasking() Do not return from rtems_initialize_start_multitasking() and call rtems_fatal() instead with a fatal source of RTEMS_FATAL_SOURCE_EXIT and a fatal code with the exit status. Remove all bsp_cleanup() functions. The boot_card() is now a no return function. --- doc/bsp_howto/init.t | 42 +++++++++++++++++++----------------------- doc/bsp_howto/support.t | 24 +++++++++++++----------- 2 files changed, 32 insertions(+), 34 deletions(-) (limited to 'doc/bsp_howto') diff --git a/doc/bsp_howto/init.t b/doc/bsp_howto/init.t index f91d15f934..d1486cca5f 100644 --- a/doc/bsp_howto/init.t +++ b/doc/bsp_howto/init.t @@ -41,7 +41,6 @@ for this functionality. @example ../../sparc/shared/start.S -../../sparc/shared/bspclean.c @end example @b{NOTE:} In most BSPs, the directory named @code{start340} in the @@ -93,10 +92,9 @@ to the shared @code{bootcard.c} framework then through the C Library, RTEMS, device driver initialization phases, and the context switch to the first application task. After this, the application executes until it calls @code{exit}, @code{rtems_shutdown_executive}, or some -other normal termination initiating routine and control is returned -to @code{bootcard.c} which allows the BSP to perform some cleanup in C -(@code{bsp_cleanup}) and then @code{boot_card} returns to the assembly -language which initially invoked it. +other normal termination initiating routine and a fatal system state is +reached. The optional @code{bsp_fatal_extension} initial extension can perform +BSP specific system termination. The routines invoked during this will be discussed and their location in the RTEMS source tree pointed out as we discuss each. @@ -197,28 +195,26 @@ this point in the initialization sequence. This is the last opportunity for the BSP to insert BSP specific code into the initialization sequence. @item It invokes the RTEMS directive -@code{rtems_initialize_start_multitasking()} which starts multitasking and context switches to the first task. @code{boot_card()} will not return until the application is shutdown. As part of this sequence the following actions occur: - -@itemize @bullet - -@item RTEMS will context switch to the first application task. As a -side-effect of this context switch, processor interrupts will be enabled. -This is often the source of a fatal error during BSP development because -the BSP did not clear and/or disable all interrupt sources and a spurious -interrupt will occur . - -@item When in the context of the first task but before its body has been +@code{rtems_initialize_start_multitasking()} +which initiates multitasking and performs a context switch to the +first user application task and may enable interrupts as a side-effect of +that context switch. The context switch saves the executing context. The +application runs now. The directive rtems_shutdown_executive() will return +to the saved context. The exit() function will use this directive. + +After a return to the saved context a fatal system state is reached. The +fatal source is RTEMS_FATAL_SOURCE_EXIT with a fatal code set to the value +passed to rtems_shutdown_executive(). + +The enabling of interrupts during the first context switch is often the source +for fatal errors during BSP development because the BSP did not clear and/or +disable all interrupt sources and a spurious interrupt will occur. + +When in the context of the first task but before its body has been entered, any C++ Global Constructors will be invoked. @end itemize -@item Finally after the application shutsdown RTEMS and control is -return to @code{boot_card()} from RTEMS, it invokes the BSP specific -routine @code{bsp_cleanup()} to perform any necessary board specific -shutdown actions. - -@end itemize - That's it. We just went through the entire sequence. @subsection bsp_start() - BSP Specific Initialization diff --git a/doc/bsp_howto/support.t b/doc/bsp_howto/support.t index 9856deb0fa..5f8eb1a9c9 100644 --- a/doc/bsp_howto/support.t +++ b/doc/bsp_howto/support.t @@ -179,23 +179,25 @@ this operation. @findex CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK If your BSP does not want to support dynamic heap extension, then you do not have to do anything special. However, if you want to support @code{sbrk}, you must provide an implementation of this method and define @code{CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK} in @code{bsp.h}. This informs @code{rtems/confdefs.h} to configure the Malloc Family Extensions which support @code{sbrk}. -@section bsp_cleanup(uint32_t status) - Cleanup the Hardware +@section bsp_fatal_extension() - Cleanup the Hardware -The @code{bsp_cleanup()} is the last C code invoked. Most of the BSPs -use the same shared version of @code{bsp_cleanup()} that does nothing. -This implementation is located in the following file: +The @code{bsp_fatal_extension()} is an optional BSP specific initial extension +invoked once a fatal system state is reached. Most of the BSPs use the same +shared version of @code{bsp_fatal_extension()} that does nothing or performs a +system reset. This implementation is located in the following file: @example c/src/lib/libbsp/shared/bspclean.c @end example -The @code{bsp_cleanup()} routine can be used to return to a ROM monitor, -insure that interrupt sources are disabled, etc.. This routine is the -last place to ensure a clean shutdown of the hardware. The @code{status} -argument is the value passed to the service which initiated shutting -down RTEMS. All of the non-fatal shutdown sequences ultimately pass -their exit status to @code{rtems_shutdown_executive} and this is what -is passed to this routine. +The @code{bsp_fatal_extension()} routine can be used to return to a ROM +monitor, insure that interrupt sources are disabled, etc.. This routine is the +last place to ensure a clean shutdown of the hardware. The fatal source, +internal error indicator, and the fatal code arguments are available to +evaluate the fatal condition. All of the non-fatal shutdown sequences +ultimately pass their exit status to @code{rtems_shutdown_executive} and this +is what is passed to this routine in case the fatal source is +RTEMS_FATAL_SOURCE_EXIT. On some BSPs, it prints a message indicating that the application completed execution and waits for the user to press a key before -- cgit v1.2.3