Please see the comment below.
On 2023-07-05 13:18, Sebastian Huber wrote:
---
bsps/sparc/leon3/include/bsp/leon3.h | 12 ++++
bsps/sparc/leon3/start/bspclean.c | 89 +++++++++++++++++++---------
bsps/sparc/leon3/start/bspsmp.c | 16 +----
3 files changed, 77 insertions(+), 40 deletions(-)
@@ -92,7 +124,10 @@ void bsp_fatal_extension(
#endif
#if BSP_RESET_BOARD_AT_EXIT
- /* If user wants to implement custom reset/reboot it can be done here */
- bsp_reset();
+ /*
+ * Stop the system termination right now. This skips the dynamically
+ * installed fatal error extensions and the generics shutdown procedure.
+ */
+ _CPU_Fatal_halt( source, code );
#endif
}
Some thoughts and questions on the implication of this.
As I understand it, bsp_reset() here was intended as a way for the user to
provide an application/mission specific way to take late action on a fatal
event. And also that bsp_reset() was called in a "single-processor
state" where
the other processors had already been stopped (powered down).
Some potential use cases for action in a bsp_reset(), I can think of:
- Log an entry in an off-chip, on-board non-volatile memory with a record
consisting of system date, fatal_source and fatal_code.
- Signal the event, using GPIO, to an external failure/redundancy
controller.
- Tell an on-board reset circuit to initiate a board reset/shutdown.
- Issuing a "warm" system restart by jumping to a known location in a
ROM boot
loader.
The _CPU_Fatal_halt looks like a path of no return (error mode) and no more
user hooks. But would it perhaps be possibility for the application to
provide
an extension with CONFIGURE_INITIAL_EXTENSIONS to have application specific
actions like the ones above?
--
Best regards,
Martin Åberg
Software Engineer
Frontgrade Gaisler
martin.ab...@gaisler.com
Frontgrade Gaisler AB, Kungsgatan 12, SE-411 19 GÖTEBORG, Sweden.
+46 (0) 31 775 8650, www.gaisler.com
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
