Remove FIRST_RESET_HANDLER_CALL build option

This patch removes the FIRST_RESET_HANDLER_CALL build flag and its
use in ARM development platforms. If a different reset handling
behavior is required between the first and subsequent invocations
of the reset handling code, this should be detected at runtime.

On Juno, the platform reset handler is now always compiled in.
This means it is now executed twice on the cold boot path, first in
BL1 then in BL3-1, and it has the same behavior in both cases. It is
also executed twice on the warm boot path, first in BL1 then in the
PSCI entrypoint code.

Also update the documentation to reflect this change.

NOTE: THIS PATCH MAY FORCE PLATFORM PORTS THAT USE THE
FIRST_RESET_HANDLER_CALL BUILD OPTION TO FIX THEIR RESET HANDLER.

Change-Id: Ie5c17dbbd0932f5fa3b446efc6e590798a5beae2

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
 -----------------------------

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()
 

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>

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