diff --git a/docs/firmware-design.md b/docs/firmware-design.md index c5a8cba39d0975e7de886acce8e2050f10bae8a3..68e3f3adb5d964e2abaf7e28ce553dbad0f86f01 100644 --- a/docs/firmware-design.md +++ b/docs/firmware-design.md @@ -959,7 +959,7 @@ The sample crash output is shown below. --------------------------------- Trusted Firmware implements a framework that allows CPU and platform ports to -perform actions immediately after a CPU is released from reset in both the cold +perform actions very early after a CPU is released from reset in both the cold and warm boot paths. This is done by calling the `reset_handler()` function in both the BL1 and BL3-1 images. It in turn calls the platform and CPU specific reset handling functions. @@ -968,33 +968,12 @@ Details for implementing a CPU specific reset handler can be found in Section 8. Details for implementing a platform specific reset handler can be found in the [Porting Guide](see the `plat_reset_handler()` function). -When adding functionality to a reset handler, the following points should be -kept in mind. - -1. The first reset handler in the system exists either in a ROM image - (e.g. BL1), or BL3-1 if `RESET_TO_BL31` is true. This may be detected at - compile time using the constant `FIRST_RESET_HANDLER_CALL`. - -2. When considering ROM images, it's important to consider non TF-based ROMs - and ROMs based on previous versions of the TF code. - -3. If the functionality should be applied to a ROM and there is no possibility - of a ROM being used that does not apply the functionality (or equivalent), - then the functionality should be applied within a `#if - FIRST_RESET_HANDLER_CALL` block. - -4. If the functionality should execute in BL3-1 in order to override or - supplement a ROM version of the functionality, then the functionality - should be applied in the `#else` part of a `#if FIRST_RESET_HANDLER_CALL` - block. - -5. If the functionality should be applied to a ROM but there is a possibility - of ROMs being used that do not apply the functionality, then the - functionality should be applied outside of a `FIRST_RESET_HANDLER_CALL` - block, so that BL3-1 has an opportunity to apply the functionality instead. - In this case, additional code may be needed to cope with different ROMs - that do or do not apply the functionality. - +When adding functionality to a reset handler, keep in mind that if a different +reset handling behavior is required between the first and the subsequent +invocations of the reset handling code, this should be detected at runtime. +In other words, the reset handler should be able to detect whether an action has +already been performed and act as appropriate. Possible courses of actions are, +e.g. skip the action the second time, or undo/redo it. 8. CPU specific operations framework ----------------------------- diff --git a/docs/porting-guide.md b/docs/porting-guide.md index 1e49deb882de211a45efa4319c8ecf9ed3cfd979..05a99758b7b8c4860f7c0713b1889ff07a5010fa 100644 --- a/docs/porting-guide.md +++ b/docs/porting-guide.md @@ -569,7 +569,7 @@ preserve the values of callee saved registers x19 to x29. The default implementation doesn't do anything. If a platform needs to override the default implementation, refer to the [Firmware Design] for general -guidelines regarding placement of code in a reset handler. +guidelines. ### Function : plat_disable_acp() diff --git a/include/common/bl_common.h b/include/common/bl_common.h index 33b75f1884ada5da2ccc81965a9c65db38f6a971..97607f0b3eab5c7a1b3be41a0eeb598e8b523d73 100644 --- a/include/common/bl_common.h +++ b/include/common/bl_common.h @@ -90,18 +90,6 @@ (_p)->h.attr = (uint32_t)(_attr) ; \ } while (0) -/******************************************************************************* - * Constant that indicates if this is the first version of the reset handler - * contained in an image. This will be the case when the image is BL1 or when - * its BL3-1 and RESET_TO_BL31 is true. This constant enables a subsequent - * version of the reset handler to perform actions that override the ones - * performed in the first version of the code. This will be required when the - * first version exists in an un-modifiable image e.g. a BootROM image. - ******************************************************************************/ -#if IMAGE_BL1 || (IMAGE_BL31 && RESET_TO_BL31) -#define FIRST_RESET_HANDLER_CALL -#endif - #ifndef __ASSEMBLY__ #include <cdefs.h> /* For __dead2 */ #include <cassert.h> diff --git a/plat/arm/board/juno/aarch64/juno_helpers.S b/plat/arm/board/juno/aarch64/juno_helpers.S index 6d3184745ce954ed89ab9dbd6d527eac0ebad362..ce41baeec673b7dac6e7f3381f0d7e2feb06dbdf 100644 --- a/plat/arm/board/juno/aarch64/juno_helpers.S +++ b/plat/arm/board/juno/aarch64/juno_helpers.S @@ -42,10 +42,6 @@ /* -------------------------------------------------------------------- * void plat_reset_handler(void); * - * Before adding code in this function, refer to the guidelines in - * docs/firmware-design.md to determine whether the code should reside - * within the FIRST_RESET_HANDLER_CALL block or not. - * * For Juno r0: * - Implement workaround for defect id 831273 by enabling an event * stream every 65536 cycles. @@ -58,13 +54,9 @@ * - The default value for the L2 Tag RAM latency for Cortex-A57 is * suitable. * - Defect #831273 doesn't affect Juno r1. - * - * This code is included only when FIRST_RESET_HANDLER_CALL is defined - * since it should be executed only during BL1. * -------------------------------------------------------------------- */ func plat_reset_handler -#ifdef FIRST_RESET_HANDLER_CALL /* -------------------------------------------------------------------- * Determine whether this code is running on Juno r0 or Juno r1. * Keep this information in x2. @@ -123,6 +115,5 @@ apply_831273: msr CNTKCTL_EL1, x0 ret: isb -#endif /* FIRST_RESET_HANDLER_CALL */ ret endfunc plat_reset_handler