diff --git a/docs/firmware-design.md b/docs/firmware-design.md
index c5a8cba..68e3f3a 100644
--- a/docs/firmware-design.md
+++ b/docs/firmware-design.md
@@ -959,7 +959,7 @@
 ---------------------------------
 
 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 @@
 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 1e49deb..05a9975 100644
--- a/docs/porting-guide.md
+++ b/docs/porting-guide.md
@@ -569,7 +569,7 @@
 
 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 33b75f1..97607f0 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 6d31847..ce41bae 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 @@
 	msr     CNTKCTL_EL1, x0
 ret:
 	isb
-#endif /* FIRST_RESET_HANDLER_CALL */
 	ret
 endfunc plat_reset_handler