summaryrefslogtreecommitdiffstats
path: root/doc/bsp_howto
diff options
context:
space:
mode:
authorSebastian Huber <sebastian.huber@embedded-brains.de>2012-12-06 17:47:30 +0100
committerSebastian Huber <sebastian.huber@embedded-brains.de>2012-12-07 09:38:41 +0100
commit48bff53b3dec885085b87db413329830110c9bb0 (patch)
treeba0c249c350b9f4f84bedb5569f11e611874617e /doc/bsp_howto
parentbsp/gdbarmsim: Do not call bsp_cleanup() (diff)
downloadrtems-48bff53b3dec885085b87db413329830110c9bb0.tar.bz2
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.
Diffstat (limited to 'doc/bsp_howto')
-rw-r--r--doc/bsp_howto/init.t42
-rw-r--r--doc/bsp_howto/support.t24
2 files changed, 32 insertions, 34 deletions
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